Re: move to rawhide update (Fedora QA breakage)

2009-04-08 Thread John Gilmore
   II. - What for me is an inhibitor is the bugzilla section tell us 
 how to reproduce the problem.  I have no desire whatsoever to try 

Mikus unfortunately plays a troll on the Internet.  He probably isn't
one in real life, but the way he uses the XO is extremely unusual, so
he views the XO in ways that appear to be 77 degrees away from the
usual viewpoint.  His bug reports require careful interpretation if
you want to avoid immediately discarding them as worthless.

  What good would it do for 
 me to enter a bugzilla report?  A dozen people would ask me for more 
 information, and for more try this and try that.  I have better 
 things to do with my time.

I'm sad to report that I tried to participate in a Fedora QA test
day last week for some particular hardware I have (low end Radeon
graphics).  I filed one clear bug report, and four days later got the
usual please send us lots of irrelevant info form letter.  I filed a
testy reply telling them they don't need it and please stop pretending
to close out bug reports by demanding that the user send some
irrelevant info.  See:

  https://bugzilla.redhat.com/show_bug.cgi?id=493748

One of these irrelevant busybodies self-identifies as one of the
Fedora BugZappers with this link:

  https://fedoraproject.org/wiki/BugZappers

  We are a group of volunteers and Red Hat employees whose primary
  mission is to review and triage bug report submissions on
  bugzilla.redhat.com, acting as a bridge between users and developers
  to aid in fixing and closing bugs.

Now I see what's going on.  Clueless people are crashing around in the
bug database, helping developers by hassling users.  Then if you
don't answer the idiots, 30 days later they close out your bug report
as CLOSED:INSUFFICIENT_DATA.  Instead of a bridge, they seem to be
more of a barrier, though perhaps they do good work somewhere.  I
think these are the same people who also trashed the OLPC
suspend/resume is broken bug report, by running a script that
declared it an obsolete problem that only applied to F10, even though
the problem persists long after F10.  But as the BugZapper credo says,
No programming knowledge is necessary, and triagers don't necessarily
need to understand the bugs they are working on.

So I'll have to agree with Mikus's analysis of why not to bother
filing Red Hat bugzilla bugs.  Idiots will hassle you, and claim
that the bug doesn't exist after all, then close it.  (*)

John

(*): At Cygnus, we wrote a bug tracking system, PRMS.  We made very
sure that nobody except the original submitter could close out a bug
report.  The only thing developers or QA people could do was put the
bug into feedback state, asking the original submitter to confirm
that the bug really is fixed.  I insisted on this process flow because
of the numerous companies I'd reported bugs to, who regularly closed
out my bugs without fixing them -- over and over.  I'd search the bug
reports at Sun and find six people all reporting the same bug I'd
encountered -- and all six of them closed inappropriately by somebody
whose job it was to close bug reports (not to fix bugs).  Cygnus's
customers appreciated the attention, even though it was sometimes a
hassle for us to nudge them to close out the bugs we really HAD fixed.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: move to rawhide update (Fedora QA breakage)

2009-04-08 Thread Peter Robinson
 Now I see what's going on.  Clueless people are crashing around in the
 bug database, helping developers by hassling users.  Then if you
 don't answer the idiots, 30 days later they close out your bug report
 as CLOSED:INSUFFICIENT_DATA.  Instead of a bridge, they seem to be
 more of a barrier, though perhaps they do good work somewhere.  I
 think these are the same people who also trashed the OLPC
 suspend/resume is broken bug report, by running a script that
 declared it an obsolete problem that only applied to F10, even though
 the problem persists long after F10.  But as the BugZapper credo says,
 No programming knowledge is necessary, and triagers don't necessarily
 need to understand the bugs they are working on.

