1:07 p.m.
On Sun, 4 Apr 2010 21:25:51 +0200, RPM wrote:
http://bugzilla.rpmfusion.org/show_bug.cgi?id=569
--- Comment #10 from Thorsten Leemhuis 2010-04-04 21:25:50 ---
(In reply to comment #9)
> Is this problem fixed ?
I would not call it a problem, more a RFE -- for something that even Fedora
sill doesn't do iirc
but whatever: seems this is one of the dozens of things in RPM Fusion that
really would be nice to fix or improved, without anybody working on it :-((
(and most of the other things that need to get improved are way more important
IMHO)
RFEs like this are in need of _somebody_ to make decisions.
In particular: Is using "gpg-agent" an option? (I think it is)
Would using "expect" be considered acceptable? (I don't like it)
As I've mentioned in that bz ticket last year, a repomdsigncmds feature is
available in the pushscripts. It just needs to be configured _and_
evaluated. Without using gpg-agent (or expect), one would need to enter
the key passphrase too often (IMO), however. Has anyone followed the
development of the signing server (and its requirements)?
A fundamental problem with RPMFusion is that at the management level there
is no work-horse to "just do it", i.e. to decide on something and work
with contributors on feasible solutions. Where something sucks, it needs
somebody to say "we want to improve in that area" and to put something
onto an agenda (or call it "wishlist").
3:32 p.m.
New subject: [Bug 569] please gpg-sign repomd.xml files, enable repo_gpgcheck=1 in yum .repo files
On Thu, Apr 8, 2010 at 3:07 PM, Michael Schwendt <mschwendt(a)gmail.com> wrote:
On Sun, 4 Apr 2010 21:25:51 +0200, RPM wrote:
> http://bugzilla.rpmfusion.org/show_bug.cgi?id=569
>
>
>
>
>
> --- Comment #10 from Thorsten Leemhuis 2010-04-04 21:25:50 ---
> (In reply to comment #9)
> > Is this problem fixed ?
>
> I would not call it a problem, more a RFE -- for something that even Fedora
> sill doesn't do iirc
>
> but whatever: seems this is one of the dozens of things in RPM Fusion that
> really would be nice to fix or improved, without anybody working on it :-((
> (and most of the other things that need to get improved are way more important
> IMHO)
RFEs like this are in need of _somebody_ to make decisions.
In particular: Is using "gpg-agent" an option? (I think it is)
Would using "expect" be considered acceptable? (I don't like it)
Why not talk about that on rpmfusion-sysadmin list as well?
As I've mentioned in that bz ticket last year, a repomdsigncmds feature is
available in the pushscripts. It just needs to be configured _and_
evaluated. Without using gpg-agent (or expect), one would need to enter
the key passphrase too often (IMO), however. Has anyone followed the
development of the signing server (and its requirements)?
I did.
A fundamental problem with RPMFusion is that at the management level there
is no work-horse to "just do it", i.e. to decide on something and work
with contributors on feasible solutions. Where something sucks, it needs
somebody to say "we want to improve in that area" and to put something
onto an agenda (or call it "wishlist").
That what i used to say to the list and... as usual noone step up
except jeroen, nicolas and anvil to "just do it" (on the build and CVS side).
AFAIK, we always work that way.
i.e RPM Fusion was looking for help on having a Account system (FAS1
which was running but broken), i did step up and ask for improve
things and dit it with FAS2.
--
Xavier.t Lamien
--
http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB
8:20 p.m.
New subject: [Bug 569] please gpg-sign repomd.xml files, enable repo_gpgcheck=1 in yum .repo files
Xavier Lamien wrote:
That what i used to say to the list and... as usual noone step up
except jeroen, nicolas and anvil to "just do it" (on the build and CVS
side). AFAIK, we always work that way.
The problem is that nobody else has the access required to "just do it".
People have offered help with various tasks on several occasions, they never
got the required access.
Kevin Kofler
9:55 p.m.
New subject: Fusionbuilder64 hangs, but still seems available.
Anyone can fix it?
Chen Lei
1:48 p.m.
New subject: [Bug 569] please gpg-sign repomd.xml files, enable repo_gpgcheck=1 in yum .repo files
On 08.04.2010 15:07, Michael Schwendt wrote:
On Sun, 4 Apr 2010 21:25:51 +0200, RPM wrote:
> http://bugzilla.rpmfusion.org/show_bug.cgi?id=569
> --- Comment #10 from Thorsten Leemhuis 2010-04-04 21:25:50 ---
> (In reply to comment #9)
>> Is this problem fixed ?
> I would not call it a problem, more a RFE -- for something that even Fedora
> sill doesn't do iirc
> but whatever: seems this is one of the dozens of things in RPM Fusion that
> really would be nice to fix or improved, without anybody working on it :-((
> (and most of the other things that need to get improved are way more important
> IMHO)
RFEs like this are in need of _somebody_ to make decisions.
I would agree for most RFE's.
But not for this specific RFE: There is (afaics) no real downside for
users. So there is not much to discuss IMHO, it just needs somebody to
do it and work out the details -- and start a privte or public
discussion in case problems emerge where a discussion and a decision is
needed.
But discussing that without knowing that anybody will work further on it
seems like a lot of wasted time for me.
[...]
A fundamental problem with RPMFusion is that at the management level there
is no work-horse to "just do it", i.e. to decide on something and work
with contributors on feasible solutions.
I partly did that in the past, but as I said multiple times: I don't
want to anymore for now and I'm willing to support individuals or
(preferred better) a group of people that want to take of steering and
"governing" RPM Fusion.
Where something sucks, it needs
somebody to say "we want to improve in that area" and to put something
onto an agenda (or call it "wishlist").
Maybe yes, but in RPM Fusion that IMHO didn't help much until now, as we
are (afaics) to few people. Take the repoclosure scripts for example --
it now years ago was definitely planed to run them after each push and
you even did some groudwork to make it easy for our sysadmins to
integrate (thx again for that), but they never got installed on our
servers (and there were many situations where the lack of automated
repoclosure scripts was discussed on this list, so it was never really
forgotten).
Cu
knurd
10:39 p.m.
New subject: [Bug 569] please gpg-sign repomd.xml files, enable repo_gpgcheck=1 in yum .repo files
On Sat, 10 Apr 2010 15:48:36 +0200, Thorsten wrote:
>> IMHO)
> RFEs like this are in need of _somebody_ to make decisions.
I would agree for most RFE's.
But not for this specific RFE: There is (afaics) no real downside for
users. So there is not much to discuss IMHO, it just needs somebody to
do it and work out the details -- and start a privte or public
discussion in case problems emerge where a discussion and a decision is
needed.
But discussing that without knowing that anybody will work further on it
seems like a lot of wasted time for me.
Work on _what_? The bugzilla ticket has not seen any reply since May 2009.
No feedback, no discussion, no progress, no effort spent on researching
alternative solutions. Plus: koji+bodhi for rpmfusion has been mentioned
a year ago (or even before that), with no status updates or public discussion.
As where you see "a lot of wasted time", dunno. Lengthy discussions
are _not_ needed. (Though, somebody who will switch to koji+bodhi+mash
must consider the consequences, e.g. very likely increased maintenance
requirements). Time _is_ wasted, when after many months old/unchanged
software is still being used, and suddenly there is a need (or request)
to add something to it. Sometimes that means that months pass without
even small steps being made.
> Where something sucks, it needs
> somebody to say "we want to improve in that area" and to put something
> onto an agenda (or call it "wishlist").
Maybe yes, but in RPM Fusion that IMHO didn't help much until now, as we
are (afaics) to few people. Take the repoclosure scripts for example --
it now years ago was definitely planed to run them after each push and
you even did some groudwork to make it easy for our sysadmins to
integrate (thx again for that), but they never got installed on our
servers (and there were many situations where the lack of automated
repoclosure scripts was discussed on this list, so it was never really
forgotten).
Over the past months, I have replied to several people who had contacted
me about broken deps reports (even EPEL related once more). I've seen
nothing else than promises. No one has returned with specific questions
about yum-util's original repoclosure. No one has sent any feedback,
no one has shown any credible interest in creating broken deps reports
and/or in collaborating on related helper scripts (Python and/or bash).
Running repoclosure (the original one or the modified one) with
different options for different sets of repositories isn't a lot of
home work. It's a tool like many others (e.g. repoquery, repodiff).
Except that anyone, who really wants to start using it, will need
to give it a try and gain a little bit of experience while doing so.
The larger excercise has been to fix it, to port it (to Yum APIs),
to hack it -- and to keep helper/report scripts running -- but such
activity can be distributed between a tool's users and its developers.
5369
days inactive
5371
days old
rpmfusion-developers@lists.rpmfusion.org
5 comments
5 participants
participants (5)
-
Chen Lei -
Kevin Kofler -
Michael Schwendt -
Thorsten Leemhuis -
Xavier Lamien