gmane.linux.debian.devel.embedded

Re: Helping Emdebian

Neil Williams — 2012-05-23T07:49:46

On Tue, 22 May 2012 13:29:35 -0400
Andrew Bradford <andrew< at >bradfordembedded.com> wrote:


Where the bugs relate to packages which are still part of Emdebian
Crush, then we need to keep those bugs around. Where the bugs seek
changes in packages in Debian then those need review. i.e. if the bug
complains that bits of Emdebian Crush don't work, keep those because
Crush is still stuck on Lenny.

Busybox is also a bit different as the long options will still cause
problems with any future version of Crush which seeks to use busybox
instead of coreutils.
 

If the bug was filed by me, there's no need to ping.
 

It just needs someone else to look through the bugs. Some may need to
be turned into TODO documents on the debian Wiki (wiki.debian.org) under
CategoryEmdebian.

Re: Helping Emdebian

Andrew Bradford — 2012-05-22T17:29:35

On Tue, 10 Apr 2012 16:39:54 +0100
Neil Williams <codehelp< at >debian.org> wrote:


There's quite a few busybox / Crush / Lenny bugs listed there.  Is it
reasonable to just close those without much discussion?  Most of these
are from 2008 time frame, so even reproducing them will probably be
difficult or not very worthwhile.

What's the recommended way of handling this?  Is a reply to each of
these really old bugs asking for any reasons to keep it open, waiting a
reasonable time (few weeks?) and if no objection, closing?

I'm rather new to Debian development / bug tracking and don't want
to step on toes, but I'd like to help.  Cleaning up really old bugs
seems like a reasonable way for me to start.

Thanks,
Andrew

SHOCKING SYSTEM.(and one weird rule) Recommends Advanced Sports to you

2012-05-21T11:34:00

Email        :ronrajan< at >yahoo.com
Friend Name  :Friend
Friend Email :debian-embedded< at >lists.debian.org
comment      :


Hi Friend,

Here's a controversial new system revealing

affiliate marketing's number one rule...

=======>  http://bit.ly/LarThw

During this revealing presentation, this crazy
underground affiliate reveals the BRUTAL TRUTH why
most beginner marketers DON'T make even one cent
online.

Ya, you might say it's a bit controversial...

.BUT if you want to discover the truth about
driving insane amounts of traffic the way the top
super affiliates do it, and find out the number
one rule that's been kept from you all along, then
you need to check out what this guy has to say:

=======>  http://bit.ly/LarThw

This WON'T be available forever so my best advice
is to go check it out right now.

Ron Rajan

P.S. If you've been looking for a STEP BY STEP
system for getting crazy amounts of laser targeted
traffic, then you'll certainly want to check this
out.

Just make sure you pay close attention to the
w

Re: Cross compilers for wheezy (bare and libc)

Keith Packard — 2012-05-18T17:39:16


I didn't end up getting newlib built; it was too hard. So I switched to
pdclib, which is very simple. The SAT built compiler doesn't seem to care.

Re: Cross compilers for wheezy (bare and libc)

Hector Oron — 2012-05-18T17:16:43

Hi,

2012/5/18 Keith Packard <keithp< at >keithp.com>:


SAT links against newlib afaics, how do you mangle the library, just
overwrite newlib with pdclib or do you patch SAT build system or do
you patch GCC spec file? Also another question arises and where should
the libraries be best placed in the system?


I guess binutils-cross should be possible to upload ASAP, that might help.

Regards,

Re: Cross compilers for wheezy (bare and libc)

Keith Packard — 2012-05-18T16:22:40


SAT has been working fine for me; the obvious goal is to not require
glibc :-)


I've been using pdclib for my tiny ARM systems; uclibc is a linux C
library, and even newlib requires significant underlying support (it
requires malloc, for instance). It's a lot more like the C library
provided with sdcc or avr-libc.

So, any compiler package will need to allow for a variety of C
libraries at the very least.