I agree with you to a certain extent. I believe the reason for the
relable as F10 is primarily due to the fact that Fedora is
relatively fast moving. The idiots you refer to are in the case of the
this has been reported in rawhide during the F10 development process
so assigning it to F10 are in fact scripts so are complete idiots.
There's a good reason to assign it from rawhide to the specific
release that it was reported under, its because it moves very quickly.
X is an example of this. There's been massive changes in the last 3-4
fedora releases and for example errors related to input devices
reported in F-9 are completely irrelevant in F-10 because the entire X
input subsystem was replaced. So to be able to see that it was
reported in what became F-9 is important because its going to be
completely different issue in F-10. Just because it gets moved from a
rawhide designator to a F-10 one doesn't mean its closed, and if its
still relevant for rawhide, you can update it. I do so regularly.

As for the bugZappers. no comment :-)

Peter
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: move to rawhide update

2009-04-08 Thread Daniel Drake
2009/4/8 John Gilmore g...@toad.com:
 Since OLPC's upstream is both Linus's kernel releases, and Fedora's
 distributions, there are two upstream places to push OLPC's hardware
 support patches to.  Have we only been trying to get them into one of
 those places (Linus's)?

 The F11 kernel currently carries about 60 patches beyond Linus's version.
 Some are tiny 4kb patches; others are 300KB.  Why aren't any of the
 XO-1 hardware support patches included in the F11 kernel?

I don't think any effort has been made (since layoffs) to get any
kernel patches upstream anywhere, mostly due to time constraints. But
anyone is welcome to step up and do so!

During a quick discussion with Chris and some others we seemed to
agree on the following:
 - regardless of Fedora/F11/F12 status, policies or whatever, the
first thing to do in any case is to get the patches upstream to Linus
 - we haven't actually tried sending our patches specifically to
Fedora (knowing that they aren't quite ready for Linus) - but IMO this
would be a bad idea
 - we don't really know Fedora's kernel policies for accepting
non-upstream patches, or for backporting upstreamed patches into
current Fedora kernels
 - my opinion: getting patches upstream to Linus, or perhaps even as
far as linux-next, would be enough for the fedora kernel maintainers
to include the patches in the F11 release kernel as an update. So
let's not rule out suspend-on-F11.. it's possible that
F11-plus-updates may work in future.

The biggest showstopper right now seems to be finding someone to do
the work of upstreaming the patches. And, in my opinion and
experience, the correct way to do this is to approach upstream saying

hey, we have this weird hardware, how would you like to see the
kernel code crafted? here's a possible patch to act as the basis of
discussions

and *not*

hey, we have this weird hardware, please take our patches as-is
without consideration because we've shipped them internally for 2
years

which makes the task harder (since kernel hacking may be needed as a
result of discussions), but should lead to success :)

Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: move to rawhide update

2009-04-07 Thread Mikus Grinbergs
 I thought now that we're getting closer to the Fedora 11 freeze it
 would be a good time for everyone to where they're at as we move
 towards F-11/9.1.0/olpc-next.

   My biggest current question is:  When on my XO I enter 'yum 
check-update' (using either the latest SoaS2 .iso or the latest 
~cjb/rawhide-xo .img), it tells me that there are more than 220 
packages at the rawhide repositories that are at a more recent 
version level than those provided by the system on my XO.

   Why don't the SoaS/~cjb distributions contain the latest rawhide 
packages ?

 The main and probably most major issues outstanding are the
 kernel/boot process - so
 kernel/initscripts/olpcrd/initscripts/upstart/rainbow collection of
 stuff of which I have no real idea about. Updates?
 
 The remaining issues are mostly either package deps or getting them
 into Fedora.

   If we are talking about 9.1.0, it would be nice if 'sound' and 
'moving pictures' worked in F-11 on the XO.  Currently they don't.

   I agree that 'suspend' (or even power-off on 'shutdown') would 
improve the usability of F-11 on the XO.


mikus


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: move to rawhide update

2009-04-07 Thread Peter Robinson
  My biggest current question is:  When on my XO I enter 'yum check-update'
 (using either the latest SoaS2 .iso or the latest ~cjb/rawhide-xo .img), it
 tells me that there are more than 220 packages at the rawhide repositories
 that are at a more recent version level than those provided by the system on
 my XO.

  Why don't the SoaS/~cjb distributions contain the latest rawhide packages ?

