Dear M.M.,
1. You can untag them (koji untag-pkg) if the builds where made this
day. If not, you'll need to get it blocked. For the f16/f18 branches,
you can also just make sure not to add it to Bodhi, but I would
suggest untagging them anyway.
2. Yes, they can block package for specific branches,
Patrick Uiterwijk wrote:
> Hello M.M.,
>
> As soon as you request the git repo, you will automatically get the
> devel (F19) branch.
> You could do two things:
> 1. Just make no builds for any other branches, then it won't get in there.
> 2. Request rel-eng to block the package for the devel branch
Hi Mamoru,
On Sat, Aug 25, 2012 at 7:31 PM, TASAKA Mamoru
wrote:
> Fedora Rawhide Report wrote, at 08/25/2012 09:34 PM +9:00:
>>
>> Compose started at Sat Aug 25 08:15:10 UTC 2012
>>
>> Broken deps for x86_64
>> --
>> [OpenSceneGraph]
>>
Hello M.M.,
As soon as you request the git repo, you will automatically get the
devel (F19) branch.
You could do two things:
1. Just make no builds for any other branches, then it won't get in there.
2. Request rel-eng to block the package for the devel branch.
With kind regards,
Patrick
--
deve
Hi everyone.
I'm packaging some themes for GNOME Shell, which are compatible with only
GNOME 3.4 (i.e. can be installed with success only on Fedora 17).
What do you think is the best way to act?
Can I submit the package to the F17 branch only, excluding everyone else
(also master, i.e. F19)?
Or is
On 08/25/2012 05:21 PM, Kevin Kofler wrote:
Lennart Poettering wrote:
Start by filing bugs. Every feature owner should get the chance to first
fix things before you escalate it all the way to FESCO.
Filing bugs assumes the feature is fixable in the first place.
No, it doesn't. It provides a
Tom Callaway wrote:
> On 08/25/2012 07:09 PM, Kevin Kofler wrote:
>> He's saying that %systemd_post and %systemd_post_enable should do the
>> exact SAME thing on F18, i.e. enable the service if and only if the
>> policy says it should be enabled, no matter what the package says. In
>> other words,
On 2012-08-25 10:09, Todd Zullinger wrote:
Enrico Scholz wrote:
Todd Zullinger writes:
Doing this would break current users that have already configured
their system to use __git_ps1().
What are "current users"? Those who installed your just released
rawhide changes?
No, it breaks anyone t
On 08/25/2012 07:09 PM, Kevin Kofler wrote:
> He's saying that %systemd_post and %systemd_post_enable should do the exact
> SAME thing on F18, i.e. enable the service if and only if the policy says it
> should be enabled, no matter what the package says. In other words, make the
> "_enable" suff
Lennart Poettering wrote:
> Start by filing bugs. Every feature owner should get the chance to first
> fix things before you escalate it all the way to FESCO.
Filing bugs assumes the feature is fixable in the first place. This one is
not.
Kevin Kofler
--
devel mailing list
devel@lists.
Tom Callaway wrote:
> Unfortunately, it isn't that easy. Please note that I had to redefine
> %systemd_post for F16 and F17 in order to simplify it to that. The
> %systemd_post_enable logic doesn't apply in F18+, because there is no
> longer any explicit enablement at the package level. The two are
Todd Zullinger writes:
>>> Doing this would break current users that have already configured
>>> their system to use __git_ps1().
>>
>> What are "current users"? Those who installed your just released
>> rawhide changes?
>
> No, it breaks anyone that's currently using __git_ps1(), as the
> functi
Enrico Scholz wrote:
Todd Zullinger writes:
Doing this would break current users that have already configured
their system to use __git_ps1().
What are "current users"? Those who installed your just released rawhide
changes?
No, it breaks anyone that's currently using __git_ps1(), as the
On 08/22/2012 10:53 AM, Kamil Paral wrote:
Following this track: if I look into the build log for the 64-bit f17
build [1], it seems that the package doesn't require anything but
the
libenet-1.3.3(64-bit). So; in my simple eyes, this looks like AutoQA
doesn't really understand the situation if
Todd Zullinger writes:
>>> I placed git-prompt.sh in /etc/profile.d where it should be sourced
>>> for normal login shells.
>>
>> As I wrote in the update comment, please revert it. It pollutes the
>> environment of every user with functions which are probably never be
>> used.
> ...
> Doing thi
Enrico Scholz wrote:
Todd Zullinger writes:
I placed git-prompt.sh in /etc/profile.d where it should be sourced
for normal login shells.
As I wrote in the update comment, please revert it. It pollutes the
environment of every user with functions which are probably never be
used.
As thes
Rex Dieter wrote:
> I don't accept it. Dan reacting poorly is a given, and something he
> (and I with him) are working on.
> I personally don't feel it helps taking your greivances public, as now
> Dan's perception of you (and now potentially others) will be colored
> as
> hostile.
Sorry, for me
Peter Robinson a écrit:
>> I naively thought 'yum downgrade xulrunner' would get me back to the
>> previous xulrunner, but it just doesn't do anything. Is that expected?
>
> In rawhide yes because the old version is no longer in the repository.
I see, thanks.
> You can get the old version from
Fedora Rawhide Report wrote, at 08/25/2012 09:34 PM +9:00:
Compose started at Sat Aug 25 08:15:10 UTC 2012
Broken deps for x86_64
--
[OpenSceneGraph]
OpenSceneGraph-examples-gtk-3.0.1-12.fc18.x86_64 requires
libpangox-1.0.so.0()(64
On Sat, Aug 25, 2012 at 10:54 AM, Dodji Seketeli wrote:
> Hello,
>
> Fedora Rawhide Report a écrit:
>
>> firefox-14.0.1-3.fc19
>> -
>> * Wed Aug 22 2012 Dan Horák - 14.0.1-3
>> - add fix for secondary arches from xulrunner
>
> With this update and ...
>
>> xulrunner-15.0-1.b6
Hello,
Fedora Rawhide Report a écrit:
> firefox-14.0.1-3.fc19
> -
> * Wed Aug 22 2012 Dan Horák - 14.0.1-3
> - add fix for secondary arches from xulrunner
With this update and ...
> xulrunner-15.0-1.b6.fc19
>
> * Wed Aug 22 2012 Martin Stransky -
21 matches
Mail list logo
