Re: Question about dist-cvs make targets
On Thu, 7 Jan 2010, Jesse Keating wrote: As I proceed to port our make system over into fedpkg, I've ran across a couple targets that are giving me pause. Is anybody out there making use of the following targets? unused-patches I use this fairly often, typically to clean up leftovers after rebasing to new version. - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH] Bodhi No Frozen Rawhide & Critical Path support
On Thu, Jan 07, 2010 at 12:44:38PM -0500, Luke Macken wrote: > Attached is the initial bodhi patch. I have since fixed a bug with the patch[0], wrote more test cases, and merged it into git. Now to deploy it... luke [0]: http://lmacken.fedorapeople.org/patches/bodhi-no-frozen-rawhide-critpath.patch -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
On Thu, Jan 07, 2010 at 03:17:45PM +, Zing wrote: > On Thu, 07 Jan 2010 07:58:11 +0100, David Tardon wrote: > > > >> gconftool-2 -s -t string /apps/metacity/general/focus_new_windows > >> strict > > thanks for that... > > >> To be useful - when that's set, new windows never take focus away from > >> a window that looks like a terminal window. (This is assuming the above > >> opens a new window. If it changes an existing window, then > >> "focus_new_windows" won't affect the behavior.) > >> > >> > > Doesn't work. I set this, then started gedit from gnome-terminal. The > > gedit window got focus. > > Are you sure you didn't have another gedit window open. It seems to work > as Owen mentioned (only if you don't have an existing window open)... > it's so close to what I needed, unfortunately I always keep a browser > open in the background. > Definitely not, I use gedit as a test application only. But I see what's the problem now--it only works from freshly started terminal. So all the terminals that were running at the moment I set focus_new_windows to strict didn't pick that setting and continue to open new windows focused. Isn't that a bug in gnome-terminal (or metacity)? D. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
On Wed, Jan 06, 2010 at 02:24:17PM -0500, Adam Jackson wrote: > > They do happen to have the same WM_CLASS and WM_CLIENT_LEADER window > properties. But that still only addresses automatic focus changes > within a single application. Automatic focus changes across apps is > probably desirable; otherwise, nothing you launch from the gnome panel > will launch focused, which is rather absurd. > Not absurd at all. I certainly wouldn't want any app I launch from a panel to start focused. -Toshio pgprhR4DP5v9E.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Recommendations on how to handle this package and its libraries
On Wed, Jan 06, 2010 at 08:58:08AM -0600, Adam Miller wrote: > I'm currently packaging lessfs and there are apparently a couple > libraries that are a part of it that have become a cause for concern > by the reviewer (rightfully so) and I'm hoping someone could offer a > recommendation of how to go about packaging them. > > Review Request: https://bugzilla.redhat.com/show_bug.cgi?id=530473 > Latest spec (not yet submitted to the review): > http://maxamillion.fedorapeople.org/lessfs.spec > Latest SRPM (not yet submitted to the review): > http://maxamillion.fedorapeople.org/lessfs-1.0.0-1.fc12.src.rpm > > There is one library that will have to be a separate package, QuickLZ > which I plan to package up and put in for review but there are many > other lib_$foo.c files that belong to lessfs and are original work by > the author. > > Upstream has been extremely responsive and very helpful through out > this process and is willing to work along with me to get some changes > into the upstream release but I'm just trying to find the best > solution. > > Here is where the recommendations would be helpful: > > Should I package the source and not worry about packaging the libraries? > Should the libraries be in their own sub package? > Should each library be their own package? > or $other? > > * As long as the tarball is the canonical source for all of the libraries (ie, it's a case of lessfs's author also writing these libraries and releasing all of them as a single tarball) they can be in a single srpm. * It's best to separate libraries from programs in separate subpackages. * Whether to have a single or multiple subpackages for the libraries depends on the libraries. Things that affect this are size of the libraries, whether programs will generally need all of the libraries or only some of them, and the dep chainof the libraries (ie: if libfoo-one requires libgtk and libfoo-two requires libqt they should be put into separate subpackages). -Toshio pgp1DCaqmsgoN.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Plan for tomorrow's (20100108) FESCo meeting
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 17:00UTC (noon EST) in #fedora-meeting on irc.freenode.net. Welcome New members - Adam Jackson, Christoph Wickert, Peter Jones and Matthew Garrett Farewells to departing members - Jon Stanley, Dan Horák, Jarod Wilson, and David Woodhouse Elect New Chair #298 Revoke Paul Johnsons pacakger access and put him on probation. #278 Better Hostname - https://fedoraproject.org/wiki/Features/BetterHostname #299 Feature: AtSpiTwo - https://fedoraproject.org/wiki/Features/AtSpiTwo #300 Feature: BetterWebcamSupportF13 - https://fedoraproject.org/wiki/Features/BetterWebcamSupportF13 Open Floor For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor. Kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
On Thu, Jan 07, 2010 at 09:29:55AM +0100, Tomas Mraz wrote: > On Wed, 2010-01-06 at 22:43 -0500, Gregory Maxwell wrote: > > On Wed, Jan 6, 2010 at 1:08 PM, Adam Jackson wrote: > > > On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote: > > >> There is no case where I want a new window or popup to take focus. Makes > > >> for an easy algorithm. (hitting r in mutt is not a problem :) > > > > > > There is no case where _you_ want this, sure. > > > > Some people what that. > > Many other people want the focus change to happen in a _few_ limited > > cases where it makes sense. > > > > Current behaviour fails to accurately predict those cases (no doubt > > because, in part, the limited acceptable cases differ from person to > > person), and so you get unexpected focus theft. This is bad for > > everyone. > > The problem is that the "automatic focus change only when intended by > user" will never be done 100% correctly. This is just impossible to do. > > So the actual better user experience case would be to always require the > user to press some (easy) key combination to transfer the focus from the > currently focused window. The user would quickly learn it. Having to click into every window when it opens (especially if it was intentional) can become quite tiring - I had to do this while working on MPX when the proof-of-concept WM didn't have any auto-focus capabilities. It is predictable, but _really_ annoying. Anyway, it's a simple cost/benefit question. Does the cost of the unintended focus changes outweigh the cost of clicking into new windows for your workflow? If so, how about the person next to you? How about your partner, uncle, grandma, neighbour's son, boss? > So the actual better user experience case [...] "better user experience" is really hard to quantify. TWM has a predictable interface for displaying new windows and could thus be labelled as "better user experience" based on this premise. No other popular window manager uses the same approach though. It all depends on your definition of "better", "user" and "experience". Cheers, Peter -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Pulseaudio update issue... [ UPDATE 2 ]
> On Thu, 07 Jan 2010 11:03:00 -0700, "Nathanael D. Noblet" > said: NDN> So it seems it is related to thunderbird. I have the preference set to NDN> play a sound when new mail arrives. After it has, sounds is messed NDN> up... Bug with thunderbird I presume? I don't think so. I think my current F12 has much much deeper issues. They seem somewhat sound related and somewhat not. All my sound-producing applications don't work any longer. Typically the first sound works and everything after that freezes. But it's not just sound applications that seem to be freezing. Many applications (firefox) seem to randomly hang as well. Invariably when I check them with strace to see what they're doing they're always hung on a futex() call. Maybe they're all trying to pipe through pulseaudio and that's the root cause. Considering how many flash applications thees days produce sound it wouldn't surprise me that the root of my firefox problems are in fact sound. In the end though, pretty much nothing sound related is working for me. I'm currently playing music on my phone instead because amarok and even xmms are completely DOA for me right now. -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto occasionally goes into "eternal" loop looking for deltas
On Thu, 2010-01-07 at 21:19 +0200, Jonathan Dieter wrote:
> On Thu, 2010-01-07 at 20:44 +0200, Pekka Pietikainen wrote:
> > Presto is one of the best things ever, but occasionally it ends up not
> > finding the delta files from any of the mirrors in the mirror list and just
> > loops through them without making any progress. --disablepresto works
> > a-ok, I think yum clean all; yum update also did the trick once.
> >
> > Still, this can probably be made a lot better. It shouldn't do that even if
> > the mirrors
> > are out-of-sync. Maybe add some logic that just disables
> > presto if the deltas are nowhere to be found after a few attempts? Anyone
> > else even see this happen?
>
> Yeah, see https://bugzilla.redhat.com/show_bug.cgi?id=540140. To
> summarize, the problem is that new updates have been pushed to the
> server between the time you loaded primary.sqlite and prestodelta.xml.
>
> When you run 'yum clean metadata' or 'yum clean all' it removes the
> outdated cached primary.sqlite and downloads the newer version.
>
> The bug has been closed as WONTFIX because there have only been a few
> reports; I wouldn't mind revisiting that decision if someone has a
> clever way of fixing it. (And I'm not convinced that checking n mirrors
> and then giving up is the solution.)
The plugin could require yum >= 3.2.25, and then do something like (in
config or prereposetup):
for repo in repos:
repo.mdpolicy.append('prestodelta')
...which would auto download presto MD when yum gets new repomd/primary.
People might complain though :) ... another kind of fix would be for the
plugin to call ".cleanExpireCache()" if the MD fails to download.
The nice server side fix is to keep around more than one complete set
of MD (possible now we have unique MD filenames), so there would have to
be two updates within the client side cache timeout. But I'm not sure
how easy that is.
--
James Antill - ja...@fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.26
http://yum.baseurl.org/wiki/YumMultipleMachineCaching
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: fedora-release-rawhide subpackage
On Thu, 07 Jan 2010 14:02:24 -0700, Kevin Fenzi wrote: > On Thu, 07 Jan 2010 15:24:05 +0100 > Till Maas wrote: > >> You propose that the repo should be enabled by default if the package >> is installed. I don't like this. This make it a lot easier to break a >> system with Rawhide, if one installs the repo file, e.g. only to be >> able to easily download the src.rpm files with yumdownloader or to >> query it with repoquery, but not to actually install the unsigned >> packages from it. > > How many folks do this? I suppose this is a downside... we could also > ship it with default disabled, so you would need to install and then > enable it. What makes you think these same users won't then also edit and enable rawhide at this point? It's not much of a stretch to think these seemingly innocent users might see this "rawhide" package, install, and then also enable it; in fact, ISTM, a package that they don't have that promises some type of newest whizbang gadgets that they're missing out on might entice more of this class of user. :( Might I suggest: $ chattr +i /etc/yum.repos.d/fedora-rawhide.repo just kidding, well, half-kidding :) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about dist-cvs make targets
> "DC" == David Cantrell writes:
DC> I was using 'unused-patches' until the packaging guidelines had us
DC> change Patch lines to use %{name} if that applied.
Please quote chapter and verse there. I don't recall any guidelines
requiring such a thing.
- J<
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: fedora-release-rawhide subpackage
On Wed, 2010-01-06 at 20:47 -0700, Kevin Fenzi wrote: > I wrote up this using the Feature template, but I don't guess it's > really that much of a feature: > > https://fedoraproject.org/wiki/Features/RawhideRepoSubpackage > > (except in that it needs coordination across the distro and docs > updates, etc). > > Thoughts? > Sounds like a great idea to me. Preventing accidents is good. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Moin orphaned in EL-4 and EL-5
Hi, I've orphaned the moin package in the EL-4 and EL-5 branches. I will keep maintaining the package in Fedora >= 11. I'll quote an earlier mail I sent to the EPEL list: "I took ownership of the moin package in Fedora and EPEL for about six months ago. I haven't gotten around to doing almost anything to it, though, mostly because I have to admit that I'm not that interested in EPEL since I don't run any EL installations myself. The other hurdle in updating moin is that the package in EPEL is really old by now. It's in version 1.5 and the newest upstream version is 1.9. If there was an update submitted for moin, we'd need to also have some instructions on how to convert the wiki data into a format which is suitable for the new version, and frankly, I don't know how to do that, since I've only gotten involved with moin during the 1.7 era. All I know is that trying to go from 1.5 to 1.6 was really difficult when it was tested with the Fedora wiki data back when Fedora was still running moin." I hope someone who cares about having moin in EPEL would take over the package and figure out how the data upgrade process would be best described to the users of the package or how to backport security patches from the maintained releases. If not, I think we could also retire moin from EPEL completely. -- Ville-Pekka Vainio -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: fedora-release-rawhide subpackage
On Thu, 07 Jan 2010 15:24:05 +0100 Till Maas wrote: > You propose that the repo should be enabled by default if the package > is installed. I don't like this. This make it a lot easier to break a > system with Rawhide, if one installs the repo file, e.g. only to be > able to easily download the src.rpm files with yumdownloader or to > query it with repoquery, but not to actually install the unsigned > packages from it. How many folks do this? I suppose this is a downside... we could also ship it with default disabled, so you would need to install and then enable it. > It will probably also auto break systems that just > install everything, which is also not nice. I don't think it's possible to 'install everything'. There are a number of packages in the collection that conflict. Or do you have some other meaning for 'everything'? kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: fedora-release-rawhide subpackage
On Thu, 7 Jan 2010 12:28:59 + Mat Booth wrote: > You must do a lot more Fedora user support than I do; is it really a > frequent occurrence that users unwittingly enable Rawhide and screw up > their systems? > > Not a criticism, I'm just surprised it happens at all. Yeah, I would say we get about 1 person a week or so in #fedora that decided they wanted as many choices as possible, so they enabled every repo file they had installed. I guess it's sometimes more, sometimes less. > Maybe the problem could be solved just by labelling it clearer, > rawhide-development or something. Currently it says: # These packages are untested and still under development. This # repository is used for development of new releases. # # This repository can see significant daily turnover and major # functionality changes which cause unexpected problems with other # development packages. Please use these packages if you want to work # with the Fedora developers by testing these new development packages. # # fedora-test-l...@redhat.com is available as a discussion forum for # testing and troubleshooting for development packages in conjunction # with new test releases. # # More information is available at http://fedoraproject.org/wiki/Testing # # Reproducible and reportable issues should be filed at # http://bugzilla.redhat.com/. However, the people who enable all repos (including source and debuginfo) aren't the ones who would stop doing that after reading most anything I don't think. They want everything enabled so they can have the most choice/newest stuff, and then are very sad when they find out they have to re-install to go back to the stable release. kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH] Bodhi No Frozen Rawhide & Critical Path support
On Thu, 2010-01-07 at 14:34 -0500, James Laska wrote: > Just to properly set expectations, I'd like to point out that while I > agree that critical path package updates should meet a higher degree of > quality, we've not yet collectively determined what "testing updates" > means. QA is working on the infrastructure to support test automation > and bouncing around ideas as to what a quality package update might look > like. Until then, the same procedures in place for updates-testing now > will be used for critical path packages [1]. During the freezes for F-12, releng at least took time to install, and minimally run the packages that were critical before allowing them to break freeze. That's what is expected out of this as well, a minimal look to ensure no brown paper bag updates get through. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [PATCH] Bodhi No Frozen Rawhide & Critical Path support
On Thu, 2010-01-07 at 12:44 -0500, Luke Macken wrote:
> Yesterday I made an initial attempt at adding support for the No Frozen
> Rawhide[0] and Critical Path Packages[1] policies in bodhi.
>
> From a bodhi/releng perspective, here is what the process will look like so
> far:
>
> Releng adds F13 to bodhi as a `locked` release:
> >>> Release(name='F13', long_name='Fedora 13', dist_tag='dist-f13',
> locked=True)
>
> Developer pushes update to F13:
> If the package is in the critical path, force it to go to testing
> until approved by releng/qa
>
> QA/Releng test F13 critical path testing updates, and promote them to
> stable.
Just to properly set expectations, I'd like to point out that while I
agree that critical path package updates should meet a higher degree of
quality, we've not yet collectively determined what "testing updates"
means. QA is working on the infrastructure to support test automation
and bouncing around ideas as to what a quality package update might look
like. Until then, the same procedures in place for updates-testing now
will be used for critical path packages [1].
> Releng kicks off a push of all updates:
> If an update is for a pending release, and headed to stable, only
> move it's tags:
> dist-f13-updates-candidate => dist-f13
> If an update is for a pending release, and headed to testing, do
> things as normal:
> dist-f13-updates-candidate => dist-f13-updates-testing
>
> Release unlocks F13 release in bodhi upon RC, and everything returns to
> normal:
> >>> Release.byName('F13').locked = False
>
> Assuming I've understood everything correctly, here are the actions that I
> took
> to implement this, and the test cases that I've written to validate the
> policy:
>
> [X] 100% Bodhi No Frozen Rawhide & Critical Path support
> [X] Ability to flag a release as 'pending'
> [X] Disable the ability to push critpath updates directly to stable
> for pending releases
> [X] If a package is critical path, force it to go to testing
> [X] Push testing updates to pending releases normally
> [X] Only allow it to go to stable if approved by releng/qa
> [X] Strongly discourage developers from pushing critpath packages
> directly to stable, for all releases
> [X] Strongly discourage pushing non-critpath updates directly to
> stable for pending releases
> [X] Tag stable updates to pending releases with Release.dist_tag
> [X] Don't mash stable updates for pending releases, only move their
> tags
> [_] 85% Test cases
> [X] Create a pending release
> [X] Submit an update for this pending release, as normal
> [X] Ensure we can't push directly to stable
> [X] Ensure it has a testing request
> [X] Try pushing it to stable
> [X] Ensure we can't as a normal developer
> [X] Ensure we can as a member of the proper groups (releng/qa)
> [X] Ensure devs cannot push critpath updates in testing to stable
> [X] Ensure releng/qa can push critpath updates in testing to stable
> [X] Ensure noncritpath updates in testing can be pushed to stable
> [_] Try pushing updates (currently not possible via unit tests)
> [_] Ensure the stable updates only get tagged
> [_] Ensure the testing update gets pushed normally
>
> Attached is the initial bodhi patch. Thanks to some clever re-use of an
> existing DB column, I was able to implement this without making any schema
> modifications, so deployment should be trivial. I've also hardcoded the
> critical path package list in bodhi's config file until we can query the pkgdb
> for it.
>
> Please let me know if I'm misunderstanding any parts of this proposal,
> if I am missing something, or if you find any bugs in my patch. I'll
> try and get this into staging ASAP so we can test the masher portion of
> this.
> Thanks,
> luke
>
> [0]: https://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal
> [1]: https://fedoraproject.org/wiki/Critical_Path_Packages_Proposal
signature.asc
Description: This is a digitally signed message part
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about dist-cvs make targets
On Thu, 2010-01-07 at 19:47 +0100, Enrico Scholz wrote: > Jonathan Underwood writes: > > > I have used make patch quite a bit when developing patches. I guess > > it's just a wrapper around gendiff though, so it maybe redundant i.e. > > in my use case I could have been using gendiff. > > fwiw, 'gendiff' does not retain comments in patches and fails when one > file is touched by multiple patches. I wrote a wrapper around 'quilt' > which is used like > > | %apply -n23 -p1 > > This expands to > > | quilt import -p 1 %PATCH23 > | quilt push -f > > resp. > > | %patch23 -p1 > > on systems without this macro. Refreshing and developing of patches is > very easy in this way. > > > Enrico > I think the patch target could be replaced by my exploded tree with git approach. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto occasionally goes into "eternal" loop looking for deltas
On Thu, 2010-01-07 at 20:44 +0200, Pekka Pietikainen wrote: > Presto is one of the best things ever, but occasionally it ends up not > finding the delta files from any of the mirrors in the mirror list and just > loops through them without making any progress. --disablepresto works > a-ok, I think yum clean all; yum update also did the trick once. > > Still, this can probably be made a lot better. It shouldn't do that even if > the mirrors > are out-of-sync. Maybe add some logic that just disables > presto if the deltas are nowhere to be found after a few attempts? Anyone > else even see this happen? Yeah, see https://bugzilla.redhat.com/show_bug.cgi?id=540140. To summarize, the problem is that new updates have been pushed to the server between the time you loaded primary.sqlite and prestodelta.xml. When you run 'yum clean metadata' or 'yum clean all' it removes the outdated cached primary.sqlite and downloads the newer version. The bug has been closed as WONTFIX because there have only been a few reports; I wouldn't mind revisiting that decision if someone has a clever way of fixing it. (And I'm not convinced that checking n mirrors and then giving up is the solution.) Jonathan signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
yum-presto occasionally goes into "eternal" loop looking for deltas
Presto is one of the best things ever, but occasionally it ends up not finding the delta files from any of the mirrors in the mirror list and just loops through them without making any progress. --disablepresto works a-ok, I think yum clean all; yum update also did the trick once. Still, this can probably be made a lot better. It shouldn't do that even if the mirrors are out-of-sync. Maybe add some logic that just disables presto if the deltas are nowhere to be found after a few attempts? Anyone else even see this happen? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about dist-cvs make targets
Jonathan Underwood writes: > I have used make patch quite a bit when developing patches. I guess > it's just a wrapper around gendiff though, so it maybe redundant i.e. > in my use case I could have been using gendiff. fwiw, 'gendiff' does not retain comments in patches and fails when one file is touched by multiple patches. I wrote a wrapper around 'quilt' which is used like | %apply -n23 -p1 This expands to | quilt import -p 1 %PATCH23 | quilt push -f resp. | %patch23 -p1 on systems without this macro. Refreshing and developing of patches is very easy in this way. Enrico -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about dist-cvs make targets
On Thu, 2010-01-07 at 07:51 -1000, David Cantrell wrote:
> I was using 'unused-patches' until the packaging guidelines had us change
> Patch lines to use %{name} if that applied. The unused-patches target would
> be helpful if it could expand RPM macros.
That's a guideline worth ignoring.
If I'm being less charitable, that's a guideline worth deleting.
- ajax
signature.asc
Description: This is a digitally signed message part
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about dist-cvs make targets
On Thu, Jan 7, 2010 at 5:28 PM, Jesse Keating wrote: > unused-patches I use this one, but it's probably something that should just happen as part of a build sanity check, or even better make it harder to cause (the new dist-git setup might do this right?) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: UPDATE Pulseaudio update issue...
Ok so totally bizarre, I re-updated via yum... It caused rhythmbox to freeze as the connection to the server died. I killed and restarted it, and the track changes were now sound seamless, as is tab completion in gnome-terminal again... I'm really not sure what the issue was, I've rebooted a few times today with noticing that an update had occurred, and then after the downgrade etc... So whatever it was is no longer an issue... odd. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Pulseaudio update issue... [ UPDATE 2 ]
So it seems it is related to thunderbird. I have the preference set to play a sound when new mail arrives. After it has, sounds is messed up... Bug with thunderbird I presume? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about dist-cvs make targets
On Thu, Jan 07, 2010 at 09:28:26AM -0800, Jesse Keating wrote: > As I proceed to port our make system over into fedpkg, I've ran across a > couple targets that are giving me pause. > > Is anybody out there making use of the following targets? > > check > export > patch > unused-patches > unused-fedora-patches > > If so, please reply to which one, and in what scenario you use those > targets. Thanks! I used 'unused-patches' every now & then to quickly check which patches are obsolete - it is easier than doing it by hand in packages which have more than 10 patches applied. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about dist-cvs make targets
Jesse Keating píše v Čt 07. 01. 2010 v 09:28 -0800: > As I proceed to port our make system over into fedpkg, I've ran across a > couple targets that are giving me pause. > > Is anybody out there making use of the following targets? > > unused-patches I tried to use this one when putting some packages with long history and some balast into a shape, but I wasn't 100% successful IIRC. > If so, please reply to which one, and in what scenario you use those > targets. Thanks! Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about dist-cvs make targets
2010/1/7 Jesse Keating : > As I proceed to port our make system over into fedpkg, I've ran across a > couple targets that are giving me pause. > > Is anybody out there making use of the following targets? > > check > export > patch > unused-patches > unused-fedora-patches > > If so, please reply to which one, and in what scenario you use those > targets. Thanks! I have used make patch quite a bit when developing patches. I guess it's just a wrapper around gendiff though, so it maybe redundant i.e. in my use case I could have been using gendiff. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[PATCH] Bodhi No Frozen Rawhide & Critical Path support
Yesterday I made an initial attempt at adding support for the No Frozen
Rawhide[0] and Critical Path Packages[1] policies in bodhi.
From a bodhi/releng perspective, here is what the process will look like so far:
Releng adds F13 to bodhi as a `locked` release:
>>> Release(name='F13', long_name='Fedora 13', dist_tag='dist-f13',
locked=True)
Developer pushes update to F13:
If the package is in the critical path, force it to go to testing until
approved by releng/qa
QA/Releng test F13 critical path testing updates, and promote them to
stable.
Releng kicks off a push of all updates:
If an update is for a pending release, and headed to stable, only move
it's tags:
dist-f13-updates-candidate => dist-f13
If an update is for a pending release, and headed to testing, do things
as normal:
dist-f13-updates-candidate => dist-f13-updates-testing
Release unlocks F13 release in bodhi upon RC, and everything returns to
normal:
>>> Release.byName('F13').locked = False
Assuming I've understood everything correctly, here are the actions that I took
to implement this, and the test cases that I've written to validate the policy:
[X] 100% Bodhi No Frozen Rawhide & Critical Path support
[X] Ability to flag a release as 'pending'
[X] Disable the ability to push critpath updates directly to stable for
pending releases
[X] If a package is critical path, force it to go to testing
[X] Push testing updates to pending releases normally
[X] Only allow it to go to stable if approved by releng/qa
[X] Strongly discourage developers from pushing critpath packages
directly to stable, for all releases
[X] Strongly discourage pushing non-critpath updates directly to stable
for pending releases
[X] Tag stable updates to pending releases with Release.dist_tag
[X] Don't mash stable updates for pending releases, only move their tags
[_] 85% Test cases
[X] Create a pending release
[X] Submit an update for this pending release, as normal
[X] Ensure we can't push directly to stable
[X] Ensure it has a testing request
[X] Try pushing it to stable
[X] Ensure we can't as a normal developer
[X] Ensure we can as a member of the proper groups (releng/qa)
[X] Ensure devs cannot push critpath updates in testing to stable
[X] Ensure releng/qa can push critpath updates in testing to stable
[X] Ensure noncritpath updates in testing can be pushed to stable
[_] Try pushing updates (currently not possible via unit tests)
[_] Ensure the stable updates only get tagged
[_] Ensure the testing update gets pushed normally
Attached is the initial bodhi patch. Thanks to some clever re-use of an
existing DB column, I was able to implement this without making any schema
modifications, so deployment should be trivial. I've also hardcoded the
critical path package list in bodhi's config file until we can query the pkgdb
for it.
Please let me know if I'm misunderstanding any parts of this proposal,
if I am missing something, or if you find any bugs in my patch. I'll
try and get this into staging ASAP so we can test the masher portion of
this.
Thanks,
luke
[0]: https://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal
[1]: https://fedoraproject.org/wiki/Critical_Path_Packages_Proposal
diff --git a/bodhi/admin.py b/bodhi/admin.py
index db096dd..7d80d25 100644
--- a/bodhi/admin.py
+++ b/bodhi/admin.py
@@ -110,9 +110,14 @@ class AdminController(Controller, SecureResource):
else:
# Get a list of all updates with a request that aren't
# unapproved security updates, or for a locked release
-requests = filter(lambda update: not update.release.locked,
- PackageUpdate.select(
- PackageUpdate.q.request != None))
+requests = PackageUpdate.select(PackageUpdate.q.request !=
None)
+
+# Come F13+, bodhi will not have locked releases. It will
+# implement the 'No Frozen Rawhide' proposal, and treat
'locked'
+# releases as pending.
+#requests = filter(lambda update: not update.release.locked,
+# PackageUpdate.select(
+# PackageUpdate.q.request != None))
for update in requests:
if update.type == 'security' and not update.approved:
continue
diff --git a/bodhi/controllers.py b/bodhi/controllers.py
index fa2e7e1..7b134e5 100644
--- a/bodhi/controllers.py
+++ b/bodhi/controllers.py
@@ -831,6 +831,20 @@ class Root(controllers.RootController):
flash_log(str(e))
raise InvalidUpdateException(params)
+
Pulseaudio update issue...
Hello, First off, not trying to bash or otherwise start a war about pulseaudio. Just checking if anyone else is experiencing issues with the latest F12 update (0.9.21-2) of pulseaudio? For me changing between tracks in rhythmbox include a sound 'pop' at the same time as the volume goes up/down. Also when doing tab completion in gnome-terminal the music playing nearly pauses for the tab 'ding' sound. I have reverted to the original version (0.9.19-2) and it seems to work, however the volume control applet can't start as it is looking for newer pulseaudio libs, even though I reverted it... I've looked through the bugs already on bugzilla but I'm not sure if its been posted yet or not... Anyone having issues like that? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about dist-cvs make targets
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 7 Jan 2010, Jesse Keating wrote:
As I proceed to port our make system over into fedpkg, I've ran across a
couple targets that are giving me pause.
Is anybody out there making use of the following targets?
check
export
patch
unused-patches
unused-fedora-patches
If so, please reply to which one, and in what scenario you use those
targets. Thanks!
I was using 'unused-patches' until the packaging guidelines had us change
Patch lines to use %{name} if that applied. The unused-patches target would
be helpful if it could expand RPM macros.
That may have changed now. I haven't checked it in a while.
- --
David Cantrell
Red Hat / Honolulu, HI
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.13 (GNU/Linux)
iEYEARECAAYFAktGHxAACgkQ5hsjjIy1VkkA8ACeIRILiiyrMYGvRIf/HW4/C1Rh
wK8AoLRRd0JWEftiXv7Vqpop0LLG1eXg
=Ix6d
-END PGP SIGNATURE-
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Question about dist-cvs make targets
As I proceed to port our make system over into fedpkg, I've ran across a couple targets that are giving me pause. Is anybody out there making use of the following targets? check export patch unused-patches unused-fedora-patches If so, please reply to which one, and in what scenario you use those targets. Thanks! -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
On Thu, 07 Jan 2010 07:58:11 +0100, David Tardon wrote: >> gconftool-2 -s -t string /apps/metacity/general/focus_new_windows >> strict thanks for that... >> To be useful - when that's set, new windows never take focus away from >> a window that looks like a terminal window. (This is assuming the above >> opens a new window. If it changes an existing window, then >> "focus_new_windows" won't affect the behavior.) >> >> > Doesn't work. I set this, then started gedit from gnome-terminal. The > gedit window got focus. Are you sure you didn't have another gedit window open. It seems to work as Owen mentioned (only if you don't have an existing window open)... it's so close to what I needed, unfortunately I always keep a browser open in the background. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Our static Libraries packaging guidelines once more
On Wed, 2010-01-06 at 17:38 +0100, Michael Schwendt wrote: > > The only problem with that is that just about every packaging guideline > > has _some_ valid exceptions (that's why they're all guidelines...) and > > it's rather hard to build exceptions into an automatic testing system in > > a way which doesn't get horribly crufty in a hurry. > > If exceptions become a problem because they are applied to many packages, > it would still be possible to adjust the guidelines or mark the packages > with special metadata comments in their .spec files. Then packagers would > need to make use of an exception _explicitly_, showing that what they do > is intentional. Yup, indeed - this is the approach MDV uses for its rpmlint checks (you can code an exception into the spec file if it's justified). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
On Thu, Jan 7, 2010 at 3:29 AM, Tomas Mraz wrote: ... snip ... > The problem is that the "automatic focus change only when intended by > user" will never be done 100% correctly. This is just impossible to do. > > So the actual better user experience case would be to always require the > user to press some (easy) key combination to transfer the focus from the > currently focused window. The user would quickly learn it. > You wouldn't need a 'new' (easy) key combination... your window manager already defines a way to 'set focus' > Then the problem shifts to whether the newly created windows should be > opened in the background or not. > ... snip ... Thank you... There is a big difference between auto-raise, and auto-focus. I would complain about auto-focus on pop-ups (that should be my configuration choice) but auto-raise isn't (as) anoying. Its a visual distraction, but then again, thats why its called a 'popup', but at least it didn't cause me to type the wrong thing into the wrong window. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20100107 changes
On Thu, Jan 07, 2010 at 02:30:28PM +, Rawhide Report wrote: > cduce-0.5.3-3.fc13.i686 requires ocaml(runtime) = 0:3.11.1 Still waiting on upstream. > 1:libguestfs-1.0.80-10.fc13.i686 requires gfs-utils Should be fixed tomorrow. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20100107 changes
Compose started at Thu Jan 7 08:15:04 UTC 2010 Broken deps for i386 -- R-hdf5-1.6.9-4.fc13.i686 requires hdf5 = 0:1.8.3 anjal-0.1.0-1.fc13.i686 requires libevolution-mail-shared.so.0 anjal-0.1.0-1.fc13.i686 requires libefilterbar.so.0 cduce-0.5.3-3.fc13.i686 requires ocaml(runtime) = 0:3.11.1 cduce-0.5.3-3.fc13.i686 requires ocaml(Filename) = 0:7cd172f02b7ee9b8d7bda3bb92144951 cduce-0.5.3-3.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cduce-0.5.3-3.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-0.5.3-3.fc13.i686 requires ocaml(Printexc) = 0:fdf007941aa14d1a26323558012dbf52 cduce-0.5.3-3.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Format) = 0:b7ba3152a5eec5609d6ab86e6c51eebb cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Buffer) = 0:23af67395823b652b807c4ae0b581211 cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(runtime) = 0:3.11.1 cduce-ocamlduce-0.5.3-3.fc13.i686 requires ocaml(Obj) = 0:c827f726ce05da709cf7de58fc15e324 cluster-snmp-0.16.1-2.fc12.i686 requires libnetsnmp.so.15 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gconf-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-devel-0.1.0.5-8.fc12.i686 requires ghc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-doc-0.1.0.5-8.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-ghc-paths-prof-0.1.0.5-8.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gio-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glade-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-glib-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gstreamer-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtk-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtkglext-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 ghc-gtksourceview2-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-devel-2009.2.0.2-3.fc13.i686 requires ghc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-doc-2009.2.0.2-3.fc13.i686 requires ghc-doc = 0:6.10.4 ghc-haskell-platform-prof-2009.2.0.2-3.fc13.i686 requires ghc-prof = 0
Re: Proposal: fedora-release-rawhide subpackage
On Wed, Jan 06, 2010 at 08:47:09PM -0700, Kevin Fenzi wrote: > I'd like to propose splitting out > the /etc/yum.repos.d/fedora-rawhide.repo file into a > fedora-release-rawhide subpackage which is NOT installed by default or > shipped on the live media. > > I wrote up this using the Feature template, but I don't guess it's > really that much of a feature: > > https://fedoraproject.org/wiki/Features/RawhideRepoSubpackage > > (except in that it needs coordination across the distro and docs > updates, etc). > > Thoughts? You propose that the repo should be enabled by default if the package is installed. I don't like this. This make it a lot easier to break a system with Rawhide, if one installs the repo file, e.g. only to be able to easily download the src.rpm files with yumdownloader or to query it with repoquery, but not to actually install the unsigned packages from it. It will probably also auto break systems that just install everything, which is also not nice. Regards Till pgpaZkcQf2OFn.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto and comps
On Thu, 2010-01-07 at 04:44 -0500, Jens Petersen wrote: > In F12 we shipped yum-presto in @gnome-desktop - a kind of a compromise I > guess. > Presto/deltarpm is very useful for machines with low net connectivity to > mirrors > but enough resources to rebuild rpms. > > But yum-presto is not a desktop package at all and certainly does not > belong in the gnome-desktop group. [1] > > Perhaps the right approach for f13 is to install yum-presto by default > but to disable it by default? Lighter compression might also > help to reduce the resource requirements for older machines? > I don't think that there really is something to fix here, and I don't know that I can make you happy. If I do the customization in the kickstart file, you complain as well (see PK-command-not-found) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Sources file audit - 2010-01-05
On Wed, Jan 06, 2010 at 10:22:58PM +0100, Hans Ulrich Niedermann wrote: > I thought the canonical URL for downloads from sourceforge.net has been > >http://prdownloads.sourceforge.net/PROJECT/NAME-VERSION.tar.gz? It should be downloads... not prdownloads... according to the SourceURL ^^ Guidelines: https://fedoraproject.org/wiki/Packaging/SourceURL#Sourceforge.net Regards Till pgpuRWAhL7Lr4.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: fedora-release-rawhide subpackage
2010/1/7 Kevin Fenzi : > Greetings. > > I'd like to propose splitting out > the /etc/yum.repos.d/fedora-rawhide.repo file into a > fedora-release-rawhide subpackage which is NOT installed by default or > shipped on the live media. > > I wrote up this using the Feature template, but I don't guess it's > really that much of a feature: > > https://fedoraproject.org/wiki/Features/RawhideRepoSubpackage > > (except in that it needs coordination across the distro and docs > updates, etc). > > Thoughts? > > (either here or the talk page of the above wiki link). > > Thanks, > > kevin > You must do a lot more Fedora user support than I do; is it really a frequent occurrence that users unwittingly enable Rawhide and screw up their systems? Not a criticism, I'm just surprised it happens at all. Maybe the problem could be solved just by labelling it clearer, rawhide-development or something. Regards, Mat -- Mat Booth -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: End of days?
On Thu, 7 Jan 2010, Tony Nelson wrote: On 10-01-06 17:54:10, Robert Relyea wrote: On 01/06/2010 01:43 PM, Orion Poplawski wrote: [or...@orca fedora/devel]$ ls */dead.package | wc -l 666 We're ok. The original number may have been 616: http://www.csad.ox.ac.uk/POxy/beast616.htm No, that's merely the most common "correction" by those with a little knowledge. 666 was the number for Neron Ceaser, while 616 was for Nero Ceaser (latinized form of name). Of course, the reference was actually to Domitian, who was Emperor when the Temple in Jerusalem was destroyed (again) after yet another revolt by the Jews. Mentioning the current Emperor in an unflattering way would get one killed, hence the code. If you want to continue this discussion please do so offlist. thanks, -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto and comps
On Thu, 2010-01-07 at 04:44 -0500, Jens Petersen wrote: > In F12 we shipped yum-presto in @gnome-desktop - a kind of a compromise I > guess. > Presto/deltarpm is very useful for machines with low net connectivity to > mirrors > but enough resources to rebuild rpms. > > But yum-presto is not a desktop package at all and certainly does not > belong in the gnome-desktop group. > > Perhaps the right approach for f13 is to install yum-presto by default > but to disable it by default? It looks like there are a couple of questions to deal with: 1) yum-presto is in @gnome-desktop and shouldn't be 2) yum-presto is enabled by default If we don't want (2), then remove it from @gnome-desktop. People who need/want it can install it using "yum install yum-presto", and it will start working immediately. If we do want (2), then we just need to work out how to fix (1). If not @gnome-desktop (which is probably not where it belongs), then possibly @base? FWIW, my opinion on (2) (as the yum-presto maintainer) is that it should be installed by default, but I'm obviously biased. > Lighter compression might also help to reduce the resource > requirements for older machines? IIRC we've already reduced the xz compression level in our rpms from 7 to 2. (See http://osdir.com/ml/fedora-devel-list/2009-09/msg00946.html) Jonathan signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads-up: %define vs %global in specs
On Tue, 5 Jan 2010, Panu Matilainen wrote:
For the impatient:
Starting with today's rawhide, the these kind of constructs in specs no
longer "work":
%{?!foo: %define foo bar}
For the generally desired effect, the above simply becomes:
%{?!foo: %global foo bar}
This is already recommended by the Fedora guidelines, but packages which
haven't been updated to follow the guideline might need revising:
https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define
FYI, this change broke font package macros.
I've reverted the macro scoping "fix" until I have a chance to properly
investigate the breakage (possibly some quirk related to %{lua: ...}
macros).
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
yum-presto and comps
In F12 we shipped yum-presto in @gnome-desktop - a kind of a compromise I guess. Presto/deltarpm is very useful for machines with low net connectivity to mirrors but enough resources to rebuild rpms. But yum-presto is not a desktop package at all and certainly does not belong in the gnome-desktop group. [1] Perhaps the right approach for f13 is to install yum-presto by default but to disable it by default? Lighter compression might also help to reduce the resource requirements for older machines? Jens [1] https://bugzilla.redhat.com/show_bug.cgi?id=549659 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
On Wed, 2010-01-06 at 22:43 -0500, Gregory Maxwell wrote: > On Wed, Jan 6, 2010 at 1:08 PM, Adam Jackson wrote: > > On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote: > >> There is no case where I want a new window or popup to take focus. Makes > >> for an easy algorithm. (hitting r in mutt is not a problem :) > > > > There is no case where _you_ want this, sure. > > Some people what that. > Many other people want the focus change to happen in a _few_ limited > cases where it makes sense. > > Current behaviour fails to accurately predict those cases (no doubt > because, in part, the limited acceptable cases differ from person to > person), and so you get unexpected focus theft. This is bad for > everyone. The problem is that the "automatic focus change only when intended by user" will never be done 100% correctly. This is just impossible to do. So the actual better user experience case would be to always require the user to press some (easy) key combination to transfer the focus from the currently focused window. The user would quickly learn it. Then the problem shifts to whether the newly created windows should be opened in the background or not. It would be also easy to teach the user. I can for example imagine that the new window would first appear on the top overlayed with a semi-transparent text like: "Press Ctrl-Tab to send the window to background, press Alt-Tab to start typing into the window, press Esc to close the window" The other keypresses would still go to the previously focused window. With the compositing WMs it would be also easily possible to make the new window semitransparent over the old window so the user would still see that he is typing into the old window. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