That would be great, of course, but doesn't leave a lot of time.

-keith

Cross compilers for wheezy (bare and libc)

Hector Oron — 2012-05-18T13:51:04

Hello,

1. BARE METAL

  Recently, some people have been wanting to have in Debian, bare
metal cross compilers for bare metal code, mainly arm-eabi target.
They have been mainly using the summon-arm-toolchain[1]. We could
reuse gcc/stage1 packaging[2] (done for testing purposes) and
configure it similar to summon-arm-toolchain. Does someone have better
ideas for such purpose?

  Note some people would like to easily be able to use a cross
toolchain and link against newlib, uclibc and other C libraries. For
such purpose, a couple git projects were created [3][4]. But maybe we
should aim to just have only one source tree. If you want to
contribute to the packaging, please ask to join 'emdebian' project on
alioth[5] (and you dont even need to be Debian Developer).

  The idea would be to include this package in the upcoming Wheezy
release (if we dont miss the freeze deadline).

2. LIBC CROSS TOOLCHAINS

  For the upcoming Wheezy release, current state of cross compilers
its a bit unfortunate. Only ARM, SH and I

Processed: Re: Bug#673094: debhelper: hardlink auto-gened.placeholder files

Debian Bug Tracking System — 2012-05-16T07:00:12

Processing commands for control< at >bugs.debian.org:

Bug #673094 [debhelper] debhelper: hardlink auto-gened .placeholder files
Bug reassigned from package 'debhelper' to 'buildd.emdebian.org'.
No longer marked as found in versions 9.20120513em1.
Ignoring request to alter fixed versions of bug #673094 to the same values previously set
Stopping processing here.

Please contact me if you need assistance.

Bug#673094: Info received (Bug#673094: debhelper: hardlinkauto-gened .placeholder files)

Debian Bug Tracking System — 2012-05-16T07:00:09

Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Joey Hess <joeyh< at >debian.org>

If you wish to submit further information on this problem, please
send it to 673094< at >bugs.debian.org.

Please do not send mail to owner< at >bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

Re: Bug#673094: debhelper: hardlink auto-gened .placeholder files

Neil Williams — 2012-05-16T06:56:10

reassign 673094 buildd.emdebian.org
quit

On Tue, 15 May 2012 16:20:30 -0700
shawn <shawn< at >jengr.tk> wrote:


Bugs against em1 versions need to be filed against buildd.emdebian.org,
not the package. (reportbug should do this for you).


From the perspective of the Debian package, there is no point worrying
about a little bit of space inside packages.

From the perspective of packages handled by emgrip, it is not going to
be simple to use hardlinks and although each file is 102 bytes, it is
not as if every debhelper 9 package is going to have these files.
Making the files zero byte isn't going to help as those are prime
candidates for removal by many cleanup processes. 

I don't think there is a lot of benefit in adding this to emgrip
currently. Cron only has 5 .placeholder files and on my Debian
unstable development box I could only find one other, in php5-common.
Even if debhelper 9 placeholder support grows enormously, if it saved
more than about 4Kb on a complete system I would be surprised.

Bug#673094: debhelper: hardlink auto-gened .placeholder files

shawn — 2012-05-15T23:20:30

Package: debhelper
Version: 9.20120513em1
Severity: wishlist

It would be nice to hardlink all the little .placeholder files when a package ships
more than one of them, such as cron. To save a little bit of space. Alternatively,
the files could be made totally empty, but I don't exect that to happen.

Emdebian Grip Squeeze 2.0.5 updated

Neil Williams — 2012-05-12T12:40:06

I've just completed the update of Emdebian Grip stable to the latest
point release, aiming to match Debian Squeeze 6.0.5.

Please note that this update does not constitute a new version of
Emdebian Grip 2.0 but only updates some of the packages included.

deb http://www.emdebian.org/grip stable main

or with all components available:

deb http://www.emdebian.org/grip stable main dev debug doc java

(Remember: squeeze will be the last time components are used, other
than main.)

