7:30 a.m.
Le Ven 16 novembre 2007 13:11, Thorsten Leemhuis a écrit :
On 15.11.2007 18:44, Thorsten Leemhuis wrote:
> On 15.11.2007 09:44, Ralf Corsepius wrote:
>> On Wed, 2007-11-14 at 23:18 +0100, Thorsten Leemhuis wrote:
>> [...]
>
> Similar problem (also not earth-shaking and a corner-case as well),
> also
> still unfixed:
> https://www.redhat.com/archives/fedora-packaging/2007-August/msg00092.html
Spot, thx for fixing this:
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=diff&...
If guideline changes are being done this way I wonder why I created a
Fonts SIG, spent days writing fonts packaging guidelines, and
submitted them to FPC (that was supposed to review them for this week
session). It seems following procedures is a lot of work just to be
sidelined by the first person that does not want to bother with them
and posts on fedora-devel.
For the record:
1. I disagreed with this change when it was first posted on fedora-devel.
2. I still disagree with this change
3. I actually maintain font packages (just in case some people still
think that's relevant to comment on associated guidelines)
4. The associated scriplet barfed once in years of use by many
packages (and not even on a stable release but during a rawhide
update!), because of actual packaging bugs in one package. I don't
think one transaction error in years is such a huge price to pay to
keep our packages sane
5. If someone had bothered reading the guidelines submitted to FPC
he'd have seen they only refresh fc-cache on the font directory owned
by a particular package and that only if fontconfig is installed. So a
problem package will only screw itself now.
6. when this error happens you'll better fail the transaction and
reinstall the package. Silently accepting the transaction means you
get fontconfig users complaining the font package that apparently
installed successfully does not work in their fontconfig app (just
lost ~ 1 hour debugging such a case yesterday).
--
Nicolas Mailhot
8:14 a.m.
New subject: Review queue/FESCo after the merge
On Fri, Nov 16, 2007 at 02:30:03PM +0100, Nicolas Mailhot wrote:
If guideline changes are being done this way I wonder why I created a
Fonts SIG, spent days writing fonts packaging guidelines, and
submitted them to FPC (that was supposed to review them for this week
session). It seems following procedures is a lot of work just to be
sidelined by the first person that does not want to bother with them
and posts on fedora-devel.
I agree that the procedures regarding packaging guidelines changes
should be followed. And bypassing them that way is not right. However I
also think that packagers can also not follow guidelines when they have
reasons to disagree and wait for someone to challenge their position and
bring the issue on the devel list, then to FESCo.
--
Pat
8:18 a.m.
New subject: Review queue/FESCo after the merge
On Fri, 2007-11-16 at 14:30 +0100, Nicolas Mailhot wrote:
For the record:
1. I disagreed with this change when it was first posted on fedora-devel.
2. I still disagree with this change
3. I actually maintain font packages (just in case some people still
think that's relevant to comment on associated guidelines)
4. The associated scriplet barfed once in years of use by many
packages (and not even on a stable release but during a rawhide
update!), because of actual packaging bugs in one package. I don't
think one transaction error in years is such a huge price to pay to
keep our packages sane
While I understand what you're saying, we adopted the policy that %post
should never ever fail, because it has the potential to really destroy a
large transaction. It was an accidental omission on that specific
section, which is why I corrected it. In fact, I thought I had already
done it a while ago, but had forgotten to.
I have read your font guideline drafts, and I think they are rather
good. We simply just don't want any scriptlets to fail, no matter how
unlikely or contained the failure may be.
Please don't take it personally. :)
~spot
9:18 a.m.
New subject: Review queue/FESCo after the merge
On Fri, 2007-11-16 at 09:18 -0500, Tom "spot" Callaway wrote:
On Fri, 2007-11-16 at 14:30 +0100, Nicolas Mailhot wrote:
> For the record:
> 1. I disagreed with this change when it was first posted on fedora-devel.
> 2. I still disagree with this change
> 3. I actually maintain font packages (just in case some people still
> think that's relevant to comment on associated guidelines)
> 4. The associated scriplet barfed once in years of use by many
> packages (and not even on a stable release but during a rawhide
> update!), because of actual packaging bugs in one package. I don't
> think one transaction error in years is such a huge price to pay to
> keep our packages sane
While I understand what you're saying, we adopted the policy that %post
should never ever fail, because it has the potential to really destroy a
large transaction. It was an accidental omission on that specific
section, which is why I corrected it. In fact, I thought I had already
done it a while ago, but had forgotten to.
I have read your font guideline drafts, and I think they are rather
good. We simply just don't want any scriptlets to fail, no matter how
unlikely or contained the failure may be.
Please don't take it personally. :)
Of course, the correct way to have scriptlets that don't fail is to
write them in a way that doesn't fails, not the swipe the failure under
the carpet...
9:24 a.m.
New subject: Review queue/FESCo after the merge
On Fri, 2007-11-16 at 10:18 -0500, Matthias Clasen wrote:
Of course, the correct way to have scriptlets that don't fail is
to
write them in a way that doesn't fails, not the swipe the failure under
the carpet...
Yes, but fixing every possible application which could ever be put in a
scriplet to never, ever, ever fail, even in the cases when failure is
acceptable (and shouldn't kill the transaction) is a little beyond the
mandate of the FPC. ;)
~spot
9:33 a.m.
New subject: Review queue/FESCo after the merge
On Fri, 2007-11-16 at 10:24 -0500, Tom "spot" Callaway wrote:
On Fri, 2007-11-16 at 10:18 -0500, Matthias Clasen wrote:
> Of course, the correct way to have scriptlets that don't fail is to
> write them in a way that doesn't fails, not the swipe the failure under
> the carpet...
Yes, but fixing every possible application which could ever be put in a
scriplet to never, ever, ever fail, even in the cases when failure is
acceptable (and shouldn't kill the transaction) is a little beyond the
mandate of the FPC. ;)
If scriptlet are not allowed to ever, ever, fail, then just make rpm
ignore the exit code of scriptlets.
9:36 a.m.
New subject: Review queue/FESCo after the merge
On Fri, 2007-11-16 at 10:33 -0500, Matthias Clasen wrote:
On Fri, 2007-11-16 at 10:24 -0500, Tom "spot" Callaway
wrote:
> On Fri, 2007-11-16 at 10:18 -0500, Matthias Clasen wrote:
>
> > Of course, the correct way to have scriptlets that don't fail is to
> > write them in a way that doesn't fails, not the swipe the failure under
> > the carpet...
>
> Yes, but fixing every possible application which could ever be put in a
> scriplet to never, ever, ever fail, even in the cases when failure is
> acceptable (and shouldn't kill the transaction) is a little beyond the
> mandate of the FPC. ;)
>
If scriptlet are not allowed to ever, ever, fail, then just make rpm
ignore the exit code of scriptlets.
Again, code changes are outside of the FPC mandate. Feel like patching
rpm? :)
~spot
1:07 p.m.
New subject: Review queue/FESCo after the merge
On 16.11.2007 16:36, Tom "spot" Callaway wrote:
On Fri, 2007-11-16 at 10:33 -0500, Matthias Clasen wrote:
> On Fri, 2007-11-16 at 10:24 -0500, Tom "spot" Callaway wrote:
>> On Fri, 2007-11-16 at 10:18 -0500, Matthias Clasen wrote:
>>
>>> Of course, the correct way to have scriptlets that don't fail is to
>>> write them in a way that doesn't fails, not the swipe the failure under
>>> the carpet...
>> Yes, but fixing every possible application which could ever be put in a
>> scriplet to never, ever, ever fail, even in the cases when failure is
>> acceptable (and shouldn't kill the transaction) is a little beyond the
>> mandate of the FPC. ;)
> If scriptlet are not allowed to ever, ever, fail, then just make rpm
> ignore the exit code of scriptlets.
Again, code changes are outside of the FPC mandate. Feel like patching
rpm? :)
BTW, this touches another problem where Fedora needs to improve: we have
no group that realizes adjustments done to the packaging guidelines in
the packages. Take *for example* the scriptlet change in
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=diff&...
Is just a corner case, but a good example.
With grep, sed, cvs diff and some small adjustments by hand this change
could also be done quickly in CVS for all effected packages. I could
start now and will likely finished the task for all packages in devel
within less then 30 minutes. But nobody does that, as modifying packages
that are owned by other people is frowned upon in Fedora land.
Such changes therefor often take years to get realized in practice. Is
that what we want?
CU
knurd
3:15 p.m.
New subject: Review queue/FESCo after the merge
On Fri, 2007-11-16 at 20:07 +0100, Thorsten Leemhuis wrote:
With grep, sed, cvs diff and some small adjustments by hand this
change
could also be done quickly in CVS for all effected packages. I could
start now and will likely finished the task for all packages in devel
within less then 30 minutes. But nobody does that, as modifying packages
that are owned by other people is frowned upon in Fedora land.
Such changes therefor often take years to get realized in practice. Is
that what we want?
No; automating these kinds of things is exactly where Fedora should be
going.
I think we very much want a model based on peer review, collective
ownership and automation, not personal fiefdoms and manual integer
increments in text files.
IMO, if you have the script, post it, get some feedback, then just do
it.
8:11 a.m.
New subject: Review queue/FESCo after the merge
On 16.11.2007 22:15, Colin Walters wrote:
On Fri, 2007-11-16 at 20:07 +0100, Thorsten Leemhuis wrote:
> With grep, sed, cvs diff and some small adjustments by hand this change
> could also be done quickly in CVS for all effected packages. I could
> start now and will likely finished the task for all packages in devel
> within less then 30 minutes. But nobody does that, as modifying packages
> that are owned by other people is frowned upon in Fedora land.
> Such changes therefor often take years to get realized in practice. Is
> that what we want?
No; automating these kinds of things is exactly where Fedora should be
going.
Well, I had no script (besides the bumpspecfile one found at
http://cvs.fedora.redhat.com/viewcvs/rebuild-scripts/bumpspecfile.py?root...
) and thus did most of it manually, as writing a script for this sort of
one-time change is likely not worth the trouble.
Results from my work:
http://www.leemhuis.info/files/fedorarpms/MISC.fdr/proper-fc-cache-calls....
@FESCo: so what do do with this? Commit and don't build? The package
owners should see the commit diff and spot errors if I did any.
I think we very much want a model based on peer review, collective
ownership and automation, not personal fiefdoms and manual integer
increments in text files.
+1, ecpecially to "collective ownership and automation"
[...]
CU
knurd
8:45 a.m.
New subject: Review queue/FESCo after the merge
On Sun, 18 Nov 2007 15:11:00 +0100
Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
Results from my work:
http://www.leemhuis.info/files/fedorarpms/MISC.fdr/proper-fc-cache-calls....
@FESCo: so what do do with this? Commit and don't build? The package
owners should see the commit diff and spot errors if I did any.
I have no problem with that, so long as the Fonts SIG is happy with the
change.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
2:43 p.m.
New subject: Review queue/FESCo after the merge
Le dimanche 18 novembre 2007 à 09:45 -0500, Jesse Keating a écrit :
On Sun, 18 Nov 2007 15:11:00 +0100
Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
> Results from my work:
> http://www.leemhuis.info/files/fedorarpms/MISC.fdr/proper-fc-cache-calls....
>
> @FESCo: so what do do with this? Commit and don't build? The package
> owners should see the commit diff and spot errors if I did any.
I have no problem with that, so long as the Fonts SIG is happy with the
change.
I stated when I started the SIG I didn't want the glorious leader
position, so I won't pretend I speak for it, and I'll only object for
the three affected packages I maintain or co-maintain.
If this change is to be done I'll insist his author explain and defend
it on the SIG list, then write a formal FPC proposal, and get this
proposal approved all the way up.
This is a "fix"¹ in search of a problem², and while I've been known to
make gratuitous changes to make a point too³, I've limited myself to my
own packages, and I'll appreciate the same restraint in my fellow
Fedorans.
I don't mind people touching my packages, but only if there are actual
problems to fix.
Regards,
¹ That can actually increase the probability bad packages make it
through QA
² One documented failure in rawhide does not count, if we shot
everything that ever went wrong in rawhide little would be left
³ Yes I'm a bastard too.
--
Nicolas Mailhot
5:55 p.m.
New subject: Review queue/FESCo after the merge
On Sun, 18 Nov 2007 21:43:05 +0100
Nicolas Mailhot <nicolas.mailhot(a)laposte.net> wrote:
I stated when I started the SIG I didn't want the glorious
leader
position, so I won't pretend I speak for it, and I'll only object for
the three affected packages I maintain or co-maintain.
If this change is to be done I'll insist his author explain and defend
it on the SIG list, then write a formal FPC proposal, and get this
proposal approved all the way up.
This is a "fix"¹ in search of a problem², and while I've been known to
make gratuitous changes to make a point too³, I've limited myself to
my own packages, and I'll appreciate the same restraint in my fellow
Fedorans.
So it would seem we're /not/ in agreement on this point. Thorsten, are
you trying to fix a real problem, or just trying to ensure everything
follows a guideline regarding exit failures in %post scriptlets?
--
Jesse Keating
Fedora -- All my bits are free, are yours?
11:56 p.m.
New subject: Review queue/FESCo after the merge
On 19.11.2007 00:55, Jesse Keating wrote:
On Sun, 18 Nov 2007 21:43:05 +0100
Nicolas Mailhot <nicolas.mailhot(a)laposte.net> wrote:
> I stated when I started the SIG I didn't want the glorious leader
> position, so I won't pretend I speak for it, and I'll only object for
> the three affected packages I maintain or co-maintain.
> If this change is to be done I'll insist his author explain and defend
> it on the SIG list, then write a formal FPC proposal, and get this
> proposal approved all the way up.
> This is a "fix"¹ in search of a problem², and while I've been known to
> make gratuitous changes to make a point too³, I've limited myself to
> my own packages, and I'll appreciate the same restraint in my fellow
> Fedorans.
So it would seem we're /not/ in agreement on this point.
Nothing new -- I leave that debate to Nicolas and the Font-SIG together
with you and the other members of the FPC, as I don't care much about it.
Thorsten, are you trying to fix a real problem,
Well, I run into problems once due to the wrong exit code. That was
likely a corner case, but there are likely other corner cases with lead
to the rule spot mentioned ("script should not exit with non-zero exit
code"), which IMHO is a good one.
or just trying to ensure everything
follows a guideline regarding exit failures in %post scriptlets?
I just want to raise the point that FPC creates or modifies rules that
are often not really (or very slowly) being realized in existing the
packages.
Someone in a lot cases (like this one) could just realize many of the
changes in the Packaging Guidelines directly in CVS for all effected
packages. I think we should do that way more often and get away from the
mantra "this is my package and nobody else is allowed to touch it" --
that's why I took this particular issue as example to just show how it
could be done. Now I expect from FESCo advice for this particular
example as well as the general concept where one persons realizes
changes in all effected packages directly in CVS.
CU
knurd
3:55 a.m.
New subject: Review queue/FESCo after the merge
On Mon, Nov 19, 2007 at 06:56:22AM +0100, Thorsten Leemhuis wrote:
Someone in a lot cases (like this one) could just realize many of the
changes in the Packaging Guidelines directly in CVS for all effected
packages. I think we should do that way more often and get away from the
mantra "this is my package and nobody else is allowed to touch it" --
that's why I took this particular issue as example to just show how it
could be done. Now I expect from FESCo advice for this particular
example as well as the general concept where one persons realizes
changes in all effected packages directly in CVS.
I fully agree, but it is already explicitely permitted in
http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToMod...
All is needed is a set of scripts and maybe FESCo taking a lead. One
occasion I see would be the mass rebuild of packages that depend on
doxygen after the 'non reproducible anchors bug' is fixed -- that is
doxygen is updated to latest version.
--
Pat
10:23 a.m.
New subject: Review queue/FESCo after the merge
On 19.11.2007 10:55, Patrice Dumas wrote:
On Mon, Nov 19, 2007 at 06:56:22AM +0100, Thorsten Leemhuis wrote:
> Someone in a lot cases (like this one) could just realize many of the
> changes in the Packaging Guidelines directly in CVS for all effected
> packages. I think we should do that way more often and get away from the
> mantra "this is my package and nobody else is allowed to touch it" --
> that's why I took this particular issue as example to just show how it
> could be done. Now I expect from FESCo advice for this particular
> example as well as the general concept where one persons realizes
> changes in all effected packages directly in CVS.
I fully agree, but it is already explicitely permitted in
http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToMod...
Well, I actually wrote most of it, but reality and documentation are two
different things afaics, thus...
All is needed is a set of scripts and maybe FESCo taking a lead.
...FESCo really is the one that needs to take a lead and say "we want
that". Especially because some of the packages might be protected by
ACLs, which creates further problems.
One
occasion I see would be the mass rebuild of packages that depend on
doxygen after the 'non reproducible anchors bug' is fixed -- that is
doxygen is updated to latest version.
Firefox IMHO is the way better example -- I fail to understand why we
didn't create a script that rebuilds all packages that depend on it once
it's build and in the buildroot. Yes,
* that could delay the firefox push by one hour or a bit more -- small
problem, but not a big one, as stuff often gets delayed by other things
as well (the ones with access to the keys being asleep for example)
* some packages might not compile with the new firefox (but most likely
will)
but that's way better then a broken repo, as a new firefox in the repo
is not much of a help if it won't get installed on the systems by yum,
as most will have yelp or other stuff installed that needs the exact
version of firefox it was build against.
Actually creating such a script was the plan early this year when I
still was FESCo chair, but seems the person that wanted to take care of
it forgot about it in the merge noise (no wonder with all those changes,
so I don't blame him).
CU
knurd
10:49 a.m.
New subject: Review queue/FESCo after the merge
On Mon, 19 Nov 2007 17:23:05 +0100
Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
Firefox IMHO is the way better example -- I fail to understand why
we
didn't create a script that rebuilds all packages that depend on it
once it's build and in the buildroot. Yes,
Again, it takes /somebody/ to write it. FESCo can say all they want "I
want this to happen", but until somebody sits down and cranks out a
script, it's just not going to happen.
Instead many of us are working toward a situation where this one-off
won't be necessary.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
11:41 a.m.
New subject: Review queue/FESCo after the merge
On Mon, 2007-11-19 at 11:49 -0500, Jesse Keating wrote:
On Mon, 19 Nov 2007 17:23:05 +0100
Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
> Firefox IMHO is the way better example -- I fail to understand why we
> didn't create a script that rebuilds all packages that depend on it
> once it's build and in the buildroot. Yes,
Again, it takes /somebody/ to write it. FESCo can say all they want "I
want this to happen", but until somebody sits down and cranks out a
script, it's just not going to happen.
Actually, if I were to imagine things ... if FESCo actually said "I want
this to happen" and takes the necessary management roles to get things
started (ie. a wiki discussion page, a mailing list thread, an ad-hoc
committee, etc.), I imagine a lot of people would be happy. But it's
important for FESCo to actually say it because then it becomes an
official Fedora-sanctioned project and people would know they're not
wasting their time. Also, I don't think people expect FESCo to actually
do the work, but at least do the managerial task of organizing people
willing to work.
If volunteers don't turn up, then FESCo's done all they can.
Instead many of us are working toward a situation where this one-off
won't be necessary.
I doubt it's a one-off thing and avoiding situations like it isn't
always desired.
--
Richi Plana
11:52 a.m.
New subject: semi-automatic firefox rebuilds (was Re: Review queue/FESCo after the merge)
On 19.11.2007 17:49, Jesse Keating wrote:
On Mon, 19 Nov 2007 17:23:05 +0100
Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
> Firefox IMHO is the way better example -- I fail to understand why we
> didn't create a script that rebuilds all packages that depend on it
> once it's build and in the buildroot. Yes,
Again, it takes /somebody/ to write it.
We often say that in Fedora-land -- the result afaics often is: we scare
people away with it.
Sure, there is of course somebody needed, but sorry, especially FESCo
members instead of "Again, it takes /somebody/ to write it." should say
something like "yeah, this could be a solution; is somebody in our
friendly community willing to realize it?" or "yeah, nice idea, but
instead we should do .... to solve the problem is a even better way"
For more complicated tasks there is of course more needed. But just
requesting "do something" won't change anything most of the time --
especially for more comlicated tasks FESCo should say "yeah, we want
something like that; this is how it could look like ..." and guide
people. Then people can be sure than the solution they work out (which
could take many workhours of even days) is at least roughly what FESCo
wants.
FESCo can say all they want "I
want this to happen", but until somebody sits down and cranks out a
script, it's just not going to happen.
Come on, if our leaders are not able to do such a simple thing like this
own their own or find somebody do do it then there really is something
wrong in Fedora-land.
It's really not that hard, even I with my very limited programming
skills (aka "knurd the package monkey") I can do what's needed in just a
few minutes:
/me wanders of to create such a "script"
/me downloads
http://cvs.fedora.redhat.com/viewcvs/rebuild-scripts/bumpspecfile.py?root...
/me adjusts changelog comment
/me copy-and pastes list from
http://fedoraproject.org/wiki/WillWoods/Drafts/FirefoxUpdates
(one could create such a list with manually as well; "repoquery
--whatrequires --alldeps 'firefox = 2.0.0.9' 'gecko-libs = 1.8.1.9'"
or
something like that would be a good start)
/me removes the newlines and created a quick loop in bash
Here is your "script":
---
for package in blam chmsee devhelp epiphany epiphany-extensions firefox
galeon gnome-python2-extras gnome-web-photo gtkmozembedmm kazehakase
liferea Miro openvrml ruby-gnome2 yelp; do
pushd ${package}
bumpspecfile.py *.spec
make tag build
popd
done
---
Find bumpspecfile.py attached. Run it in a full cvs checkout once the
new firefox is in the repo; if you don't have one add a "cvs co
${package}" at the right place and adjust the pushd call.
Before above works one needs to adjust some of the spec files so none
hard-code the gecko-* or firefox-* versions -- or instead use the same
format everywhere witch can be adjusted with a simple sed call. I can't
do that, something like that is unwanted in Fedora-land (see earlier in
this thread). If FESCo gives me the permission I'm of course
volunteering to do it.
Have fun.
CU
knurd
12:02 p.m.
New subject: semi-automatic firefox rebuilds (was Re: Review queue/FESCo after the merge)
On Mon, 19 Nov 2007 18:52:12 +0100
Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
/me removes the newlines and created a quick loop in bash
Here is your "script":
---
for package in blam chmsee devhelp epiphany epiphany-extensions
firefox galeon gnome-python2-extras gnome-web-photo gtkmozembedmm
kazehakase liferea Miro openvrml ruby-gnome2 yelp; do
pushd ${package}
bumpspecfile.py *.spec
make tag build
popd
done
So this is great and all, but it's FF specific, where we're moving to
xulrunner anyway. Time is better spent getting these things to support
xul.
Not that this script isn't handy at all. In fact, I think we (as
Fedora) need to appoint somebody or some "body" (like a SIG) to oversee
the entire gecko stack both now and in the future to ensure that
updates are coordinated. Just building is only one part of the puzzle,
they all have to get pushed out at the same time and into the same
repos.
I don't have the time or energy to own this problem space. I can tell
you from my perspective where the problems are, and take a look at
proposed solutions. Your script may indeed prove very handy to those
that are going to own this problem space, especially if it were tied
into the makefile changes Luke made for auto-filing bodhi push requests.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
1:56 a.m.
New subject: semi-automatic firefox rebuilds (was Re: Review queue/FESCo after the merge)
On 19.11.2007 19:02, Jesse Keating wrote:
On Mon, 19 Nov 2007 18:52:12 +0100
Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
> /me removes the newlines and created a quick loop in bash
> Here is your "script":
> ---
> for package in blam chmsee devhelp epiphany epiphany-extensions
> firefox galeon gnome-python2-extras gnome-web-photo gtkmozembedmm
> kazehakase liferea Miro openvrml ruby-gnome2 yelp; do
> pushd ${package}
> bumpspecfile.py *.spec
> make tag build
> popd
> done
So this is great and all, but it's FF specific, where we're moving to
xulrunner anyway. Time is better spent getting these things to support
xul.
F8 will still be around for about 12 months, which IMHO is more then
enough a reason to warrant one or two of work. Especially as it safes
the maintainers of the packages some work, so in the end less work for
everybody.
BTW, does xulrunner properly and for real solve the problem? The current
rawhide package just as firefox has a path with a version number in it
(/usr/lib64/xulrunner-1.9a9pre/) so I fear that there sill will be
packages taht depend on a particular xulrunner version. Or is there some
abstraction somewhere to make sure packages don't depend on a particular
version of xulrunner?
Not that this script isn't handy at all. In fact, I think we
(as
Fedora) need to appoint somebody or some "body" (like a SIG) to oversee
the entire gecko stack both now and in the future to ensure that
updates are coordinated.
Maybe, yes, but I tend a bit to the "who broke something should at least
do minimal efforts to get it fixed". IOW: the one that rebuilds firefox
should ask rel-eng to put it into the buildroot and call the script once
it really exists.
Just building is only one part of the puzzle,
they all have to get pushed out at the same time and into the same
repos.
With the new bodhi command line interface this shouldn't be to hard afaics.
I don't have the time or energy to own this problem space.
I'd be willing to create the script properly and modify the packages if
I can do it directly in CVS (after a public review of course) if FESCO
backs the effort.
[...]
CU
knurd
2:25 a.m.
New subject: semi-automatic firefox rebuilds (was Re: Review queue/FESCo after the merge)
Thorsten Leemhuis wrote:
On 19.11.2007 19:02, Jesse Keating wrote:
> On Mon, 19 Nov 2007 18:52:12 +0100
> Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
>
>> /me removes the newlines and created a quick loop in bash
>> Here is your "script":
>> ---
>> for package in blam chmsee devhelp epiphany epiphany-extensions
>> firefox galeon gnome-python2-extras gnome-web-photo gtkmozembedmm
>> kazehakase liferea Miro openvrml ruby-gnome2 yelp; do
>> pushd ${package}
>> bumpspecfile.py *.spec
>> make tag build
>> popd
>> done
> So this is great and all, but it's FF specific, where we're moving to
> xulrunner anyway. Time is better spent getting these things to support
> xul.
F8 will still be around for about 12 months, which IMHO is more then
enough a reason to warrant one or two of work. Especially as it safes
the maintainers of the packages some work, so in the end less work for
everybody.
BTW, does xulrunner properly and for real solve the problem? The current
rawhide package just as firefox has a path with a version number in it
(/usr/lib64/xulrunner-1.9a9pre/) so I fear that there sill will be
packages taht depend on a particular xulrunner version. Or is there some
abstraction somewhere to make sure packages don't depend on a particular
version of xulrunner?
I also don't understand. I thought the whole point of having xulrunner
was precisely so we can package it properly using a more classic dynamic
libraries versioning scheme...
-d
6:49 a.m.
New subject: semi-automatic firefox rebuilds
On 11/20/2007 08:56 AM, Thorsten Leemhuis wrote:
BTW, does xulrunner properly and for real solve the problem? The
current
rawhide package just as firefox has a path with a version number in it
(/usr/lib64/xulrunner-1.9a9pre/) so I fear that there sill will be
packages taht depend on a particular xulrunner version. Or is there some
abstraction somewhere to make sure packages don't depend on a particular
version of xulrunner?
Don't expect what's in rawhide right now to be what's in F9. We're
still working hard on getting things done right. This is on the list.
Even so, until the final release is made, xulrunner is still in a
pre-release stage and ABI is not yet guaranteed.
6:58 a.m.
New subject: semi-automatic firefox rebuilds
On 20.11.2007 13:49, Christopher Aillon wrote:
On 11/20/2007 08:56 AM, Thorsten Leemhuis wrote:
> BTW, does xulrunner properly and for real solve the problem? The current
> rawhide package just as firefox has a path with a version number in it
> (/usr/lib64/xulrunner-1.9a9pre/) so I fear that there sill will be
> packages taht depend on a particular xulrunner version. Or is there some
> abstraction somewhere to make sure packages don't depend on a particular
> version of xulrunner?
Don't expect what's in rawhide right now to be what's in F9. We're
still working hard on getting things done right. This is on the list.
Even so, until the final release is made, xulrunner is still in a
pre-release stage and ABI is not yet guaranteed.
k, thx for the clarification, as it looked a bit odd in its current state.
CU
knurd
10:49 a.m.
New subject: Review queue/FESCo after the merge
On Mon, 2007-11-19 at 17:23 +0100, Thorsten Leemhuis wrote:
On 19.11.2007 10:55, Patrice Dumas wrote:
> On Mon, Nov 19, 2007 at 06:56:22AM +0100, Thorsten Leemhuis wrote:
>> Someone in a lot cases (like this one) could just realize many of the
>> changes in the Packaging Guidelines directly in CVS for all effected
>> packages. I think we should do that way more often and get away from the
>> mantra "this is my package and nobody else is allowed to touch it" --
>> that's why I took this particular issue as example to just show how it
>> could be done. Now I expect from FESCo advice for this particular
>> example as well as the general concept where one persons realizes
>> changes in all effected packages directly in CVS.
> I fully agree, but it is already explicitely permitted in
>
http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToMod...
Well, I actually wrote most of it, but reality and documentation are two
different things afaics, thus...
> All is needed is a set of scripts and maybe FESCo taking a lead.
...FESCo really is the one that needs to take a lead and say "we want
that". Especially because some of the packages might be protected by
ACLs, which creates further problems.
You are taking the words right out of my
mouth.
> One
> occasion I see would be the mass rebuild of packages that depend on
> doxygen after the 'non reproducible anchors bug' is fixed -- that is
> doxygen is updated to latest version.
Right. I am wonder when this update
willl happen ;)
Firefox IMHO is the way better example
Other examples:
* The perl base package split so far has not been reflected to quite a
number of perl packages being shipped (Probably because of their
maintainers having lost interest in Fedora).
* The FPG wants to split out static libs and to discontinue them
whenever possible. Several packagers still ship static libs as part of
their devel packages and ignore corresponding requests.
...
Technically, changes related to these topics are close to trivial (and
partially scriptable) for an "experienced user". The "normal"
BZ'em, nag
maintainer and launch AWOL-process if necessary is much more effort and
(at least to me) too inconvenient on most occasions (ie. unless
inevitable for technical reasons).
Ralf
10:57 a.m.
New subject: Review queue/FESCo after the merge
On Mon, 2007-11-19 at 17:49 +0100, Ralf Corsepius wrote:
* The perl base package split so far has not been reflected to quite
a
number of perl packages being shipped (Probably because of their
maintainers having lost interest in Fedora).
To be fair, I fixed most of these a few weeks ago.
~spot
2:01 a.m.
New subject: Review queue/FESCo after the merge
On 19.11.2007 17:49, Ralf Corsepius wrote:
[...]
Technically, changes related to these topics are close to trivial (and
partially scriptable) for an "experienced user". The "normal"
BZ'em, nag
maintainer and launch AWOL-process if necessary is much more effort and
(at least to me) too inconvenient on most occasions (ie. unless
inevitable for technical reasons).
And it seem the overhead is to big for others as well (including me).
We need to get rid of the overhead -- it seems to become more and more a
problem afaics as known problems (most small, others medium sized) don't
get fixed.
Cu
knurd
9:41 a.m.
New subject: Review queue/FESCo after the merge
Matthias Clasen (mclasen(a)redhat.com) said:
> Yes, but fixing every possible application which could ever be
put in a
> scriplet to never, ever, ever fail, even in the cases when failure is
> acceptable (and shouldn't kill the transaction) is a little beyond the
> mandate of the FPC. ;)
If scriptlet are not allowed to ever, ever, fail, then just make rpm
ignore the exit code of scriptlets.
scriptlets should be allowed to fail when the failure is catastrophic
enough. What that is, I'm not sure.
Bill
12:34 p.m.
New subject: Review queue/FESCo after the merge
Le vendredi 16 novembre 2007 à 10:41 -0500, Bill Nottingham a écrit :
Matthias Clasen (mclasen(a)redhat.com) said:
> > Yes, but fixing every possible application which could ever be put in a
> > scriplet to never, ever, ever fail, even in the cases when failure is
> > acceptable (and shouldn't kill the transaction) is a little beyond the
> > mandate of the FPC. ;)
>
> If scriptlet are not allowed to ever, ever, fail, then just make rpm
> ignore the exit code of scriptlets.
scriptlets should be allowed to fail when the failure is catastrophic
enough. What that is, I'm not sure.
scriptlets should be allowed to fail when the benefits of failing
(fixing packages) outweigh the cost of failure (killing transactions for
lots of users). Since so far the only documented failure was in rawhide
(at a time I doubt rawhide was perfectly installable anyway) I question
the need to hide this particular failure.
If official policy was to never fail in scriplets, that should be fixed
at the rpm or yum level. FPC may not be in the business of mandating
code changes generally but refusing to touch our own packaging tools and
embarking instead on an exhausting crusade to catch manually every
single error output in our scriptlets is such an utter waste of packager
time I hope no one ever mandates it in an official way. Software is
there to help people not the other way around.
--
Nicolas Mailhot
12:36 p.m.
New subject: Review queue/FESCo after the merge
Nicolas Mailhot (nicolas.mailhot(a)laposte.net) said:
> scriptlets should be allowed to fail when the failure is
catastrophic
> enough. What that is, I'm not sure.
scriptlets should be allowed to fail when the benefits of failing
(fixing packages) outweigh the cost of failure (killing transactions for
lots of users). Since so far the only documented failure was in rawhide
(at a time I doubt rawhide was perfectly installable anyway) I question
the need to hide this particular failure.
Not all scriptlets abort the transaction anyways, as I recall. %post
certainly doesn't. So, maybe it should just be %pre shouldn't fail.
Bill
1:24 p.m.
New subject: Review queue/FESCo after the merge
On Fri, 16 Nov 2007, Bill Nottingham wrote:
Nicolas Mailhot (nicolas.mailhot(a)laposte.net) said:
>> scriptlets should be allowed to fail when the failure is catastrophic
>> enough. What that is, I'm not sure.
>
> scriptlets should be allowed to fail when the benefits of failing
> (fixing packages) outweigh the cost of failure (killing transactions for
> lots of users). Since so far the only documented failure was in rawhide
> (at a time I doubt rawhide was perfectly installable anyway) I question
> the need to hide this particular failure.
Not all scriptlets abort the transaction anyways, as I recall. %post
certainly doesn't. So, maybe it should just be %pre shouldn't fail.
No scriptlet will abort the transaction, just the package with failing
scriptlet will have its install/upgrade/remove will be aborted.
"We brake for nobody" ;)
- Panu -
4:06 p.m.
New subject: Review queue/FESCo after the merge
Le vendredi 16 novembre 2007 à 13:36 -0500, Bill Nottingham a écrit :
Nicolas Mailhot (nicolas.mailhot(a)laposte.net) said:
> > scriptlets should be allowed to fail when the failure is catastrophic
> > enough. What that is, I'm not sure.
>
> scriptlets should be allowed to fail when the benefits of failing
> (fixing packages) outweigh the cost of failure (killing transactions for
> lots of users). Since so far the only documented failure was in rawhide
> (at a time I doubt rawhide was perfectly installable anyway) I question
> the need to hide this particular failure.
Not all scriptlets abort the transaction anyways, as I recall. %post
certainly doesn't. So, maybe it should just be %pre shouldn't fail.
Well if this particular error never hit stable and never stayed long in
rawhide that's because the failure is immediate the first time someone
actually installs a faulty package, and "fixing" the scriptlet only
increases the probability a problem package will hit stable
Please keep this a brownpaper bag error.
--
Nicolas Mailhot
12:57 p.m.
New subject: Review queue/FESCo after the merge
On Fri, 16 Nov 2007, Bill Nottingham wrote:
Matthias Clasen (mclasen(a)redhat.com) said:
>> Yes, but fixing every possible application which could ever be put in a
>> scriplet to never, ever, ever fail, even in the cases when failure is
>> acceptable (and shouldn't kill the transaction) is a little beyond the
>> mandate of the FPC. ;)
>
> If scriptlet are not allowed to ever, ever, fail, then just make rpm
> ignore the exit code of scriptlets.
scriptlets should be allowed to fail when the failure is catastrophic
enough. What that is, I'm not sure.
Agreed on principle but... The rpm transaction is not unlike a derailed
train - a few red lights from failing scriptlets ain't going to stop it
from wrecking everything that happens to be on its way until it simply
runs out of speed. So the problem is: what exactly is a scriptlet
intentionally failing going to do? It wont stop the transaction anyway...
For the vast majority of cases it'd be far far more useful just to
ignore the status but log the failures to permanent storage (and notify
user at end of transaction). Leaving duplicates behind on upgrades like it
now does is hardly useful behavior to anybody.
Then of course there are packages (typically commercial) that attempt to
prevent installation by non-zero exit from %pre if some conditions aren't
met, but that's totally broken to begin with because it wont prevent the
rest of the transaction from running...
- Panu -
1:16 p.m.
New subject: Review queue/FESCo after the merge
On Fri, 2007-11-16 at 20:57 +0200, Panu Matilainen wrote:
On Fri, 16 Nov 2007, Bill Nottingham wrote:
> Matthias Clasen (mclasen(a)redhat.com) said:
>>> Yes, but fixing every possible application which could ever be put in a
>>> scriplet to never, ever, ever fail, even in the cases when failure is
>>> acceptable (and shouldn't kill the transaction) is a little beyond the
>>> mandate of the FPC. ;)
>>
>> If scriptlet are not allowed to ever, ever, fail, then just make rpm
>> ignore the exit code of scriptlets.
>
> scriptlets should be allowed to fail when the failure is catastrophic
> enough. What that is, I'm not sure.
Agreed on principle but... The rpm transaction is not unlike a derailed
train - a few red lights from failing scriptlets ain't going to stop it
from wrecking everything that happens to be on its way until it simply
runs out of speed. So the problem is: what exactly is a scriptlet
intentionally failing going to do? It wont stop the transaction anyway...
For the vast majority of cases it'd be far far more useful just to
ignore the status but log the failures to permanent storage (and notify
user at end of transaction). Leaving duplicates behind on upgrades like it
now does is hardly useful behavior to anybody.
+1
It confuses people and makes them come and ask me questions.
-sv
8:25 a.m.
New subject: Review queue/FESCo after the merge
On Fri, 2007-11-16 at 14:30 +0100, Nicolas Mailhot wrote:
If guideline changes are being done this way I wonder why I created
a
Fonts SIG, spent days writing fonts packaging guidelines, and
submitted them to FPC (that was supposed to review them for this week
session).
FWIW: This week's meeting failed due to mis-communications related
to
the DST-time switch in the US (one wiki page said 16:00UTC, another one
said 17:00UTC).
Ralf
PS: Your mailer still tears threads apart.
6011
days inactive
6015
days old
34 comments
14 participants
participants (14)
-
Bill Nottingham -
Christopher Aillon -
Colin Walters -
Denis Leroy -
Jesse Keating -
Matthias Clasen -
Nicolas Mailhot -
Panu Matilainen -
Patrice Dumas -
Ralf Corsepius -
Richi Plana -
Seth Vidal -
Thorsten Leemhuis -
Tom Callaway