headers
bugzilla-daemon | 1 Jun 2005 01:02

[Bug 50] glibc_cvs.bb doesn't compile

http://bugs.openembedded.org/show_bug.cgi?id=50

------- Additional Comments From bero <at> arklinux.org  2005-05-31 16:02 -------
Created an attachment (id=13)
 --> (http://bugs.openembedded.org/attachment.cgi?id=13&action=view)
New glibc_cvs.bb, adapted to the CVS changes

Adding fix

--

-- 
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
Michael 'Mickey' Lauer | 1 Jun 2005 10:34
Picon
Picon

Re: /media/ram on c7x0 machines

Am Dienstag, den 31.05.2005, 22:42 +0000 schrieb Luke-Jr:
> On Tuesday 31 May 2005 21:24, Koen Kooi wrote:
> > As seen on (strangely enough) on oz-devel:
> 
> Which is for Zaurus-specific OE stuff, according to mickey...

Exactly. Since OE-based distributions are very similar, I see the 
familiar list (which I'm also on) as the ipaq hardware specific list and
the openzaurus list as the zaurus hardware specific list.

This list (oe <at> handhelds.org) should IMO primarily be for hardware
independent packaging and generic distro issues.

Seeing familiar and openzaurus (and simpad-general) as
hardware-specific-issues lists would also support our mergin strategy.

I'll respond on-topic to oz-devel ;)

Regards,

Mickey.
------------------------------------------------------------------
Dipl.-Inf. Michael 'Mickey' Lauer <mickey <at> tm.cs.uni-frankfurt.de>
------------------------------------------------------------------
Permalink | Reply | 5 comments |
headers
Koen Kooi | 1 Jun 2005 10:57

Re: /media/ram on c7x0 machines


Michael 'Mickey' Lauer wrote:
> Am Dienstag, den 31.05.2005, 22:42 +0000 schrieb Luke-Jr:
> 
>>On Tuesday 31 May 2005 21:24, Koen Kooi wrote:
>>
>>>As seen on (strangely enough) on oz-devel:
>>
>>Which is for Zaurus-specific OE stuff, according to mickey...
> 
> 
> Exactly. Since OE-based distributions are very similar, I see the 
> familiar list (which I'm also on) as the ipaq hardware specific list and
> the openzaurus list as the zaurus hardware specific list.

That only works *if* OZ was the *only* distro running on zauri *and*
every person doing OE devel who owns a Z is on that list. That just
isn't so. This 'split' is especially funny since the OZ people insist on
using the OE bugtracker for OZ too. A 'hypocrisy' alarm is going off in
my head.

> This list (oe <at> handhelds.org) should IMO primarily be for hardware
> independent packaging and generic distro issues.

How many distro's have to be running on a clamshell to make it a
'generic' issue?

> Seeing familiar and openzaurus (and simpad-general) as
> hardware-specific-issues lists would also support our mergin strategy.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Michael 'Mickey' Lauer | 1 Jun 2005 11:14
Picon
Picon

Re: /media/ram on c7x0 machines

In general: Could you please stop distinguishing the "familiar" people
and the "openzaurus" people? I thought we agreed that we are one
community and the only differences are a couple of people having just
one target device.

> > Exactly. Since OE-based distributions are very similar, I see the 
> > familiar list (which I'm also on) as the ipaq hardware specific list and
> > the openzaurus list as the zaurus hardware specific list.
> 
> That only works *if* OZ was the *only* distro running on zauri *and*
> every person doing OE devel who owns a Z is on that list. That just
> isn't so. This 'split' is especially funny since the OZ people insist on
> using the OE bugtracker for OZ too. A 'hypocrisy' alarm is going off in
> my head.

Huh? Please forget the "open" in "openzaurus". We will rename it if it
bothers you so much. I think it is a good idea to have a list for common
things (as for example the nslu people are very little interested in
ipaq or zaurus things) and lists for the two major platform families,
which happen to be ipaq and zaurus.

> > This list (oe <at> handhelds.org) should IMO primarily be for hardware
> > independent packaging and generic distro issues.
> 
> How many distro's have to be running on a clamshell to make it a
> 'generic' issue?

Huh? See above.

> > Seeing familiar and openzaurus (and simpad-general) as
(Continue reading)

Permalink | Reply | 3 comments |
headers
bugzilla-daemon | 1 Jun 2005 11:31

[Bug 52] New: Bin-utils fails to compile. Bison seems to be in an infinite loop.

http://bugs.openembedded.org/show_bug.cgi?id=52

           Summary: Bin-utils fails to compile. Bison seems to be in an
                    infinite loop.
           Product: Openembedded
           Version: unspecified
          Platform: ARM
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Build
        AssignedTo: oe <at> handhelds.org
        ReportedBy: stefan <at> hauser.tv

Bin-utils fails to compile. Bison seems to be in an infinite loop. I waited for
8 hours oh an gigahertz machine with 768 MB RAM.

--

-- 
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Jun 2005 11:49

[Bug 52] Bin-utils fails to compile. Bison seems to be in an infinite loop.

http://bugs.openembedded.org/show_bug.cgi?id=52

------- Additional Comments From pb <at> reciva.com  2005-06-01 02:49 -------
I think Mickey checked in a fix for this a couple of days ago.  Update your tree
and try again.

--

-- 
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
Koen Kooi | 1 Jun 2005 11:50

Re: /media/ram on c7x0 machines


Michael 'Mickey' Lauer wrote:
> In general: Could you please stop distinguishing the "familiar" people
> and the "openzaurus" people? I thought we agreed that we are one
> community and the only differences are a couple of people having just
> one target device.

The question about a /media/ram affects more than one device. We need a
policy for stuff like that, and that policy should be distro
independant. That's is going to be hard if you insist on using the OZ
list for that. Maybe the nslu2 people like the idea, maybe they don't,
but your shutting them out.

> 
> 
>>>Exactly. Since OE-based distributions are very similar, I see the 
>>>familiar list (which I'm also on) as the ipaq hardware specific list and
>>>the openzaurus list as the zaurus hardware specific list.
>>
>>That only works *if* OZ was the *only* distro running on zauri *and*
>>every person doing OE devel who owns a Z is on that list. That just
>>isn't so. This 'split' is especially funny since the OZ people insist on
>>using the OE bugtracker for OZ too. A 'hypocrisy' alarm is going off in
>>my head.
> 
> 
> Huh? Please forget the "open" in "openzaurus". We will rename it if it
> bothers you so much. I think it is a good idea to have a list for common
> things (as for example the nslu people are very little interested in
> ipaq or zaurus things) and lists for the two major platform families,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael 'Mickey' Lauer | 1 Jun 2005 12:09
Picon
Picon

Re: /media/ram on c7x0 machines

Am Mittwoch, den 01.06.2005, 11:50 +0200 schrieb Koen Kooi:
> Michael 'Mickey' Lauer wrote:
> > In general: Could you please stop distinguishing the "familiar" people
> > and the "openzaurus" people? I thought we agreed that we are one
> > community and the only differences are a couple of people having just
> > one target device.
> 
> The question about a /media/ram affects more than one device. We need a
> policy for stuff like that, and that policy should be distro
> independant. That's is going to be hard if you insist on using the OZ
> list for that. Maybe the nslu2 people like the idea, maybe they don't,
> but your shutting them out.

True enough, however my particular annoyance was raised by the fact
_how_ the change was introduced. 1st) by someone which wasn't very
prominently active in the community until now and 2nd) only for one
particular device. Considering both facts the it looked wrong just to
apply that changeset - a bit more open discussion and thinking was
needed.

> On handhelds.org we have familiar <at> , familiar-dev <at>  *and* ipaq <at> . You get 3
> guesses where ipaq related questions should go to.

Actually I am subscribed to the familiar list and I see a lot of ipaq
specific questions there.

> If you refuse to discuss MACHINE related items on the OE list I get the
> idea you don't want to merge. Let's work *together* and discuss OE stuff
> in a central place. For now that place is oe <at> . Integration, not segregation.
(Continue reading)

Permalink | Reply | 1 comment |
headers
bugzilla-daemon | 1 Jun 2005 12:09

[Bug 51] ipkg fails to find kernel modules in do_rootfs

http://bugs.openembedded.org/show_bug.cgi?id=51

------- Additional Comments From pb <at> reciva.com  2005-06-01 03:09 -------
Check that your deploy/ipk directory doesn't contain any other packages with the
same Provides (i.e. older versions of the kernel).  Might also be worth double
checking that h3600 is listed as a valid architecture in ipkg.conf.

--

-- 
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Jun 2005 12:29

[Bug 51] ipkg fails to find kernel modules in do_rootfs

http://bugs.openembedded.org/show_bug.cgi?id=51

------- Additional Comments From rw <at> handhelds.org  2005-06-01 03:29 -------
(In reply to comment #1)
> Check that your deploy/ipk directory doesn't contain any other packages with the
> same Provides (i.e. older versions of the kernel).

I had -hh37.4 packages in deploy/ipk indeed. ipkg-make-index didn't move those 
to the morgue since the kernel version is now part of the package names.

Any idea how to fix that? Currently you'd have to move older kernel packages 
away on every version bump...

--

-- 
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |

Gmane