Squeeze 2.0.5 is the stable release of Emdebian Grip and is the
recommended distribution for those basing their own work on Emdebian
Grip. Changes are only made in the stable release when Debian makes a
corresponding point release.

Mirror:
deb http://ftp.uk.debian.org/emdebian/grip stable main

As I've been preparing this announcement, the changes have been pushed
to the mirror, so that should now be up to date with 2.0.5.

The full log of the changes is available here:

http://www.emdebian.org/grip/logs/squeeze-log

Note that this i

Q for USB error on Debian Squeeze

tanimura — 2012-05-11T21:18:48

I got following error message when I was going to load ARM7 program
into target GBA (ARM7TDMI) board.

---
Source file = /home/jingba/my_OS/build/bin/sagos2.bin
Program size = 14690

Error: OPTIMIZE GBA-USB-bootcable is not found!
---

I have been using this loading program on Debian Lenny or Etch, and
was able to load successfully.

Is any change for USB devices after Squeeze?

I attach dmesg that seems recognizing the USB.

Thanks in advance for your help or information.

============== dmesg
================================================================

[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 2.6.32-5-686 (Debian 2.6.32-43)
(dannf< at >debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Sat Mar
31 03:56:41 UTC 2012
[ 0.000000] KERNEL supported cpus:
[ 0.000000] Intel GenuineIntel
[ 0.000000] AMD AuthenticAMD
[ 0.000000] NSC Geode by NSC
[ 0.000000] Cyrix CyrixInstead
[ 0.000000] Centaur CentaurHauls
[ 0.000000] Transmeta Genuine

Re: Who is using emdebian-grip-server?

Andrew Bradford — 2012-05-10T14:06:53

On Thu, 10 May 2012 14:35:32 +0100
Neil Williams <codehelp< at >debian.org> wrote:


I'll uninstall and see if I can do what I need to (I assume I can based
on your response).  I probably installed emdebian-grip-server with a
smattering of "throw stuff at the wall and see if it sticks"
mentality.  Stuff stuck, so I assumed I needed everything... now I will
reevaluate.


No.  I will only be working with Squeeze.  Once Wheezy goes stable,
I'll be working with Wheezy.


Ok, I will look more into apt-grip.


As I nail down which packages I really need, I will follow the
directions.  I expect to fully understand my package needs within the
next 2 months.


I will read up!


Ok, will keep in mind.

Thanks!
-Andrew

Re: Who is using emdebian-grip-server?

Neil Williams — 2012-05-10T13:35:32

On Thu, 10 May 2012 08:20:43 -0400
Andrew Bradford <andrew< at >bradfordembedded.com> wrote:


In that case, you probably don't want it installed.
emdebian-grip-server is an ongoing task, it needs to run a couple of
times a day, every day. (It has a cron task for this purpose but this
needs to be manually enabled.)


Are you going to be using testing migrations? (i.e. are you trying to
track the same package in both unstable and testing and trying to
update testing with changes in unstable? This is the area of code which
causes the most problems with emdebian-grip-server.)

I'm not sure emdebian-grip-server is going to be suitable for what you
want, it's designed to do a lot more stuff which you won't be using
and that extra complexity can make the simpler jobs harder than
necessary.

If you're only converting a few packages, then apt-grip is the way to
go.

Also, let me know *which* packages you need from Debian because although
I can't promise to get them into Squeeze via proposed-updates, I can now
add package

Re: Who is using emdebian-grip-server?

Andrew Bradford — 2012-05-10T12:20:43

On Wed, 2 May 2012 22:48:58 +0100
Neil Williams <codehelp< at >debian.org> wrote:


I'm one of those people in popcon.  Haven't used it much yet, but will
be in the near future to grip a few (single digit, hopefully) Squeeze
armel debs.  If I run into issues, I'll shout.


I've probably missed an important note about how Wheezy will be
integrated with Emdebian, sorry if this is a repeat question:  With
Wheezy, will either a set of scripts like emdebian-grip-server be
available (not just in SVN) or will all Wheezy packages already be
gripped?

Thanks,
Andrew

Who is using emdebian-grip-server?

Neil Williams — 2012-05-02T21:48:58

If the integration goes ahead, I won't have time to maintain a
duplicate set of scripts in emdebian-grip-server which are themselves
buggy and incomplete. (It turns out replicating dak, britney and
stable-release-managers is not a way to create bug free scripts.)

In effect, I'm having to push everything into the debian-grip scripts
but those are tightly integrated into the Debian infrastructure and are
not going to work as a separate package any longer.

The only remaining uses for emdebian-grip-server on www.emdebian.org
are generating TDebs and handling the ports (unstable only).

Most of the bugs in the current scripts are outside these roles, so I
could keep those running on www.emdebian.org but without the really
problematic code of testing migrations and stable release management, I
see little use in the package being in Wheezy.

So, according to popcon, there are people who have emdebian-grip-server
installed. If any of those people are here, please speak up and tell me
how you're doing with the scri

Re: Upcoming upload of X server 1.12 to unstable

Cyril Brulebois — 2012-05-01T00:33:56

Hi.

Cyril Brulebois <kibi< at >debian.org> (04/03/2012):

Just a quick heads-up, this is happening today:
  http://blog.mraw.org/2012/05/01/DXN-11/

Mraw,
KiBi.

/usr/bin/update-alternatives: Re: dpkg: update-alternatives shouldmake sure target dir exist before attempting to create symlinks.

shawn — 2012-04-27T18:21:21

Package: dpkg
Followup-For: Bug #623602

this is fixed in my version

Setting up aptitude (0.6.6-1+b1em1) ...
update-alternatives: warning: forcing reinstallation of
alternative /usr/bin/aptitude-curses because link group aptitude is
broken.
update-alternatives: warning: skip creation
of /usr/share/man/man8/aptitude.8.gz because associated
file /usr/share/man/man8/aptitude-curses.8.gz (of link group aptitude)
doesn't exist.
update-alternatives: warning: skip creation
of /usr/share/man/cs/man8/aptitude.8.gz because associated
file /usr/share/man/cs/man8/aptitude-curses.8.gz (of link group
aptitude) doesn't exist.
update-alternatives: warning: skip creation
of /usr/share/man/de/man8/aptitude.8.gz because associated
file /usr/share/man/de/man8/aptitude-curses.8.gz (of link group
aptitude) doesn't exist.
update-alternatives: warning: skip creation
of /usr/share/man/es/man8/aptitude.8.gz because associated
file /usr/share/man/es/man8/aptitude-curses.8.gz (of link group
aptitude) doesn't exist.
update-alternatives

Re: Multistrap upload to experimental

Marcus Osdoba — 2012-04-24T21:24:09

Am 17.04.2012 22:53, schrieb Neil Williams:
Just tested the following with my Makefile set [0] for rootfs-generation:
* host system debian squeeze (qemu from backports)
- armel for qemu works (no regression)
- ppc for qemu works (no regression)
- i386 rootfs is generated as it were a cross one from above (my desired 
behaviour, because I can reconfigure it later like I do with the others)

Regards,
Marcus


[0] https://gitorious.org/debian/rootfs-builder

Bug#670200: gdb: ships syscalls decls for unrelated archs

Yann Dirson — 2012-04-23T22:03:03

Package: gdb
Version: 7.4really-1
Severity: normal
X-Debbugs-CC: debian-embedded< at >lists.debian.org

In /usr/share/gdb/syscalls/, the standard gdb package installs many
files, seamingly for support of other archs, although "set arch" will
make it obvious that very few of those are indeed usable with the
installed binary.

This makes it uncomfortable to simultaneously install cross gdb
packages from emdebian, as those currently ship the same set of files
- and even if they only shipped the relevant ones, there would be
conflict on those files they seem the more legitimate to ship.