Because rawhide is a daily moving development target. If there's a
large update (like when rawhide was blocked for the creation of
F11-Beta) there could 100s of updates in a day. See the daily rawhide
report on the fedora-devel list for a general overview.

 The main and probably most major issues outstanding are the
 kernel/boot process - so
 kernel/initscripts/olpcrd/initscripts/upstart/rainbow collection of
 stuff of which I have no real idea about. Updates?

 The remaining issues are mostly either package deps or getting them
 into Fedora.

  If we are talking about 9.1.0, it would be nice if 'sound' and 'moving
 pictures' worked in F-11 on the XO.  Currently they don't.

Are there bugzilla reports for these? What do you mean by 'moving
pictures', do you mean recording video or playing video?

  I agree that 'suspend' (or even power-off on 'shutdown') would improve the
 usability of F-11 on the XO.

I believe this is being worked on.

Peter
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: move to rawhide update

2009-04-07 Thread Peter Robinson
   Why don't the SoaS/~cjb distributions contain the latest rawhide packages 
  ?

 Because rawhide is a daily moving development target.

 Aren't you both right?  The builds contain the latest rawhide packages
 as of the image creation date, right?  Thus if it's no longer the
 instant the image was created, rawhide packages may have been updated.

Yes. that is correct. The image is built from the current rawhide at
the time of build. But if the image was based on rawhide from a couple
of days ago (or the F-11 beta) it wouldn't be surprising that there
was 210 package updates.

Peter
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: move to rawhide update

2009-04-07 Thread Greg Dekoenigsberg

On Tue, 7 Apr 2009, p...@laptop.org wrote:

 as mikus said, his applications all worked before.  this is a 
 regression, plain an simple, *with respect to the previous XO releases*. 
 now, to the extent that fedora doesn't really care about any specific 
 piece of hardware, especially one which wasn't running fedora when these 
 things last worked, then i suppose it's appropriate to ignore the 
 issues.

 i think this, and the fact that no one is sure what's broken in the 
 current fedora-on-XO releases, points to huge holes in the OLPC plan of 
 record for ongoing support of this product.  unless some energetic 
 entity is willing to own the actual XO distribution(s), and be 
 responsible for maintaining a bug list, and issuing even minimal release 
 notes, i fear for the project. (or, rather, i fear that the project will 
 be running 8.2 until the laptops die.  which wouldn't be the worst 
 possible outcome, i suppose...  :-/ )

This is what happens when the 95% of the developers working on the project 
get canned.  The unenviable choice becomes:

* Get a community to work from an 8.2 branch that will become more and 
more outdated over time; or

* Get a community to work from a moving target that has a greater chance 
of supporting new features once they're integrated, but is inherently less 
stable for large chunks of the development cycle.

Whichever way you go, strong leadership, patience, and many hands are 
required to fight through the problems.  If the community cares enough and 
develops the necessary leadership, the project moves forward.  But it's 
never easy.

It is my hope that people continue to use the tracking bug here, and 
align bugs to it, and use it to assess fitness of the current release:

https://bugzilla.redhat.com/showdependencytree.cgi?id=461806hide_resolved=1

It may not be the perfect tool, but it's the best we have.

--g

--
Got an XO that you're not using?  Loan it to a needy developer!
   [[ http://wiki.laptop.org/go/XO_Exchange_Registry ]]

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: move to rawhide update

2009-04-07 Thread Peter Robinson
     II. - What for me is an inhibitor is the bugzilla section tell us how 
 to
    reproduce the problem.  I have no desire whatsoever to try to describe 
 how
    to obtain the Fluendo mp3 codec for an XO, nor how to follow its
    instructions for seeing if it works.  I have even less desire to describe
    where I obtained a static-linked Mplayer, nor how I have set up my XO for
    playing movies.  [Both the mp3 codec and the Mplayer application work 
 fine
    in 8.2.1.]  What good would it do for me to enter a bugzilla report?  A
    dozen people would ask me for more information, and for more try this 
 and
    try that.  I have better things to do with my time.
  
   Well, firstly if they're statically compiled applications that aren't
   shipped in Fedora there's no point filing bugs in Fedora about them as
   they aren't supported.

 but surely the APIs that they use _are_ supported, no?

Yes.

   But if your going to have an attitude of its a
   waste of your time, I won't waste my time trying to get them to work
   for you.

 if mikus is having these problems, children with laptops will
 too.  i'm sorry to hear someone who has done a _lot_ of very
 patient bug reporting and testing (and documentation, i believe)
 being dismissed like this.

I'm not dismissing him. I'm quite prepared to help him if he'll
provide the information. I'm someone who has done a _lot_ of very
patient bug testing and trying to get all the OLPC changes to Fedora
upstream so that we have the best release possible.

As for children having these problems, most children will use the
built in video player (totem, not sure of the sugar application), and
then from there there will be local support teams and it will then
move upstream (I believe). I doubt they will be reporting the bugs
direct to the olpc-devel mailing lists.

 no point in filing bugs?  let's all pack it in and go home.
 send the bug reports straight to nicholas.

By no point filing bugs I meant that 80% of fedora package maintainers
will close the bug straight up because its not a package in Fedora and
will ask a bug to be filed with the upstream. Those that don't close
the bug will expect details and ask questions which mikus clearly
stated he couldn't be bothered providing. There's not a lot that can
be done unless he at least states what application it is. He original
stated 'sound' and 'moving pictures', how am I or anyone else
suppose to work out what that means without asking for details such as
the application, what version/build it is and if its not in Fedora
where he got it from. Even Microsoft don't support 3rd party
applications. That's why Fedora refuses to ship binary drivers for
graphics chips and binary applications, it causes alot of
problems. go and search the ubuntu forums or google about video
driver problems.

 that being said, as a developer, i understand that a bug report
 with missing background information is difficult to deal with.
 mikus -- even attaching the static mplayer binary to the bug
 report, with an explanation that it used to work on 8.2, and now
 it doesn't, would be better than nothing.

its not difficult, its impossible.

    What do you mean by 'moving
    pictures', do you mean recording video or playing video?
   
    I don't try to record video - so I have no idea if it works or not (see 
 what
    I mean about being asked questions which I don't know how to answer?).  
 The
    'Record' activity does not show me a picture of what the XO camera is
    supposed to be seeing.  The 'watchlisten' activity gives me neither 
 'sound'
    nor 'moving pictures'.  [IIRC, it can close prematurely.]  Mplayer runs, 
 but
    gives me neither 'sound' nor anything except a blank screen.
  
   I can check the record activity but as mentioned before issues with
   mplayer and mp3 codecs will need  to be reported to where ever you get
   them from.

 as mikus said, his applications all worked before.  this is a
 regression, plain an simple, *with respect to the previous XO releases*.
 now, to the extent that fedora doesn't really care about any
 specific piece of hardware, especially one which wasn't running
 fedora when these things last worked, then i suppose it's
 appropriate to ignore the issues.

Yes, it may well be a regression but if he's using rpms or binary
tarballs compiled against older versions of Fedora that could be the
issue. It could be as simple as directing him to a repository that
contains the best version of mplayer to use on F11 but he's provided
nothing. I'm trying to help but I'm not god, I'm one person and if the
person that wants help isn't prepared to do some legwork why should I.
I do this in my free time and I due to the lack of people on the
project I could spend every spare second of waking time on it and
still not have every done.

 i think this, and the fact that no one is sure what's broken in
 the current fedora-on-XO releases, points to huge holes in the
 OLPC plan of record for ongoing support 

Re: move to rawhide update

2009-04-07 Thread Mikus Grinbergs
  If we are talking about 9.1.0, it would be nice if 'sound' and
  'moving pictures' worked in F-11 on the XO. Currently they don't.
 
  Are there bugzilla reports for these?

  I. - I haven't figured out how to do an exhaustive search on 
bugzilla.  'OLPC' picks up some; 'XO' picks up some; '461806' picks 
up some.  But let me emphasize once again - bugzilla appears to be 
aimed at the problems of developers (and isn't optimal for users).

  II. - What for me is an inhibitor is the bugzilla section tell us 
how to reproduce the problem.  I have no desire whatsoever to try 
to describe how to obtain the Fluendo mp3 codec for an XO, nor how 
to follow its instructions for seeing if it works.  I have even less 
desire to describe where I obtained a static-linked Mplayer, nor how 
I have set up my XO for playing movies.  [Both the mp3 codec and the 
Mplayer application work fine in 8.2.1.]  What good would it do for 
me to enter a bugzilla report?  A dozen people would ask me for more 
information, and for more try this and try that.  I have better 
things to do with my time.

  What do you mean by 'moving
  pictures', do you mean recording video or playing video?

I don't try to record video - so I have no idea if it works or not 
(see what I mean about being asked questions which I don't know how 
to answer?).  The 'Record' activity does not show me a picture of 
what the XO camera is supposed to be seeing.  The 'watchlisten' 
activity gives me neither 'sound' nor 'moving pictures'.  [IIRC, it 
can close prematurely.]  Mplayer runs, but gives me neither 'sound' 
nor anything except a blank screen.


mikus
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: move to rawhide update

2009-04-07 Thread Peter Robinson
 Are there bugzilla reports for these?

  I. - I haven't figured out how to do an exhaustive search on bugzilla.
  'OLPC' picks up some; 'XO' picks up some; '461806' picks up some.  But let
 me emphasize once again - bugzilla appears to be aimed at the problems of
 developers (and isn't optimal for users).

You don't need to do an exhaustive search on bugzilla. You just need
to search against the component that's causing issues. eg totem media
player. Generally most components will have  10 bugs so its easy to
see if its an issue for the component.

  II. - What for me is an inhibitor is the bugzilla section tell us how to
 reproduce the problem.  I have no desire whatsoever to try to describe how
 to obtain the Fluendo mp3 codec for an XO, nor how to follow its
 instructions for seeing if it works.  I have even less desire to describe
 where I obtained a static-linked Mplayer, nor how I have set up my XO for
 playing movies.  [Both the mp3 codec and the Mplayer application work fine
 in 8.2.1.]  What good would it do for me to enter a bugzilla report?  A
 dozen people would ask me for more information, and for more try this and
 try that.  I have better things to do with my time.

Well, firstly if they're statically compiled applications that aren't
shipped in Fedora there's no point filing bugs in Fedora about them as
they aren't supported. But if your going to have an attitude of its a
waste of your time, I won't waste my time trying to get them to work
for you.

 What do you mean by 'moving
 pictures', do you mean recording video or playing video?

 I don't try to record video - so I have no idea if it works or not (see what
 I mean about being asked questions which I don't know how to answer?).  The
 'Record' activity does not show me a picture of what the XO camera is
 supposed to be seeing.  The 'watchlisten' activity gives me neither 'sound'
 nor 'moving pictures'.  [IIRC, it can close prematurely.]  Mplayer runs, but
 gives me neither 'sound' nor anything except a blank screen.

I can check the record activity but as mentioned before issues with
mplayer and mp3 codecs will need  to be reported to where ever you get
them from.

Peter
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: move to rawhide update

2009-04-07 Thread pgf
peter, and greg --

greg wrote:
  Whichever way you go, strong leadership, patience, and many hands are 
  required to fight through the problems.  If the community cares enough and 
  develops the necessary leadership, the project moves forward.  But it's 
  never easy.
  
  It is my hope that people continue to use the tracking bug here, and 
  align bugs to it, and use it to assess fitness of the current release:
  
  https://bugzilla.redhat.com/showdependencytree.cgi?id=461806hide_resolved=1

of course.  but the whole thing feels a lot like telling someone
that their local dealership has closed, and they should write to
the car's manufacturer for information about oil changes.  the
scale of the solution doesn't match the needs of the problem. 
(the analogy is shaky, i agree.)

but as an example -- if bugs filed against the XO will be
summarily closed by the developers because it's not our problem,
file it upstream, the larger OLPC community will be ill-served.

users of the XO are not typical open-source enthusiasts, and
they're not the audience that current linux distributions are
used to targeting.  the XO isn't a general purpose laptop, and
was never intended to be.  it's better considered a device,
with special needs, and as such i think it will be under-served
by the new generic release and support scheme.  while i agree
that the current plan is probably the best we can come up with, i
remain frustrated.

thanks.  and sorry for the non-technical venting...  believe me,
the real target of my rant is not the folks like you two who are
continuing the mission.

paul
=-
 paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: move to rawhide update

2009-04-07 Thread Greg Dekoenigsberg

On Tue, 7 Apr 2009, p...@laptop.org wrote:

 peter, and greg --

 greg wrote:
  Whichever way you go, strong leadership, patience, and many hands are
  required to fight through the problems.  If the community cares enough and
  develops the necessary leadership, the project moves forward.  But it's
  never easy.
 
  It is my hope that people continue to use the tracking bug here, and
  align bugs to it, and use it to assess fitness of the current release:
 
  https://bugzilla.redhat.com/showdependencytree.cgi?id=461806hide_resolved=1

 of course.  but the whole thing feels a lot like telling someone that 
 their local dealership has closed, and they should write to the car's 
 manufacturer for information about oil changes.  the scale of the 
 solution doesn't match the needs of the problem. (the analogy is shaky, 
 i agree.)

 but as an example -- if bugs filed against the XO will be summarily 
 closed by the developers because it's not our problem, file it 
 upstream, the larger OLPC community will be ill-served.

s/larger OLPC community/larger open source community/

Because, of course, this is not a problem experienced only by OLPC.  This 
painful problem is central to every distro provider.  The answer is a 
comprehensive ecosystem-wide mechanism for distributed defect tracking, 
and we are years away from that solution, I suspect.

 users of the XO are not typical open-source enthusiasts, and they're not 
 the audience that current linux distributions are used to targeting. 
 the XO isn't a general purpose laptop, and was never intended to be. 
 it's better considered a device, with special needs, and as such i 
 think it will be under-served by the new generic release and support 
 scheme.  while i agree that the current plan is probably the best we can 
 come up with, i remain frustrated.

Yeah, me too.  The hope continues to be that we can stabilize and maintain 
the base, and then focus on the deltas that set the device apart.  But 
it's a hard problem, made harder by a lack of resources.

 thanks.  and sorry for the non-technical venting...  believe me,
 the real target of my rant is not the folks like you two who are
 continuing the mission.

I know, dude.  It's okay.  If you have any suggestions, believe me, I'm 
happy to hear them.  :)

--g

--
Got an XO that you're not using?  Loan it to a needy developer!
   [[ http://wiki.laptop.org/go/XO_Exchange_Registry ]]

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: move to rawhide update

2009-04-07 Thread John Gilmore
 The main and probably most major issues outstanding are the
 kernel/boot process - so
 kernel/initscripts/olpcrd/initscripts/upstart/rainbow collection of
 stuff of which I have no real idea about. Updates?

It's pretty trivial to disable Rainbow, whereas it's not trivial to
get maintainers of half a dozen packages to adopt patches that let
them deal with Rainbow.  So if you want F11 to work on OLPC, disabling
Rainbow's UID fiddling in the version of Sugar that ships in F11 is
the obvious short-term cure.

Some of the initscript changes related to the bizarre idea of running
the anti-theft process as pid 1 so it couldn't be killed by root.
This required changing init so it didn't run as pid 1.  This is
trivial to fix by running the anti-theft process (which is a no-op
loop on most OLPCs anyway, and should in a sane world merely exit) on
some other pid, and running init where it belongs.

It looks like perhaps the kernel changes have slipped right through
the F11 schedule.  Is it seriously likely that the F11 kernel
maintainers would adopt a pile of OLPC patches that aren't in the
upstream kernel, between the Beta and the Final F11 releases?  Had
these changes been adopted (by Fedora or by the Linux kernel) early in
the release cycle, they could've been well tested to make sure they
don't introduce any problems into non-OLPC hardware.  But now, it
appears that F11 won't be able to suspend on OLPC, which makes it
almost useless for laptop use (as opposed to developer use when the
laptop is sitting on a desk with permanent AC power).  Such is the
price of firing all of your kernel developers.

Even the bug report that tracks the kernel power management changes
has fallen into disarray (the Fedora Bug Zapper zapped it in November
and nobody has bothered to fix it since):

  https://bugzilla.redhat.com/show_bug.cgi?id=465284

John
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: move to rawhide update

2009-04-07 Thread pgf
john wrote:
  It looks like perhaps the kernel changes have slipped right through
  the F11 schedule.  Is it seriously likely that the F11 kernel

for the record, this was a conscious decision.  everyone knew there
wouldn't be time to get XO-specific changes upstream, and back to
fedora, before F11.  as you say, it was the cost of going broke.

the challenge is now to get those changes upstream in time for F12.

  maintainers would adopt a pile of OLPC patches that aren't in the
  upstream kernel, between the Beta and the Final F11 releases?  Had
  these changes been adopted (by Fedora or by the Linux kernel) early in
  the release cycle, they could've been well tested to make sure they
  don't introduce any problems into non-OLPC hardware.  But now, it
  appears that F11 won't be able to suspend on OLPC, which makes it
  almost useless for laptop use (as opposed to developer use when the
  laptop is sitting on a desk with permanent AC power).  Such is the

i think the plan is to make an OLPC-patched kernel available for
the distribution creators.

paul

  price of firing all of your kernel developers.
  
  Even the bug report that tracks the kernel power management changes
  has fallen into disarray (the Fedora Bug Zapper zapped it in November
  and nobody has bothered to fix it since):
  
https://bugzilla.redhat.com/show_bug.cgi?id=465284
  
   John
  
  ___
  Fedora-olpc-list mailing list
  fedora-olpc-l...@redhat.com
  https://www.redhat.com/mailman/listinfo/fedora-olpc-list

=-
 paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: move to rawhide update

2009-04-07 Thread Chris Ball
Hi John,

It's pretty trivial to disable Rainbow, whereas it's not trivial to
get maintainers of half a dozen packages to adopt patches that let
them deal with Rainbow.

Yes, we aren't using rainbow in the F11 builds.

Some of the initscript changes related to the bizarre idea of
running the anti-theft process as pid 1 so it couldn't be killed
by root.

Or this.

But now, it appears that F11 won't be able to suspend on OLPC,
which makes it almost useless for laptop use (as opposed to
developer use when the laptop is sitting on a desk with permanent
AC power).

Sure, but you can install a different kernel on your F11 image, such as
OLPC's custom kernel (this has already been tested working), or just
the minimum set of patches to the F11 kernel that add suspend/resume
support, as Scott Douglass and Martin Dengler have been looking at
recently.

I hope we can get some power management patches (even if they're basic
patches rather than everything we have) upstream and back for F12.  We
started the F11 project with the knowledge that we wouldn't be able to
get much of what we need upstream and back in time for its release.

Thanks,

- Chris.
-- 
Chris Ball   c...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: move to rawhide update

2009-04-07 Thread Peter Robinson
Paul,

   Whichever way you go, strong leadership, patience, and many hands are
   required to fight through the problems.  If the community cares enough and
   develops the necessary leadership, the project moves forward.  But it's
   never easy.
  
   It is my hope that people continue to use the tracking bug here, and
   align bugs to it, and use it to assess fitness of the current release:
  
   
 https://bugzilla.redhat.com/showdependencytree.cgi?id=461806hide_resolved=1

 of course.  but the whole thing feels a lot like telling someone
 that their local dealership has closed, and they should write to
 the car's manufacturer for information about oil changes.  the
 scale of the solution doesn't match the needs of the problem.
 (the analogy is shaky, i agree.)

I agree with you here to a degree, but also by getting the Fedora
community involved you also get 1000s of extra bug testers, coders,
and community which I think in time will have much more of a positive
effect than negative. Unfortunately in the short term while everything
gets moved upstream and settles out there will be some pain.

 but as an example -- if bugs filed against the XO will be
 summarily closed by the developers because it's not our problem,
 file it upstream, the larger OLPC community will be ill-served.

They won't be summarily closed if they are related to Fedora, but if
its the other application that is broken its very standard. I had
Microsoft do exactly the same at work the other day when it was proven
that it was a vendors AV causing the problem. Of course this will also
depend on the package maintainer and how responsive the reporter is.
For things like 3rd party stuff it might be worthwhile
using/recommending some of the recognised fedora repos for mp3 stuff
etc. I'm not sure how that would need to be handled from a legal
perspective.

 users of the XO are not typical open-source enthusiasts, and
 they're not the audience that current linux distributions are
 used to targeting.  the XO isn't a general purpose laptop, and
 was never intended to be.  it's better considered a device,
 with special needs, and as such i think it will be under-served
 by the new generic release and support scheme.  while i agree
 that the current plan is probably the best we can come up with, i
 remain frustrated.

Also most XO users will probably unlikely to go and get software
that's not distributed through a supported stream such as a school
server or fedora repos. While the current situation isn't ideal but it
was my understanding that alot of the support was being moved to
country based teams which would then liaise with upstream
OLPC/sugarlabs/fedora so it might well work ok as that gets
implemented.

 thanks.  and sorry for the non-technical venting...  believe me,
 the real target of my rant is not the folks like you two who are
 continuing the mission.

Its not an issue. We're all hear for the same reason and probably all
frustrated for various reason. I came in at the very end of the 8.2.0
dev cycle. With the changes I've some how got a lot more involved than
I originally planned I started getting involved with small Fedora
devices because I wanted to help with a spin for Netbooks that's
sort of been replaced with this :-)

Peter
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: move to rawhide update

2009-04-07 Thread Peter Robinson
Hi Chris,

    It's pretty trivial to disable Rainbow, whereas it's not trivial to
    get maintainers of half a dozen packages to adopt patches that let
    them deal with Rainbow.

 Yes, we aren't using rainbow in the F11 builds.

    Some of the initscript changes related to the bizarre idea of
    running the anti-theft process as pid 1 so it couldn't be killed
    by root.

 Or this.

    But now, it appears that F11 won't be able to suspend on OLPC,
    which makes it almost useless for laptop use (as opposed to
    developer use when the laptop is sitting on a desk with permanent
    AC power).

 Sure, but you can install a different kernel on your F11 image, such as
 OLPC's custom kernel (this has already been tested working), or just
 the minimum set of patches to the F11 kernel that add suspend/resume
 support, as Scott Douglass and Martin Dengler have been looking at
 recently.

 I hope we can get some power management patches (even if they're basic
 patches rather than everything we have) upstream and back for F12.  We
 started the F11 project with the knowledge that we wouldn't be able to
 get much of what we need upstream and back in time for its release.

So is that trying to get them into 2.6.30?

Peter
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: move to rawhide update

2009-04-07 Thread Chris Ball
Hi,

So is that trying to get them into 2.6.30?

Yes, that would be ideal.

- Chris.
-- 
Chris Ball   c...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: move to rawhide update

2009-04-07 Thread Kevin Sonney
Given everything discussed so far, is it worth considering an F11-OLPC
branch, with the intent of merging with F12?

-- Kevin Sonney
-- ke...@sonney.com

“Around here, however, we don’t look backwards for very long. We keep
moving forward, opening up new doors and doing new things… and
curiosity keeps leading us down new paths.”
–Walt Disney

I check email a couple times daily; to reach me sooner, click here:
http://awayfind.com/ksonney
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: move to rawhide update

2009-04-07 Thread Martin Dengler
On Tue, Apr 07, 2009 at 05:17:09PM +0100, Peter Robinson wrote:
   Why don't the SoaS/~cjb distributions contain the latest rawhide packages ?
 
 Because rawhide is a daily moving development target.

Aren't you both right?  The builds contain the latest rawhide packages
as of the image creation date, right?  Thus if it's no longer the
instant the image was created, rawhide packages may have been updated.

  [mikus]
 Peter

Martin


pgplabmuIFC50.pgp
Description: PGP signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel