Bug#1007600: xfaces: please consider upgrading to 3.0 source format

[Hakan Ardo]

Sorry about that. Ill look into upgrading.

On Tue, Mar 26, 2024, 22:51 Bastian Germann  wrote:

> Hi Hakan,
>
> You have overridden my NMU which fixed this issue and - more importantly -
> #1049887. I have uploaded the fix for
> #1049887 once again with 3.3-30.1. I am not sending a debdiff so that
> debdiff does not show up in the BTS or mailing
> list archives.
>
> Please make sure to have the last NMU integrated in your working directory.
>
> For this issue I have created a debdiff that is attached. Having
> additional files in your working copy included in your
> uploads is one of the things that are prevented with the 3.0 (quilt)
> format. Please consider applying.
>
> Thanks,
> Bastian

Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain

[Hakan Ardo]

There is no progress I'm afraid. The package is up for adoption. We need to
find someone who's willing to put in the time needed...

On Tue, Jun 14, 2022 at 7:27 PM Marco  wrote:

> What's the current status? This bug is almost 3 years old and Debian
> is still shipping 5.4.0, even in Sid. nightwalker-87 mentions that
> Arch Linux may have found a working solution:
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932989#20
>


-- 
Håkan Ardö

Bug#999263: libcompface: diff for NMU version 1:1.5.2-5.1

[Hakan Ardo]

Thanx!

On Sat, Dec 25, 2021 at 6:21 PM gregor herrmann  wrote:

> Control: tags 861345 + pending
> Control: tags 965632 + patch
> Control: tags 965632 + pending
> Control: tags 999263 + patch
> Control: tags 999263 + pending
>
>
> Dear maintainer,
>
> I've prepared an NMU for libcompface (versioned as 1:1.5.2-5.1) and
> uploaded it to DELAYED/7. Please feel free to tell me if I
> should delay it longer.
>
> Regards.
>
>
> --
>  .''`.  https://info.comodo.priv.at -- Debian Developer
> https://www.debian.org
>  : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649
> AA06
>  `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation
> Europe
>`-   NP: Alan Jackson: Chattahoochee
>


-- 
Håkan Ardö

Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain

[Hakan Ardo]

No worries. Thanx for caring!

On Thu, Dec 16, 2021 at 3:00 PM Gregor Riepl  wrote:

> Please disregard my last message, I totally missed the whole discussion
> that has already been going on.
>
> Sorry.
>


-- 
Håkan Ardö

Bug#1001273: Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain

[Hakan Ardo]

I believe your right, and I would support any such efforts. I've orphaned
these packages quite some time ago as I've not been able to find the time
to implement this myself though.

On Thu, Dec 16, 2021 at 2:03 PM Gregor Riepl  wrote:

>
> >> Switching back to use upstream source would be one option. But will
> >> that mean we'll have to dropp support for newer devices?
>
> > Unfortunately I don’t know too much about the development history of
> > this package @Debian and the related decisions. It would be helpful
> > though to have other developers and maintainers to have their say on
> > this to help find a common solution. At first one should find out if
> > support for newer devices would suffer from such an approach. I have
> > not come across that topic yet...
>
> To be honest, I don't think newer device support is a big issue any
> more. While Microchip is still releasing new AVR MCUs, they are usually
> not that different from existing devices. Even if Debian is lagging
> behind, I think developers targeting older devices will benefit greatly
> from an updated gcc. If they must, they can always rely on the binary
> releases provided by Microchip.
>
> It's also not that hard to feed in support for new devices:
> https://gcc.gnu.org/wiki/avr-gcc#Supporting_.22unsupported.22_Devices
>
> And last but not least, upstream has kept pace with new AVR devices, as
> can be seen in the gcc release notes:
>
> https://gcc.gnu.org/gcc-7/changes.html#avr
> https://gcc.gnu.org/gcc-8/changes.html#avr
> https://gcc.gnu.org/gcc-10/changes.html#avr
>
> I believe it's time to make the switch - same for binutils-avr and
> avr-libc.
>


-- 
Håkan Ardö

Bug#932989: gcc-avr: which MCUs are not supported by upstream gcc?

[Hakan Ardo]

OK, so upstream does indeed currently seem to be ahead. That has not always
been the case historically. I'm fine with switching if anyone steps up to
do the work. I've put the packages up for adoption, but I'll be happy to
give some support...

On Thu, Feb 11, 2021 at 10:57 AM Benjamin Valentin <
benjamin.valen...@beuth-hochschule.de> wrote:

> Just comparing the output of avr-gcc --target-help gives
>
> --- gcc-5.4.txt 2021-02-11 09:56:37.490084599 +0100
> +++ gcc-10.2.txt2021-02-11 09:56:30.918162094 +0100
> @@ -160,9 +160,14 @@
>  attiny13
>  attiny13a
>  attiny15
> +attiny1614
> +attiny1616
> +attiny1617
>  attiny1634
>  attiny167
>  attiny20
> +attiny212
> +attiny214
>  attiny22
>  attiny2313
>  attiny2313a
> @@ -173,8 +178,13 @@
>  attiny261
>  attiny261a
>  attiny28
> +attiny3214
> +attiny3216
> +attiny3217
>  attiny4
>  attiny40
> +attiny412
> +attiny414
>  attiny416
>  attiny417
>  attiny4313
> @@ -186,6 +196,7 @@
>  attiny461a
>  attiny48
>  attiny5
> +attiny814
>  attiny816
>  attiny817
>  attiny828
>
> So gcc10 actually knows about some more parts.
> I don't know if there are any missing patches upstream though.
> Arch seems to carry the latest upstream gcc for AVR with no complaints
> though.
>


-- 
Håkan Ardö

Bug#930195: avr-libc: Upstream avr-libc maintainers appear to be MIA; can another source be found?

[Hakan Ardo]

Hi,
updated packages are now uploaded to unstable. It might still take some
time for the mirrors to be updated. Please let me know if this solves your
problem.

Thanx!

On Tue, Nov 3, 2020 at 1:16 PM Andy Bennett  wrote:

> Hi,
>
> > I'm sorry, but this got lost in my flood todos. Please keep
> > pinging me about it and we'll get there...
>
> Thanks.
>
> I'm ready to test a package for a board I'm working on so anything in the
> next week or so would be perfect. If you have the time I'll really
> appreciate it.
>
>
> Thanks again!
>
>
>
> Best wishes,
> @ndy
>
> --
> andy...@ashurst.eu.org
> http://www.ashurst.eu.org/
> 0x7EBA75FF
>


-- 
Håkan Ardö

Bug#930195: avr-libc: Upstream avr-libc maintainers appear to be MIA; can another source be found?

[Hakan Ardo]

I'm sorry, but this got lost in my flood todos. Please keep pinging me
about it and we'll get there...

On Mon, Nov 2, 2020 at 11:15 PM Andy Bennett  wrote:

> Hello again,
>
> Is there an upgraded package that I could try that has the support
> discussed above for the "0-series"?
>
> Thanks!
>
>
>
> Best wishes,
> @ndy
>
> --
> andy...@ashurst.eu.org
> http://www.ashurst.eu.org/
> 0x7EBA75FF
>


-- 
Håkan Ardö

Bug#966898: binutils-avr: FTBFS: elf.c:706:35: error: overflow in conversion from ‘unsigned int’ to ‘int’ changes value from ‘num_group = 4294967295’ to ‘-1’ [-Werror=overflow]

[Hakan Ardo]

Thanx for the investigation! I'll update the package.

Yes something has to be done about what upstream distribution we use.
Unfortunately there are atmel specific patches that people rely on that was
not accepted upstream, so switching is not as straight forward as it
might seem...

On Mon, Aug 31, 2020 at 1:48 PM Gregor Riepl  wrote:

> > > elf.c: In function ‘setup_group’:
> > > elf.c:706:35: error: overflow in conversion from ‘unsigned int’ to
> ‘int’ changes value from ‘num_group = 4294967295’ to ‘-1’ [-Werror=overflow]
> > >   706 | elf_tdata (abfd)->num_group = num_group = -1;
>
> Upstream bug is here:
> https://sourceware.org/bugzilla/show_bug.cgi?id=25717
>
> This was fixed upstream by:
>
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=cda7e5603f6efd7c3716e45cc6ea11b70dd8daae
>
> Looks like it's caused by GCC 10 being more picky about signedness.
>
> > > In file included from elf.c:45:
> > > elf.c: In function ‘elfcore_write_linux_prpsinfo32’:
> > > elf-linux-psinfo.h:73:7: warning: ‘strncpy’ output may be truncated
> copying 16 bytes from a string of length 16 [-Wstringop-truncation]
>
> This and the rest of the errors are false positives occurring from GCC 8
> onwards. They have been silenced upstream:
>
>
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=5a6312e8c015d4a98020038f3b6e144db230f3ca
>
>
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=b9f26d2e29bb56a0404216c5612d6d7fee54a769
>
>
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d99b4b92c8ed0f7ef98f370bbf65a360ed66ad7b
>
>
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=602f16570454a1597c2af28af66852133432d1f2
>
> (there may be other patches as well)
>
> Related bug reports:
> https://sourceware.org/bugzilla/show_bug.cgi?id=23146
> (can't find any that describe the original problem)
>
> Also, please note that elf-linux-psinfo.h was renamed to
> elf-linux-core.h upstream:
>
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=de64ce13a78669f094d6909fce51d210e2f9d2c0
>
> Perhaps it's time to replace the outdated Atmel versions of avr-gcc
> avr-binutils and avr-libc in favour of the upstream versions?
>


-- 
Håkan Ardö

Bug#969204: RFA: gdb-avr -- GNU Debugger for avr

[Hakan Ardo]

Package: wnpp
Severity: normal

I request an adopter for the gdb-avr package. I'm lacking the time
to propperly maintain it.


The package description is:
 This package has been compiled to target the  avr architecture.
 GDB is a source-level debugger, capable of breaking programs at
 any specific line, displaying variable values, and determining
 where errors occurred. Currently, it works for C, C++, Fortran
 Modula 2 and Java programs. A must-have for any serious
 programmer.
 This package is primarily for avr developers and cross-compilers and
 is not needed by normal users or developers.

Bug#969202: RFA: binutils-avr -- Binary utilities supporting Atmel's AVR targets

[Hakan Ardo]

Package: wnpp
Severity: normal

I request an adopter for the binutils-avr package. I'm lacking the time
to propperly maintain it.


The package description is:
 The programs in this package are used to manipulate binary and object
 files that may have been created for Atmel's AVR architecture.  This package
 is primarily for AVR developers and cross-compilers and is not needed
 by normal users or developers.
 The programs in this package are used to manipulate binary and object
 files that may have been created for Atmel's AVR architecture.  This package
 is primarily for AVR developers and cross-compilers and is not needed
 by normal users or developers.

Bug#969203: RFA: gcc-avr -- GNU C compiler (cross compiler for avr)

[Hakan Ardo]

Package: wnpp
Severity: normal

I request an adopter for the gcc-avr package. I'm lacking the time
to propperly maintain it.


The package description is:
 This is the GNU C compiler, a fairly portable optimizing compiler which
 supports multiple languages.  This package includes support for C.

Bug#969205: RFA: avr-libc -- Standard C library for Atmel AVR development

[Hakan Ardo]

Package: wnpp
Severity: normal

I request an adopter for the avr-libc package. I'm lacking the time
to propperly maintain it.

The package description is:
 Standard library used to the development of C programs for the
 Atmel AVR micro controllers. This package contains static
 libraries as well as the header files needed.

Bug#932989: gcc-avr: which upstream to track

[Hakan Ardo]

Hi,
thanx a lot for the great summary of the situation! Historically, the issue
with "community" versions of the avr toolchain have been the lack of
support for all AVR devices. Especially newer once. I don't know what the
situation is there with the Arduino toolcahin.

I agree that providing two version of gcc (one with Arduino as upstream and
one with microchip) is probably the best solution. That will however
require some packaging work, and I'm afraid that my current
personal situation wont allow me to put in that work anytime soon. But I
will gladly support it if anyone steps up to do the work.

So, the plan is to have a new release based on Atmel-3.6.2 from microchip
soon, and we can then make a separate release adding the Arduino version as
an alternative once it is packaged.


On Sun, Jan 12, 2020 at 2:30 AM Osamu Aoki  wrote:

> Hi again,
>
> I checked meaning of GCC versions.
>
> GCC development time lines:
>https://gcc.gnu.org/develop.html#timeline
>
> As for ISO C99 conformance:
>https://gcc.gnu.org/c99status.html
>
> The last mentioned version was GCC 5 for "extended identifiers".  So GCC
> 5 as supported by the vendor (microchip) isn't bad choice for C programs
> mostly used by embedded programs.
>
> Since Arduino sketches are in-essence C++ program(*), let's see C++
> conformance:
>https://gcc.gnu.org/projects/cxx-status.html
>
> For C++14, GCC 5 is good enough.
> For C++17, GCC 7 is needed and is good enough.
> For C++2a, GCC 8-10 are addressing some features.
>
> Unicode UTF-8 support is important. This u8 character literals support
> is made available at GCC 6 as a part of C++17 feature:
>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4267.html
>https://gcc.gnu.org/gcc-6/changes.html#cxx
>
> This kind of explains why Arduino is updating GCC 7.
>
> Osamu
>
> (*) https://github.com/arduino/arduino-preprocessor
> https://github.com/arduino/arduino-builder
>
> https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification
>


-- 
Håkan Ardö

Bug#930195: avr-libc: Upstream avr-libc maintainers appear to be MIA; can another source be found?

[Hakan Ardo]

Thanx for the info! I'll make suer to upgrade the Debian packages.

On Sat, Jan 11, 2020 at 10:09 AM Ronald Sutherland <
ronald.sutherl...@gmail.com> wrote:

> Hi,
>
> Just want to note that a new upstream version is available for avr
> toolchain
>
>
>
> The old location
>
>
>
> http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/
>
>
>
> has changed (look for heading: AVR GCC, then AVR GCC 3.6.2)
>
>
>
> https://www.microchip.com/mplab/avr-support/avr-and-sam-downloads-archive
>
>
>
> On Mon, 10 Jun 2019 12:50:21 +0200 Hakan Ardo  wrote:
>
> > Hi,
>
> > Apache 2.0 licence is fine, but for the main distribution we need the
>
> > source as well.
>
> >
>
> > On Mon, Jun 10, 2019 at 12:28 PM Paul "LeoNerd" Evans <
>
> > leon...@leonerd.org.uk> wrote:
>
> >
>
> > > On Mon, 10 Jun 2019 11:07:29 +0200
>
> > > Hakan Ardo  wrote:
>
> > >
>
> > > > There have been a sugestion to use Microchip Packs Repository:
>
> > > >
>
> > > > http://packs.download.atmel.com/
>
> > > >
>
> > > > But as far as I can tell, these are binary distributions and thus not
>
> > > > suitable for mainstream debian (I suppose placing them i non-free
>
> > > > could be an option).
>
> > >
>
> > > This is the preferred method I believe. In fact, it's what I use as a
>
> > > workaround at the moment.
>
> > >
>
> > > I've written myself a "reminder to self" blog post, which illustrates
>
> > > the steps I took to fix this problem:
>
> > >
>
> > >
>
> > >
> https://leonerds-code.blogspot.com/2019/06/building-for-new-attiny-1-series-chips.html
>
> > >
>
> > > Having done that, I can build code for these new chips just fine.
>
> > >
>
> > > Maybe that's all that is required? The pack files are Apache 2.0
>
> > > licenced, so hopefully that is acceptable to Debian?
>
> > >
>
> > > --
>
> > > Paul "LeoNerd" Evans
>
> > >
>
> > > leon...@leonerd.org.uk  |  https://metacpan.org/author/PEVANS
>
> > > http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
>
> > >
>
> >
>
> >
>
> > --
>
> > Håkan Ardö
>


-- 
Håkan Ardö

Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain

[Hakan Ardo]

Hi,
gcc-avr was originally built from the mainline gcc, but was later split out
by to build depend on gcc-source as it was not wanted in the mainstream gcc
package. Has that situation changed?

It was then decided to base the package on the Atmel distribution instead
of the upstream source as that gave support for newer devices faster.

Now, as far as I can tell, Atmel have dropped their source distribution and
only provided binaries. So something have to be done indeed.

Switching back to use upstream source would be one option. But will that
mean we'll have to dropp support for newer devices?

Den tors 25 juli 2019 17:27nightwalker-87 
skrev:

> Package: gcc-avr
> Version: 1:5.4.0+Atmel3.6.1-2
> Severity: normal
> Tags: newcomer
>
> Dear Maintainer,
>
> It appears that the gcc-avr toolchain in the debian repository is severely
> outdated compared to the current level of version support for the main gcc
> toolchain. This leaves avr-developers wishing to use newer C language
> features
> behind and makes it necessary to use external toolchains (source based or
> pre-
> compiled). Pointing to this in the debian-devel IRC-Channel, lead to the
> following idea: "if it was in mainline, the gcc-avr package could be
> dropped in
> favour of a package built from the mainline version of gcc." as well as "an
> example of such a source package is gcc-arm-none-eabi, the equivalent for
> avr
> could be added by someone interested, then gcc-avr could be removed."
> (user:
> pabs) From my point of view this could be a promising approach to resume
> development on this topic. I would appreciate, if debian developers could
> take
> action on this topic to resolve this long lasting backlog and make
> contribution
> to make debian even more attractive for development. As it stands the avr-8
> architecture will remain for many years to come in some parts even with new
> applications.
>
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages gcc-avr depends on:
> ii  binutils-avr  2.26.20160125+Atmel3.6.1-4
> ii  libc6 2.28-10
> ii  libgcc1   1:8.3.0-7
> ii  libgmp10  2:6.1.2+dfsg-4
> ii  libmpc3   1.1.0-1
> ii  libmpfr6  4.0.2-1
> ii  libstdc++68.3.0-7
> ii  zlib1g1:1.2.11.dfsg-1
>
> gcc-avr recommends no packages.
>
> Versions of packages gcc-avr suggests:
> ii  avr-libc  1:2.0.0+Atmel3.6.1-2
> ii  gcc   4:8.3.0-1
> pn  gcc-doc   
>
> -- no debconf information
>

Bug#930195: avr-libc: Upstream avr-libc maintainers appear to be MIA; can another source be found?

[Hakan Ardo]

Hi,
Apache 2.0 licence is fine, but for the main distribution we need the
source as well.

On Mon, Jun 10, 2019 at 12:28 PM Paul "LeoNerd" Evans <
leon...@leonerd.org.uk> wrote:

> On Mon, 10 Jun 2019 11:07:29 +0200
> Hakan Ardo  wrote:
>
> > There have been a sugestion to use Microchip Packs Repository:
> >
> > http://packs.download.atmel.com/
> >
> > But as far as I can tell, these are binary distributions and thus not
> > suitable for mainstream debian (I suppose placing them i non-free
> > could be an option).
>
> This is the preferred method I believe. In fact, it's what I use as a
> workaround at the moment.
>
> I've written myself a "reminder to self" blog post, which illustrates
> the steps I took to fix this problem:
>
>
> https://leonerds-code.blogspot.com/2019/06/building-for-new-attiny-1-series-chips.html
>
> Having done that, I can build code for these new chips just fine.
>
> Maybe that's all that is required? The pack files are Apache 2.0
> licenced, so hopefully that is acceptable to Debian?
>
> --
> Paul "LeoNerd" Evans
>
> leon...@leonerd.org.uk  |  https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
>


-- 
Håkan Ardö

Bug#930195: avr-libc: Upstream avr-libc maintainers appear to be MIA; can another source be found?

[Hakan Ardo]

Hi,
avr packages in debian have for the last couple of years been based on a
distribution from atmel:


http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-%20Toolchain/3.4.4/

However it's recently gone away too...

There have been a sugestion to use Microchip Packs Repository:

http://packs.download.atmel.com/

But as far as I can tell, these are binary distributions and thus not
suitable for mainstream debian (I suppose placing them i non-free could be
an option).



On Sat, Jun 8, 2019 at 12:45 AM Paul "LeoNerd" Evans 
wrote:

> Package: avr-libc
> Version: 1:2.0.0+Atmel3.6.1-2
> Severity: normal
>
> Dear Maintainer,
>
> Hi all,
>
> The upstream project at https://savannah.nongnu.org/projects/avr-libc/
> appears to have stalled, because no actual updates have been made in a
> couple of years now. Meanwhile there are many new types of AVR chip that
> the library does not yet support. I've been reporting bugs upstream and
> not getting any responses. E.g.
>
>   https://savannah.nongnu.org/bugs/?54652
>
>   https://savannah.nongnu.org/bugs/?54977
>
> Would it be possible for Debian to find another source of this - perhaps
> by using the Atmel part files more directly? Specifically, newer chips
> that this Debian package does not support that I have been trying to
> work on are:
>
>   ATmega328PB
>
>   ATtiny214, ATtiny414, ATtiny814, ATtiny1614, ATtiny3214
>   ATtiny416, ATtiny816, ATtiny1616, ATtiny3216
>   ATtiny417, ATtiny817, ATtiny1717, ATtiny3217
> (i.e. the entire new ATtiny 1-series)
>
>   ATmega3208, ATmega4808
>   ATmega3209, ATmega4809
> (i.e. the entire new ATmega 0-series)
>
> A number of folks on #avr on Freenode have been aware of this for some
> time, and we're getting close to the point of declaring a fork of the
> original nongnu project so we can continue to make progress adding the
> newer chips from the last few years.
>
> Before we look into that, is Debian aware of any other sources for this
> sort of thing, that we could talk to instead?
>
> Thanks,
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
> 'testing-debug'), (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages avr-libc depends on:
> ii  binutils-avr  2.26.20160125+Atmel3.6.1-4
> ii  gcc-avr   1:5.4.0+Atmel3.6.1-2
>
> avr-libc recommends no packages.
>
> avr-libc suggests no packages.
>
> -- no debconf information
>
> -- debsums errors found:
> debsums: changed file /usr/lib/avr/include/avr/io.h (from avr-libc package)
>
>
> --
> Paul "LeoNerd" Evans
>
> leon...@leonerd.org.uk  |  https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
>


-- 
Håkan Ardö

Bug#917390: avr-gcc version mismatch

[Hakan Ardo]

Hi again,
I created bug 917390 to track this issue. I don't think we should use
identical version strings as the debian package might differ slightly to
the atmel binary version, but we should reflect which athmel version it is
based on.

On Thu, Dec 27, 2018 at 10:03 AM Hakan Ardo  wrote:

> Hi,
> thanx for your reprt. We can't use a binary distribution in Debian (the
> gnu license requires us to provide sources and we need to support all
> debian architectures) so we need to build gcc from source. Version 5.4.0 of
> avr-gcc is availible in testing. It will be part of the next stable debian
> release. The version string is not identical to yours though:
>
> $ avr-gcc --version
> avr-gcc (GCC) 5.4.0
>
> which I suppose would be a good idea to fix.
>
> On Thu, Dec 27, 2018 at 9:17 AM Brian Holaday 
> wrote:
>
>> Hi Hakan,
>>
>> FYI when you get a chance: I had some issues submitting a bug request so
>> passing this to you via email. There is no hurry on this but offered a fix:
>>
>> Fix Proposed:
>>
>> Manual Package: GCC-AVR Official
>> AVR Toolchain Proper Link: (
>> http://ww1.microchip.com/downloads/en/DeviceDoc/avr8-gnu-toolchain-3.6.2.1759-linux.any.x86_64.tar.gz
>> )
>>
>> Command:
>> #wget
>> http://ww1.microchip.com/downloads/en/DeviceDoc/avr8-gnu-toolchain-3.6.2.1759-linux.any.x86_64.tar.gz
>>
>> #gunzip -k avr8-gnu-toolchain-3.6.2.1759-linux.any.x86_64.tar.gz
>> #mkdir /opt/avr-gcc
>> #mv avr8-gnu-toolchain-3.6.2.1759-linux.any.x86_64.tar.gz /opt/avr-gcc
>>
>> I then added the New Toolchain to MPLAB X : Project Selection works: All
>> is good.
>>
>> -- Forwarded message -
>> From: Brian Holaday 
>> Date: Thu, Dec 27, 2018 at 12:45 AM
>> Subject: avr-gcc version mismatch
>> To: 
>>
>>
>> Package: gcc-avr
>> Version: 1:4.9.2+Atmel3.5.3-1
>> Severity: important
>>
>> Issue: When trying to use MPLAB X the compiler fails to pick up
>> versioning flags. It be helpful if the package could be updated to use
>> proper version output standing.
>>
>> Files that work:
>> URL #1:
>> https://www.microchip.com/mymicrochip/filehandler.aspx?ddocname=en607660
>> URL #2: https://www.microchip.com/mplabx-ide-linux-installer
>>
>> #1A: Version Mismatch causes MPLab to not build any projects. MPLab
>> reports said default as Version 1 and the URL below as 5.4.0
>>
>> #1. Default Install (/usr/bin)
>> >> #avr-gcc --version
>> >>> avr-gcc (GCC) 4.9.2
>>
>> #2. URL #1 Install (/opt/gcc-1/)
>> >> #./avr-gcc --version
>> >> #avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.2_1759) 5.4.0
>>
>> Upon further investigation it appears you only need URL #1 : this looks
>> like a built package that just works when extracted to /opt. This might
>> allow different versions to be installed and things to be more proper in
>> MPLAB and other tools as the tool allows different path chains. It will be
>> up to you if you fix this or not but submitting a patch on my input/idea on
>> how I got MPLab finally working and avr-gcc working proper.
>>
>
>
> --
> Håkan Ardö
>


-- 
Håkan Ardö

Bug#917390: gcc-avr: Expand the version string with the atmel version

[Hakan Ardo]

Package: gcc-avr
Version: 1:5.4.0+Atmel3.6.1-1
Severity: wishlist

Dear Maintainer,
seei follow up mail.

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
LANGUAGE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-avr depends on:
ii  binutils-avr  2.26.20160125+Atmel3.6.1-4
ii  libc6 2.24-11+deb9u1
ii  libgcc1   1:6.3.0-18
ii  libgmp10  2:6.1.2+dfsg-1
ii  libmpc3   1.1.0-1
ii  libmpfr6  4.0.1-1
ii  libstdc++66.3.0-18
ii  zlib1g1:1.2.8.dfsg-5

gcc-avr recommends no packages.

Versions of packages gcc-avr suggests:
ii  avr-libc  1:2.0.0+Atmel3.6.1-1
ii  gcc   4:6.3.0-4
ii  gcc-doc   5:6.1.0-1

-- no debconf information

Bug#867235: avr-libc: Fails to find iom328pb.h

[Hakan Ardo]

Hi,
thanx for the repport, but iom328pb.h is not provided by avr-libc as far as
I can tell? So it would have to be added to the patch for it to be usefull.
Can I also suggest that you report this upstream aswell:

http://savannah.nongnu.org/bugs/?group=avr-libc

Thanx!


On Wed, Jul 5, 2017 at 1:59 AM, Paul "LeoNerd" Evans  wrote:

> Package: avr-libc
> Version: 1:2.0.0+Atmel3.5.4-1
> Severity: normal
> Tags: patch
>
> Attempting to build a program for the new ATmega328PB, it seems the
> device-specific IO file is not found:
>
> avr-gcc -std=gnu99 -Wall -Os -DF_CPU=1600 -mmcu=atmega328pb -flto
> -ffunction-sections ...
> In file included from src/test.c:1:0:
> /usr/lib/avr/include/avr/io.h:623:6: warning: #warning "device type not
> defined" [-Wcpp]
>  #warning "device type not defined"
>   ^
>
> I do have the required iom328pb.h file though:
>
> -rw-r--r-- 1 root root 27K Jul 22  2016 /usr/lib/avr/include/avr/
> iom328pb.h
>
> Further, I see that iom328pb.h isn't listed in the big long section of
> #ifdef-guarded #includes in the main io.h. I see there is an attempted
> generic fallback section based on value of __AVR_DEV_LIB_NAME__ but it
> seems for whatever reason that isn't kicking in today.
>
> If I simply add the required 2 lines (by copying the 328P example), my
> code will compile fine. Attached is my patch.
>
>
> -- System Information:
> Debian Release: 9.0
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages avr-libc depends on:
> ii  binutils-avr  2.26.20160125+Atmel3.5.3-1
> ii  gcc-avr   1:4.9.2+Atmel3.5.4-1
>
> avr-libc recommends no packages.
>
> avr-libc suggests no packages.
>
> -- no debconf information
>



-- 
Håkan Ardö

Bug#831174: gcc-avr: diff for NMU version 1:4.9.2+Atmel3.5.0-1.1

[Hakan Ardo]

I'm releaseing my version now, which I suppose cancels the NMU?

On Sun, Sep 25, 2016 at 12:36 PM, Sebastian Ramacher <sramac...@debian.org>
wrote:

> On 2016-09-25 10:40:34, Hakan Ardo wrote:
> > Thanx. I've got a version on the way that instead applies this upstream
> fix
> > for gcc 6 compatibility:
> >
> > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=
> ec1cc0263f156f70693a62cf17b254a0029f4852
> >
> > I would prefer to go with thatone unless you have strong reasons for your
> > approach?
>
> No, not all. Just let me know if you prefer if I'd delay it longer or
> cancel it
> altogether.
>
> Cheers
>
> >
> > On Sat, Sep 24, 2016 at 11:43 PM, Sebastian Ramacher <
> sramac...@debian.org>
> > wrote:
> >
> > > Control: tags 831174 + patch
> > > Control: tags 831174 + pending
> > >
> > > Dear maintainer,
> > >
> > > I've prepared an NMU for gcc-avr (versioned as 1:4.9.2+Atmel3.5.0-1.1)
> and
> > > uploaded it to DELAYED/2. Please feel free to tell me if I
> > > should delay it longer.
> > >
> > > Regards.
> > >
> > > --
> > > Sebastian Ramacher
> > >
> >
> >
> >
> > --
> > Håkan Ardö
>
> --
> Sebastian Ramacher
>



-- 
Håkan Ardö

Bug#831174: gcc-avr: diff for NMU version 1:4.9.2+Atmel3.5.0-1.1

[Hakan Ardo]

Thanx. I've got a version on the way that instead applies this upstream fix
for gcc 6 compatibility:

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ec1cc0263f156f70693a62cf17b254a0029f4852

I would prefer to go with thatone unless you have strong reasons for your
approach?

On Sat, Sep 24, 2016 at 11:43 PM, Sebastian Ramacher 
wrote:

> Control: tags 831174 + patch
> Control: tags 831174 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for gcc-avr (versioned as 1:4.9.2+Atmel3.5.0-1.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
>
> Regards.
>
> --
> Sebastian Ramacher
>



-- 
Håkan Ardö

Bug#833805: picon-domains: FTBFS when built with dpkg-buildpackage -A (binary build with no binary artifacts)

[Hakan Ardo]

Thanx for the repport and fix. I'll apply it shortely...

On Mon, Aug 8, 2016 at 11:21 PM, Santiago Vila  wrote:

> Hi.
>
> While we are at it: You might want to modernize debian/rules a little
> bit. In particular, targets build-arch and build-indep are now
> mandatory too (so it's likely that just swapping binary-arch and
> binary-indep might not be enough).
>
> But debhelper (or dh) takes care of this if you let it to care.
>
> For example, after creating debian/compat with "9" as the contents,
> the attached debian/rules would possibly work for picon-domains, and I
> guess that maybe for all the other packages as well without changing a
> single line.
>
> Thanks.




-- 
Håkan Ardö

Bug#808938: ftpwatch: diff for NMU version 1.21+nmu1

[Hakan Ardo]

Thanx, it's looking good.

On Fri, Dec 25, 2015 at 3:18 PM, Andreas Metzler  wrote:

> Control: tags 808938 + patch
> Control: tags 808938 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for ftpwatch (versioned as 1.21+nmu1) and
> uploaded it to DELAYED/15. Please feel free to tell me if I
> should delay it longer.
>
> Regards.
> --
> `What a good friend you are to him, Dr. Maturin. His other friends are
> so grateful to you.'
> `I sew his ears on from time to time, sure'
>



-- 
Håkan Ardö

Bug#808396: /usr/bin/avr-gcc: please provide a "long double" which would be 8 bytes or just an 8-byte double

[Hakan Ardo]

Please consider submitting this upstream, it makes little sense to have it
as a Debian specific feature.

On Sat, Dec 19, 2015 at 3:20 PM, folkert  wrote:

> Package: gcc-avr
> Version: 1:4.8.1+Atmel3.4.5-1
> Severity: wishlist
> File: /usr/bin/avr-gcc
>
> Please provide a "long double" which would be 8 bytes or just an 8-byte
> double.
> We're also doing 64 bit ints so why no 64b double?
>
>
> -- System Information:
> Debian Release: 8.0
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'unstable'), (500,
> 'testing'), (500, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, armhf
>
> Kernel: Linux 4.2.0-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages gcc-avr depends on:
> ii  binutils-avr  2.24+Atmel3.4.5-1
> ii  libc6 2.21-4
> ii  libgmp10  2:6.0.0+dfsg-6
> ii  libmpc3   1.0.2-1
> ii  libmpfr4  3.1.3-1
> ii  zlib1g1:1.2.8.dfsg-2+b1
>
> gcc-avr recommends no packages.
>
> Versions of packages gcc-avr suggests:
> ii  avr-libc  1:1.8.0+Atmel3.4.5-1
> ii  gcc   4:5.3.1-1
> pn  gcc-doc   
> pn  task-c-devel  
>
> -- no debconf information
>



-- 
Håkan Ardö

Bug#808114: avr-libc in Debian testing is incompatible with gcc-avr, linking fails

[Hakan Ardo]

On Wed, Dec 16, 2015 at 9:22 AM, Paul Fertser <fercer...@gmail.com> wrote:
>
> Hello, thank you for the prompt reply.
>
> On Wed, Dec 16, 2015 at 09:05:19AM +0100, Hakan Ardo wrote:
> > Thanks, this is fixed in unstable.
>
> It is, but users of Debian testing right now receive confusing
> messages and are not able to build anything. I might be
> misunderstanding something but this seems important to me.


Indeed. I'm not sure what more to do about it though. The new packages
should propagate to testing in 3 days.

>
>
> Also, do you think it's worth considering to use more stricter
> dependencies between avr-libc and gcc-avr (exact version match)?

An exact version match is too strong as most versions are backwards
compatible. But the current situation is not acceptable. What I have done
in binutils version 2.25+Atmel3.5.0-2 (currently in unstable) is to declear
it incompatible with any avr-libc older than 1.8.0+Atmel3.5.0 and latest
avr-gcc already depends on any binutils-avr newer than 2.25+Atmel3.5.0.
Maybe we should increase that to 2.25+Atmel3.5.0-2 though...

--
Håkan Ardö

Bug#808114: avr-libc in Debian testing is incompatible with gcc-avr, linking fails

[Hakan Ardo]

Thanks, this is fixed in unstable.
Den 16 dec 2015 09:00 skrev "Paul Fertser" :

> Package: avr-libc
> Version: 1:1.8.0+Atmel3.4.5-1
> Severity: grave
>
> This current version depends on gcc-avr (>= 1:4.8.1+Atmel3.4.5), and
> testing already ships 1:4.9.2+Atmel3.5.0-1 which formally fulfills the
> dependency, however, the resulting combination is unusable as the
> specs files supplied with gcc-avr 1:4.9.2+Atmel3.5.0-1 list startup
> files like "crtatmega128.o", and this specific avr-libc version
> provides "crtm128.o". There's also no device-specific lib present so
> upon linking an example demo project these errors are produced:
>
> $ make
> avr-gcc -g -Wall -O2 -mmcu=atmega8-c -o demo.o demo.c
> avr-gcc -g -Wall -O2 -mmcu=atmega8  -Wl,-Map,demo.map -o demo.elf demo.o
> /usr/lib/gcc/avr/4.9.2/../../../avr/bin/ld: cannot find crtatmega8.o: No
> such file or directory
> /usr/lib/gcc/avr/4.9.2/../../../avr/bin/ld: cannot find -latmega8
> collect2: error: ld returned 1 exit status
> Makefile:75: recipe for target 'demo.elf' failed
> make: *** [demo.elf] Error 1
>
> Thank you in advance.
>

Bug#807502: gcc-avr: Missing support for atxmega

[Hakan Ardo]

Hi,
I've now uploaded a new version of avr-libc with the new names on those
files. I'll also update binutils to declear that it wont work with older
avr-libc.

On Fri, Dec 11, 2015 at 7:56 PM, Hakan Ardo <ha...@debian.org> wrote:

> Hi,
> the file you want is crtx384d3.o and not crtatxmega384d3.o (even i the new
> avr-libc). Dont know why he's suddenly trying to use crtatxmega384d3.o
> instead, but the issue seems to be in binutils. I'm reassigning the bug
> there and will keep looking...
>
> On Fri, Dec 11, 2015 at 4:23 PM, Lisandro Damián Nicanor Pérez Meyer <
> perezme...@gmail.com> wrote:
>
>> On Friday 11 December 2015 16:15:52 Hakan Ardo wrote:
>> > Please do.
>>
>> Done, thanks!
>>
>> > It might be that we need to update avr-libc too? That work is in
>> > progress, but was delayed. Should be ready any day now...
>>
>> It might be, if so just ping me as soon as it's available in incoming.d.o
>> and
>> I'll happily give it a try.
>>
>> Thanks!
>>
>> --
>> The volume of a pizza of thickness a and radius z can be described by
>> the following formula:
>>
>> pi zz a
>>
>> Lisandro Damián Nicanor Pérez Meyer
>> http://perezmeyer.com.ar/
>> http://perezmeyer.blogspot.com/
>>
>
>
>
> --
> Håkan Ardö
>



-- 
Håkan Ardö

Bug#807840: [gcc-avr] new version breaks with current avr-libc version

[Hakan Ardo]

Yes, avr-libc (1.8.0, Atmel3.5.0) was uploaded this morning, it should fix
this.

On Sun, Dec 13, 2015 at 6:38 PM, Bastien Montagne 
wrote:

> Package: gcc-avr
> Version: 1:4.9.2+Atmel3.5.0-1
> Severity: normal
>
> --- Please enter the report below this line. ---
>
> Hi,
>
> New 4.9.2 version using Atmel3.5.0 cannot compile simple programs (arduino
> demo ones) for atmega328:
>
> /usr/lib/gcc/avr/4.9.2/../../../avr/bin/ld: cannot find crtatmega328p.o
>> /usr/lib/gcc/avr/4.9.2/../../../avr/bin/ld: cannot find -latmega328p
>>
>
> Downgrading just the gcc-avr package to previous version (4.8.1,
> atmel3.4.5) makes things work again
> perfectly fine.
>
> According to [1], this would be because current avr-libc package is too
> old (1.8.0, Atmel3.4.5).
>
> [1]
> http://stackoverflow.com/questions/31740435/cannot-compile-and-link-avr-program-in-os-x
>
> Thanks,
> Bastien
>
> --- System information. ---
> Architecture: amd64
> Kernel: Linux 4.2.0-1-amd64
>
> Debian Release: stretch/sid
> 990 testing ftp.fr.debian.org
> 990 testing ftp.deb-multimedia.org
> 990 testing deb.torproject.org
> 300 unstable ftp.fr.debian.org
> 200 experimental ftp.fr.debian.org
>
> --- Package information. ---
> Package's Depends field is empty.
>
> Package's Recommends field is empty.
>
> Package's Suggests field is empty.
>



-- 
Håkan Ardö

Bug#807502: gcc-avr: Missing support for atxmega

[Hakan Ardo]

Please do. It might be that we need to update avr-libc too? That work is in
progress, but was delayed. Should be ready any day now...

On Fri, Dec 11, 2015 at 3:57 PM, Lisandro Damián Nicanor Pérez Meyer <
perezme...@gmail.com> wrote:

> Then I would prefer to raise the severity to serious, are you OK with
> that?
>
> --
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
> El dic 11, 2015 11:48 AM, "Thorsten Schulz" <
> thorsten.sch...@uni-rostock.de> escribió:
>
>> Hej,
>>
>> this may be a broader issue. I must confirm this bug for the x32e5 as
>> well.
>> Stepping gcc-avr back to testing helps for the meanwhile.
>>
>> The complained files do not exist in earlier versions. So either this may
>> be a problem of a new feature or some odd configuration. GOOD LUCK, I have
>> no idea :/
>>
>> --
>> To unsubscribe, send mail to 807502-unsubscr...@bugs.debian.org.
>>
>


-- 
Håkan Ardö

Bug#807502: gcc-avr: Missing support for atxmega

[Hakan Ardo]

Hi,
the file you want is crtx384d3.o and not crtatxmega384d3.o (even i the new
avr-libc). Dont know why he's suddenly trying to use crtatxmega384d3.o
instead, but the issue seems to be in binutils. I'm reassigning the bug
there and will keep looking...

On Fri, Dec 11, 2015 at 4:23 PM, Lisandro Damián Nicanor Pérez Meyer <
perezme...@gmail.com> wrote:

> On Friday 11 December 2015 16:15:52 Hakan Ardo wrote:
> > Please do.
>
> Done, thanks!
>
> > It might be that we need to update avr-libc too? That work is in
> > progress, but was delayed. Should be ready any day now...
>
> It might be, if so just ping me as soon as it's available in incoming.d.o
> and
> I'll happily give it a try.
>
> Thanks!
>
> --
> The volume of a pizza of thickness a and radius z can be described by
> the following formula:
>
> pi zz a
>
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
>



-- 
Håkan Ardö

Bug#790103: new default build flag from dpkg: -Wdate-time

[Hakan Ardo]

Hi,
the archlinux avr-gcc seams to be a standard unpatched gcc compiled for the
avr target. I would prefere to base the main avr-gcc package on the atmel
releases as those have historically been of higiher quality for avr usage.
That means avr-gcc will be upgraded to the atmel release 3.5.0 based on gcc
4.9.2 soon. Will that help? Otherwise my suggestion would be that we
introduce a new package, say avr-gcc5, that we base on the gnu release
5.2.0 and keep avr-gcc following the atmel releases.

On Sat, Nov 14, 2015 at 10:49 AM, Mattia Rizzolo  wrote:

> reassign 790103 gcc-avr 1:4.8.1+Atmel3.4.5-1
> retitle 790103 gcc-avr: base on a newer version of gcc
> affects 790103 expeyes
>
> On Sat, Nov 14, 2015 at 10:35:46AM +0100, Georges Khaznadar wrote:
> > > > 3- rebase the package gcc-avr on a newer version of gcc, which may
> be a
> > > >hard work. Such a work seems to exist, for example at
> > > >https://www.archlinux.org/packages/community/x86_64/avr-gcc/
> since
> > > >last July
> > >
> > > This is what should be done, really.
> >
> > I had a look at this last option, but I miss knowledge to keep on with
> > it: as I could guess, the current gcc-avr package is based on a frozen
> > archive of gcc-4.8, which is modified by adding subtle modifications.
> > Obviously, I can freeze an archive of gcc-5, but I cannot craft the
> > modifications to turn it into an efficient compiler for avr.
>
> I miss those too, fwiw.
>
> > So I shall reassign bug #790103 to gcc-avr, and keep the suggested link
> > to expeyes.
>
> done.
>
> > As a matter of fact, I cannot push the severity such a bugreport higher
> > than whishlist, as I cannot provide any help about the work to be done.
>
> This is not what is used to decide the severities :), but still it's a
> whishlist bug.
>
> If this is not fixed in time for the change I'll open another bug
> against expeyes to at least disable the flag.
> If for some reason (=> allow us to test your package, maybe?) you want
> to do it now adding this to d/rules should be sufficient
> DEB_BUILD_MAINT_OPTIONS=reproducible=-timeless
>
> > Best regards, Georges.
>
> enjoy!
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  http://mapreri.org  : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
>



-- 
Håkan Ardö

Bug#790103: new default build flag from dpkg: -Wdate-time

[Hakan Ardo]

On Wed, Nov 18, 2015 at 8:31 PM, Mattia Rizzolo <mat...@mapreri.org> wrote:

> On Wed, Nov 18, 2015 at 08:26:24PM +0100, Hakan Ardo wrote:
> > That means avr-gcc will be upgraded to the atmel release 3.5.0 based on
> gcc
> > 4.9.2 soon.
>
> soon = ?
>

Within a week or three...

Bug#779495: Vanilla AVR toolchain

[Hakan Ardo]

On Wed, Mar 11, 2015 at 4:01 PM, Gregor Riepl onit...@gmail.com wrote:

 whoever of the two that are most out of date varies from time to
 time and from feature to feature. I guess it depends on where in their
 release cycle they are and how hard a time Atmel is having to get
 their patches accepted upstream. Also, there seems to be some patches
 in binutils that avr-develoopers depend on, that will never be
 accepted upstream (for whatever reason). Also, when using the Atmel
 release we get a full toolchain (gcc, binutils and libc) well tested
 to work for avr develoopment.

 In this this case I'd argue that the best course of action would be to offer
 two packages: One that is based on the same sources as the rest of the
 binutils/gcc packages in Debian (plus vanilla avr-libc), and one that builds
 from Atmel toolchain sources. However, I understand that this would lead to
 some confusion for users and also meant additional work.

Yes that would be possible. I'm however reluctant to take on the
additional packages as I'm already behind in the maintenance of the
packages I currently maintain...


 On a different note, I do think that debian/rules should be improved a bit. It
 lacks quilt support (patches are hand-applied) and the whole build process is
 bit hackish. When I built my custom gcc-avr and avr-libc packages, I had to
 fix paths and patches manually.

Agreed!

-- 
Håkan Ardö


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#779495: Vanilla AVR toolchain

[Hakan Ardo]

Hi,
whoever of the two that are most out of date varies from time to
time and from feature to feature. I guess it depends on where in their
release cycle they are and how hard a time Atmel is having to get
their patches accepted upstream. Also, there seems to be some patches
in binutils that avr-develoopers depend on, that will never be
accepted upstream (for whatever reason). Also, when using the Atmel
release we get a full toolchain (gcc, binutils and libc) well tested
to work for avr develoopment.

However, there is a version 3.4.5 release of the Atmel sources which
we should upgrade to. It's still based on gcc 4.8.1 though.


On Mon, Mar 9, 2015 at 7:51 PM, Gregor Riepl onit...@gmail.com wrote:
 It seems avr-libc 1.8.1 will not build with gcc 4.8.1, but vanilla gcc 4.9.1
 works fine. I rolled my own .debs from the regular Debian gcc-4.9.1 sources
 and vanilla 1.8.1 from the project website.

 As I understand, the AVR toolchain on Debian is built from Atmel sources, but
 these are currently out of date. It seems Atmel toolchain developers are now
 actively submitting patches to the gcc project, before making a new version of
 their own toolchain available. This begs the question, wouldn't it be better
 if Debian avr- packages started using vanilla sources instead? It would help
 developers stay more up to date, and avoid relying on patched third party 
 sources.



-- 
Håkan Ardö


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762303: avr-libc ships with old iom256rfr2.h

[Hakan Ardo]

Is it that so? Are all Atmel adjustments included in the 1.8.1?

On Fri, Oct 3, 2014 at 5:50 PM, Simon John g...@the-jedi.co.uk wrote:
 Hi folks,

 is there any update on this? Would it be possible to pull in the header?

 Why are we using the Atmel patches? Its going to be a long time before
 we get avr-libc 1.8.1 that way.

 For a couple of years avr-libc upstream looked a bit dead so Atmel was
 the only choice, but now I'd say upstream have overtaken Atmel again.

 Cheers.


 On 23/09/14 07:19, Hakan Ardo wrote:
 Hi Simon,
 thanx for the report. I suppose we could pull in a single header file
 from avr-libc trunk if the general consensus is that the Atmel version
 is in a bad state.

 Aurelien, you been pushing for using the Atmel patches. Can you see
 any issues with this? Thanx.



 --
 Simon John
 https://github.com/sej7278
 g...@the-jedi.co.uk



-- 
Håkan Ardö


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762303: avr-libc ships with old iom256rfr2.h

[Hakan Ardo]

Hi,
atmel-adjusted headers are provided in  the file avr8-headers-6.2.0.334.zip

On Wed, Oct 8, 2014 at 3:41 PM, Simon John g...@the-jedi.co.uk wrote:
 i'm not sure what the atmel adjustments are. from what i can see they
 just package up the upstream avr-libc.

 if you look at the source from atmel, there doesn't appear to be any
 patches, it just looks like upstream avr-libc:

 http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.4.4/

 i've CC'd the contact address quoted in the README to possibly clarify.

 regards.


 On 08/10/14 13:21, Hakan Ardo wrote:
 Is it that so? Are all Atmel adjustments included in the 1.8.1?

 On Fri, Oct 3, 2014 at 5:50 PM, Simon John g...@the-jedi.co.uk wrote:
 Hi folks,

 is there any update on this? Would it be possible to pull in the header?

 Why are we using the Atmel patches? Its going to be a long time before
 we get avr-libc 1.8.1 that way.

 For a couple of years avr-libc upstream looked a bit dead so Atmel was
 the only choice, but now I'd say upstream have overtaken Atmel again.

 Cheers.


 On 23/09/14 07:19, Hakan Ardo wrote:
 Hi Simon,
 thanx for the report. I suppose we could pull in a single header file
 from avr-libc trunk if the general consensus is that the Atmel version
 is in a bad state.

 Aurelien, you been pushing for using the Atmel patches. Can you see
 any issues with this? Thanx.


 --
 Simon John
 https://github.com/sej7278
 g...@the-jedi.co.uk



-- 
Håkan Ardö


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762303: avr-libc ships with old iom256rfr2.h

[Hakan Ardo]

Hi Simon,
thanx for the report. I suppose we could pull in a single header file
from avr-libc trunk if the general consensus is that the Atmel version
is in a bad state.

Aurelien, you been pushing for using the Atmel patches. Can you see
any issues with this? Thanx.

On Sat, Sep 20, 2014 at 11:01 PM, Simon John g...@the-jedi.co.uk wrote:
 Package: avr-libc
 Version: 1:1.8.0+Atmel3.4.4-1

 When compiling firmware for Pinoccio (https://pinocc.io/) which uses and
 ATmega256RFR2, I get various errors from HardwareSerial.cpp which
 prevents the firmware from compiling. For log see:

 https://gist.github.com/sej7278/51c8853e06ba667d2135

 If I delete
 /usr/share/arduino/hardware/arduino/cores/arduino/HardwareSerial.cpp
 then it builds ok but then breaks serial comms.

 If I replace /usr/lib/avr/include/avr/iom256rfr2.h with the one from
 avr-libc trunk, it compiles and works:

 http://svn.savannah.nongnu.org/viewvc/trunk/avr-libc/include/avr/iom256rfr2.h?revision=2410root=avr-libcview=markup

 See also discussion:

 https://github.com/Pinoccio/firmware-pinoccio/issues/10

 I asked Atmel and they have no plans to move to avr-libc 1.8.1 in their
 SP1 release, not sure about afterwards.

 So a quick fix would be to import the upstream iom256rfr2.h

 The alternative is going back to using avr-libc proper rather than
 Atmel's version, but avr-libc 1.8.1 requires avr-gcc 4.9.1

 Debian jessie/sid with Arduino 1.0.5

 Thanks.

 --
 Simon John
 https://github.com/sej7278
 g...@the-jedi.co.uk



-- 
Håkan Ardö


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#724351: avr-libc: diff for NMU version 1:1.8.0-4.1

[Hakan Ardo]

Thanx. That'll do nicely.

On Mon, Mar 3, 2014 at 12:21 AM, Eric Dorland e...@debian.org wrote:
 tags 724351 + pending
 thanks

 Dear maintainer,

 I've prepared an NMU for avr-libc (versioned as 1:1.8.0-4.1) and
 uploaded it to DELAYED/10. Please feel free to tell me if I
 should delay it longer.

 Regards.

 --
 Eric Dorland e...@kuroneko.ca
 ICQ: #61138586, Jabber: ho...@jabber.com




-- 
Håkan Ardö


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739953: Bug#740391: avr-libc: please use atmel patches

[Hakan Ardo]

Hi, thanx for the reports. Upstream avr-libc develoopment does indeed
seem stalled, so I guess it is time to apply these patches ourself.
The binutils-avr package already contains the atmel patches you refer
to. As for gcc we use gcc 4.8 which I believe contain the Atmel
patches, which are for gcc 4.7.

On Fri, Feb 28, 2014 at 11:46 PM, Aurelien Jarno aure...@debian.org wrote:
 Package: avr-libc
 Version: 1:1.8.0-4
 Severity: wishlist

 avr-libc upstream development seems more or less stalled. Unfortunately
 it means support for new devices and bug fixes are not available. Atmel
 is providing a set of patches to apply on top of avr-libc 1.8.0 at this
 URL:

   
 http://distribute.atmel.no/tools/opensource/Atmel-AVR-Toolchain-3.4.2/avr/avr-patches.tar.gz

 It will solve bug like #739953. Do you think it would be possible to
 use (at least part of) this patchset for the Debian package? Note that
 the tarball also includes patches for binutils and gcc which might be
 interesting to include, though upstream development for these is still
 active.

 -- System Information:
 Debian Release: jessie/sid
   APT prefers unstable
   APT policy: (500, 'unstable'), (1, 'experimental')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386

 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash

 Versions of packages avr-libc depends on:
 ii  binutils-avr  2.23.1-2
 ii  gcc-avr   1:4.8-2

 avr-libc recommends no packages.

 avr-libc suggests no packages.

 -- no debconf information



-- 
Håkan Ardö


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#734320: gdb-avr: Wrong memory map due to missing XML support

[Hakan Ardo]

Hi,
thanx for the report. I've upgraded to gdb 7.6 and enbaled xml
support. If you still believe it is misbehaving please open a new bug.
Also, please consider to make your case upstream:

http://www.gnu.org/software/gdb/bugs/

On Sun, Jan 5, 2014 at 11:05 PM, Johannes Deutsch
johannes.d...@googlemail.com wrote:
 Package: gdb-avr
 Version: 7.4-1+b1
 Severity: normal

 Dear Maintainer,

 the description of the following case is related to the debugging of a real 
 mcu
 with avr-gdb over avarice.

 If i want to set a breakpoint at a specific address in program space with the
 corresponding gdb command

 (gdb) break *0xfff

 gdb answers my approach with

 warning: Can not parse XML memory map; XML support was disabled at compile
 time
 Breakpoint 1 at 0x800dbe

 Although after continuing the execution gdb breaks at the right address, it
 looks like gdb creates a breakpoint in data space at first sight. In addition
 the warning is scary :)

 Instead of the message above one would expect a mere

 Breakpoint 1 at 0xdbe

 Best regards



 -- System Information:
 Debian Release: jessie/sid
   APT prefers testing
   APT policy: (500, 'testing')
 Architecture: i386 (i686)

 Kernel: Linux 3.10-3-686-pae (SMP w/2 CPU cores)
 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages gdb-avr depends on:
 ii  libc62.17-97
 ii  libncurses5  5.9+20130608-1
 ii  libtinfo55.9+20130608-1

 gdb-avr recommends no packages.

 Versions of packages gdb-avr suggests:
 pn  gdb-doc  none

 -- no debconf information



-- 
Håkan Ardö


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#733603: avr-libc: avr-man unable to work due to missing files/directories

[Hakan Ardo]

Hi again,
moving them was not trivial. For a clean solution I had to patch
doxygen. I've, made an upstream pull-request:

  https://github.com/doxygen/doxygen/pull/90

Hopefully I'll propagte to debian before too long. Otherwise we'll
hack differently...


On Sun, Jan 5, 2014 at 12:17 PM, Hakan Ardo ha...@debian.org wrote:
 OK, we'll rename them and move them again.

 On Fri, Jan 3, 2014 at 10:19 AM, Ivan Shmakov i...@siamics.net wrote:
 fixed 733603 1:1.8.0-4
 thanks

 Hakan Ardo ha...@debian.org writes:
 On Mon, Dec 30, 2013 at 11:40 AM, Simon Kainz wrote:

   After inspecting avr-man, i see the line:

   exec man -M /usr/share/doc/avr-libc/man $@

   But the path /usr/share/doc/avr-libc/man is not created by
   installing avr-libc nor is it by any other package.

   the manpages was moved there in version 1.8.0-4, currently in
   testing.

 I’m thus marking the bug as fixed there (so it would be archived
 when the current stable won’t be supported anymore.)

   In the version in stable they reside in /usr/lib/share/man/man3/

 … However, I don’t seem to understand the choice of either
 location.  Isn’t it customary to use /usr/share/man for
 everything in Debian, possibly adding appropriate suffixes to
 the filenames, as in: readline.3readline.gz, TIFFsize.3tiff.gz,
 Encode::Unicode.3perl.gz, and thus, presumably, floor.3avr.gz,
 random_r.3avr.gz, etc.?

 Going this way, there’s no need for any MANPATH tweaking, and
 even the manual page browsers that are not based on man(1) (such
 as Emacs’ woman.el) will just work “out of box.”

 --
 FSF associate member #7257



 --
 Håkan Ardö



-- 
Håkan Ardö


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#733603: avr-libc: avr-man unable to work due to missing files/directories

[Hakan Ardo]

OK, we'll rename them and move them again.

On Fri, Jan 3, 2014 at 10:19 AM, Ivan Shmakov i...@siamics.net wrote:
 fixed 733603 1:1.8.0-4
 thanks

 Hakan Ardo ha...@debian.org writes:
 On Mon, Dec 30, 2013 at 11:40 AM, Simon Kainz wrote:

   After inspecting avr-man, i see the line:

   exec man -M /usr/share/doc/avr-libc/man $@

   But the path /usr/share/doc/avr-libc/man is not created by
   installing avr-libc nor is it by any other package.

   the manpages was moved there in version 1.8.0-4, currently in
   testing.

 I’m thus marking the bug as fixed there (so it would be archived
 when the current stable won’t be supported anymore.)

   In the version in stable they reside in /usr/lib/share/man/man3/

 … However, I don’t seem to understand the choice of either
 location.  Isn’t it customary to use /usr/share/man for
 everything in Debian, possibly adding appropriate suffixes to
 the filenames, as in: readline.3readline.gz, TIFFsize.3tiff.gz,
 Encode::Unicode.3perl.gz, and thus, presumably, floor.3avr.gz,
 random_r.3avr.gz, etc.?

 Going this way, there’s no need for any MANPATH tweaking, and
 even the manual page browsers that are not based on man(1) (such
 as Emacs’ woman.el) will just work “out of box.”

 --
 FSF associate member #7257



-- 
Håkan Ardö


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727117: binutils-avr: FTBFS on s390x - blocks testing migration

[Hakan Ardo]

Hi,
thanx for the report. I've made a few test builds on s390x now and it
seems to build just fine, so I'm not sure what to do about this. I'm
uploading a new version with other fixes now, and I'll dig more if
this issue persists...

On Tue, Oct 22, 2013 at 2:39 PM, Niels Thykier ni...@thykier.net wrote:
 Package: binutils-avr
 Version: 2.23.1-1
 Severity: serious

 Hi,

 Your package FTBFS on s390x, but it built there in the past.  This
 currently prevents binutils-avr from migrating to testing.

 ~Niels



-- 
Håkan Ardö


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727117: Please retry building binutils-avr 2.23.1-1 on s390x

[Hakan Ardo]

Hi,
I've made a few test builds of  binutils-avr 2.23.1-1 in a
sid_s390x-dchroot chroot on zelenka.debian.org and they all worked
just fine.

gb binutils-avr_2.23.1-1 . s390x

-- 
Håkan Ardö


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725770: gcc-avr: Needs binutils-avr later than 2.20.1-3

[Hakan Ardo]

Yes, your right. I'll update the dependency. Thanx for the report.


On Tue, Oct 8, 2013 at 8:48 AM, Moritz Augsburger 
bug+deb...@moritz.augsburger.name wrote:

 Package: gcc-avr
 Version: 1:4.8-1
 Severity: serious
 Justification: Policy 3.5

 With binutils-avr 2.20.1-3 installed, I got pseudo op errors when trying
 to compile:
 avr-gcc -c -mmcu=attiny261 -I. -gdwarf-2 -DF_CPU=800UL -Os
 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums
 -ffunction-sections -fdata-sections -Wall -Wstrict-prototypes
 -Wa,-adhlns=./main.lst  -std=gnu99 -Wundef -MMD -MP -MF .dep/main.o.d
 main.c -o main.o
 /tmp/cc3WUFDu.s: Assembler messages:
 /tmp/cc3WUFDu.s:8: Error: unknown pseudo-op: `.cfi_sections'
 /tmp/cc3WUFDu.s:16: Error: unknown pseudo-op: `.cfi_startproc'
 /tmp/cc3WUFDu.s:22: Error: unknown pseudo-op: `.cfi_endproc'
 /tmp/cc3WUFDu.s:31: Error: unknown pseudo-op: `.cfi_startproc'
 /tmp/cc3WUFDu.s:37: Error: unknown pseudo-op: `.cfi_endproc'
 /tmp/cc3WUFDu.s:46: Error: unknown pseudo-op: `.cfi_startproc'
 /tmp/cc3WUFDu.s:52: Error: unknown pseudo-op: `.cfi_endproc'
 /tmp/cc3WUFDu.s:61: Error: unknown pseudo-op: `.cfi_startproc'
 /tmp/cc3WUFDu.s:67: Error: unknown pseudo-op: `.cfi_endproc'
 /tmp/cc3WUFDu.s:81: Error: unknown pseudo-op: `.cfi_startproc'
 /tmp/cc3WUFDu.s:86: Error: unknown pseudo-op: `.cfi_def_cfa_offset'
 /tmp/cc3WUFDu.s:87: Error: unknown pseudo-op: `.cfi_offset'
 /tmp/cc3WUFDu.s:90: Error: unknown pseudo-op: `.cfi_def_cfa_offset'
 /tmp/cc3WUFDu.s:91: Error: unknown pseudo-op: `.cfi_offset'
 /tmp/cc3WUFDu.s:149: Error: unknown pseudo-op: `.cfi_endproc'
 /tmp/cc3WUFDu.s:162: Error: unknown pseudo-op: `.cfi_startproc'
 /tmp/cc3WUFDu.s:277: Error: unknown pseudo-op: `.cfi_endproc'
 make: *** [main.o] Error 1

 Upgrading to binutils-avr 2.23.1-1 fixed this issue, so I think the
 dependency should be adjusted.

 -- System Information:
 Debian Release: jessie/sid
   APT prefers testing
   APT policy: (500, 'testing'), (1, 'experimental'), (1, 'unstable')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386

 Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores)
 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages gcc-avr depends on:
 ii  binutils-avr  2.23.1-1
 ii  libc6 2.17-93
 ii  libgmp10  2:5.1.2+dfsg-3
 ii  libmpc3   1.0.1-1
 ii  libmpfr4  3.1.1-2
 ii  zlib1g1:1.2.8.dfsg-1

 gcc-avr recommends no packages.

 Versions of packages gcc-avr suggests:
 ii  avr-libc  1:1.8.0-4
 pn  gcc-4.2   none
 pn  gcc-doc   none
 pn  task-c-devel  none

 -- no debconf information




-- 
Håkan Ardö

Bug#689223: binutils-avr: Linker relaxations broken

[Hakan Ardo]

Hi,
I'm uploading version 2.23.1-1 of binutils-avr to unstable. Could you check
if it fixes this issue?

  Thanx


On Sun, Sep 30, 2012 at 4:05 PM, Hans Schou ch...@schou.dk wrote:

 Package: binutils-avr
 Version: 2.20.1-3
 Severity: normal

 Dear Maintainer,

* What led up to the situation?

 Compiling LUFA demo VirtualSerialMassStorage.


* What exactly did you do (or not do) that was effective (or
  ineffective)?

 cd Demos/Device/ClassDriver/VirtualSerialMassStorage
 make

* What was the outcome of this action?

 The packe did not compile reporting:

 /usr/lib/gcc/avr/4.7.0/../../../avr/lib/avr51/crtusb1286.o: In function
 `__bad_interrupt':
 ../../../../crt1/gcrt1.S:195: relocation truncated to fit: R_AVR_13_PCREL
 against symbol `__vector_11' defined in .text.__vector_11 section in
 ../../../../LUFA/Drivers/USB/Core/AVR8/USBInterrupt_AVR8.o

 There is a work around by removing the relaxe option from the build make
 file:
   perl -i -pe 's/-Wl,--relax//' LUFA/Build/lufa_build.mk

 The more correct way is to patch 307 elf32-avr.c:

 https://github.com/pld-linux/crossavr-binutils/blob/master/307-binutils-fix-AVRTC-424.patch

 Above information is based on Dean Camera's explanation.

 cheers!

 -- System Information:
 Debian Release: wheezy/sid
   APT prefers testing
   APT policy: (500, 'testing')
 Architecture: amd64 (x86_64)

 Kernel: Linux 3.2.0-3-amd64 (SMP w/6 CPU cores)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages binutils-avr depends on:
 ii  libc6  2.13-35

 binutils-avr recommends no packages.

 Versions of packages binutils-avr suggests:
 ii  binutils  2.22-6.1

 -- no debconf information




-- 
Håkan Ardö

Bug#644485: /usr/bin/avr-gcc: Assertion failure in get_known_segmented_expression

[Hakan Ardo]

Hi,
I'm uploading avr-gcc v 4.8 and I no longer get an assertion error. Could
you verify that this is OK now?


On Thu, Oct 6, 2011 at 11:01 AM, Bernhard Kuemel bernh...@bksys.at wrote:

 Package: gcc-avr
 Version: 1:4.3.5-1
 Severity: normal
 File: /usr/bin/avr-gcc


 bug1:

 bernhard@b:~/src/attiny45/bug1$ make
 avr-gcc  -mmcu=attiny45   bootloader.S   -o bootloader
 bootloader.S: Assembler messages:
 bootloader.S:8: Internal error!
 Assertion failure in get_known_segmented_expression at read.c line 5347.
 Please report this bug.
 make: *** [bootloader] Error 1

 bug2:
 bernhard@b:~/src/attiny45/bug1$ make
 avr-gcc  -mmcu=attiny45   bootloader.S   -o bootloader
 bootloader.S: Assembler messages:
 bootloader.S:11: Warning: symbol L0 undefined; zero assumed
 /usr/lib/gcc/avr/4.3.5/../../../avr/lib/avr25/crttn45.o: In function
 `__bad_interrupt':
 .../../../../crt1/gcrt1.S:193: warning: internal error: out of range error
 /tmp/cc9DBxMl.o: In function `main':
 (.text+0xfff): warning: internal error: out of range error

 Not sure if bug2 is a bug, but 'internal error' sounds like it.

 -- System Information:
 Debian Release: 6.0.2
   APT prefers stable
   APT policy: (500, 'stable')
 Architecture: i386 (i686)

 Kernel: Linux 2.6.32-5-686-bigmem (SMP w/2 CPU cores)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages gcc-avr depends on:
 ii  binutils-avr  2.20.1-1   Binary utilities supporting
 Atmel'
 ii  libc6 2.11.2-10  Embedded GNU C Library:
 Shared lib
 ii  libgmp3c2 2:4.3.2+dfsg-1 Multiprecision arithmetic
 library
 ii  libmpfr4  3.0.0-2multiple precision
 floating-point

 gcc-avr recommends no packages.

 Versions of packages gcc-avr suggests:
 ii  avr-libc  1:1.6.8-2  Standard C library for Atmel
 AVR d
 pn  gcc-4.2   none (no description available)
 ii  gcc-doc   5:3documentation for the GNU
 compiler
 pn  task-c-devel  none (no description available)

 -- no debconf information

 *** /home/bernhard/src/attiny45/bug1/bootloader.S
 #include avr/io.h

 main1:
 rjmpmain1

 ;bug 1
 tlsize=(tlend-TinyAsyLoad)
 ..org FLASHEND-tlsize

 ;bug (?) 2
 ;.org FLASHEND-(tlend-TinyAsyLoad)




 ;   .section .bootloader,ax,@progbits
 .global main
 main:
 TinyAsyLoad:
 rjmpmain1   ;THIS MUST RESIDE AT THE LAST
 ;ADDRESS OF FLASH
 tlend:

 *** /home/bernhard/src/attiny45/bug1/Makefile
 CC  = avr-gcc
 CPPFLAGS= -mmcu=attiny45

 bootloader:

 clean:
 rm -f bootloader





-- 
Håkan Ardö

Bug#684226: patch available

[Hakan Ardo]

Great, we'll upgrade.

On Mon, Jul 8, 2013 at 7:58 PM, reportbug.deb...@moritz.augsburger.namewrote:

 On 2013-07-08 06:41, reportbug.deb...@moritz.augsburger.name wrote:
  according to
 
 https://gnu.googlesource.com/gcc/+/724fcbc302453e801b823c317a1f729a1e3e3dd1
  it got at least implemented, but still not in the official tree.

 I have to correct myself, it's in 4.8.x.




-- 
Håkan Ardö

Bug#696397: gdb-avr: add Built-Using field

[Hakan Ardo]

Thanx for the patch! I'll upgrade the package.

On Thu, Dec 20, 2012 at 1:46 PM, Ansgar Burchardt ans...@debian.org wrote:
 Package: src:gdb-avr
 Version: 7.2-1
 Severity: serious
 Tags: patch
 Usertags: built-using

 gdb-avr uses the gdb source from gdb-source, but does not indicate so with a
 Built-Using field (Policy 7.8). This means the archive might not contain the
 full source for this package as the specific version of gdb used to build the
 package could be replaced with a newer version.

 I've attached a patch adding the Built-Using field to the gdb-avr binary
 package.

 Ansgar



-- 
Håkan Ardö


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#695514: linking with AVR Libc fails with crttn13a.o: No such file

[Hakan Ardo]

Thanx for the report. When they'll have it properly fixed upstream I
can update the package.

On Sun, Dec 9, 2012 at 4:38 PM, Ivan Shmakov oneing...@gmail.com wrote:
 Package: avr-libc
 Version: 1:1.8.0-3

 While trying to build a program for ATtiny13A on a recent Debian
 Wheezy, I've got (using both the 1:4.7.0-2 and 1:4.7.2-1 gcc-avr
 packages):

 $ avr-gcc -g -O2 -Wall -pedantic -std=gnu99 -mmcu=attiny13a \
   -L/usr/lib/avr/lib/avr25  ../6pp5iouyw6unnen7egfroozp8b.c \
   -o 6pp5iouyw6unnen7egfroozp8b
 /usr/lib/gcc/avr/4.7.0/../../../avr/bin/ld: crttn13a.o: No such file: No such 
 file or directory
 collect2: error: ld returned 1 exit status
 $

 It was suggested [1] that this issue is related to [2].  As a
 workaround, the addition of /usr/lib/avr/lib/avr25/crttn13a.o
 -nostartfiles (also suggested in [1]) seems to work.

 [1] http://comments.gmane.org/gmane.comp.hardware.avr.libc.devel/6455
 [2] https://savannah.nongnu.org/bugs/?35407

 --
 FSF associate member #7257



-- 
Håkan Ardö


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#693572: gcc-avr: Segfaults when compiled with the -mint8 option

[Hakan Ardo]

Thanx for the report. I'll upgrade to 4.7.1.

On Sun, Nov 18, 2012 at 1:22 AM, nuess0r nussgip...@gmx.ch wrote:
 Package: gcc-avr
 Version: 4.7.0-2
 Severity: important
 Tags: upstream patch

 Dear Maintainer,

 avr-gcc segfaults when a source is compiled with the -mint8 option.

 This bug is known and discussed by the gcc maintainers, it's fixed in version 
 4.7.1, bug report is here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261


 -- System Information:
 Debian Release: wheezy/sid
   APT prefers unstable
   APT policy: (500, 'unstable')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386

 Kernel: Linux 3.6-5.slh.3-aptosid-amd64 (SMP w/8 CPU cores; PREEMPT)
 Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages gcc-avr depends on:
 ii  binutils-avr  2.20.1-3
 ii  libc6 2.13-36
 ii  libgmp10  2:5.0.5+dfsg-2
 ii  libmpc2   0.9-4
 ii  libmpfr4  3.1.0-5
 ii  zlib1g1:1.2.7.dfsg-13

 gcc-avr recommends no packages.

 Versions of packages gcc-avr suggests:
 pn  avr-libc  none
 pn  gcc-4.2   none
 pn  gcc-doc   none
 pn  task-c-devel  none



-- 
Håkan Ardö


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#686173: ld segfaults when linking uncomforming ELF

[Hakan Ardo]

Thanx!
I'm uploading a new version binutils-avr with this patch. Please
verify that it solves the problem.

On Wed, Aug 29, 2012 at 5:54 PM, Scott Howard showard...@gmail.com wrote:
 owner 686173
 submitter 686173 jack23...@hotmail.com
 reassign 686173 binutils-avr 2.20.1-2
 severity 686173 serious
 tags 686173 patch
 forwarded 686173 http://sourceware.org/bugzilla/show_bug.cgi?id=12161
 thanks

 The following upstream bug [1] appears in Debian and the patch should
 be applied to the debian sources [2].

 When compiling the Ethernet library examples in the arduino package
 for a mega 256 or ADK target board, ld will crash with a segfault.
 When the below patch is applied to the Debian sources, it compiles
 cleanly.

 It's related to the fact that the mega 256 target board uses the
 -Wl,--relax linker option since it has greater than 128 kB of memory
 [3] which somehow started causing problems once code was compiled with
 gcc 4.7.

 Thank you!
 Regards,
 Scott



 [1] http://sourceware.org/bugzilla/show_bug.cgi?id=12161
 [2] 
 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf32-avr.c.diff?cvsroot=srconly_with_tag=binutils-2_22-branchr1=1.51r2=1.51.2.1
 [3] http://sourceware.org/bugzilla/show_bug.cgi?id=13612



-- 
Håkan Ardö


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#684226:

[Hakan Ardo]

Hi,
thanx for the report, I've forwarded it upstream:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54280

On Wed, Aug 15, 2012 at 2:51 AM, a...@avarner.servebeer.com
a...@avarner.servebeer.com wrote:
 Using the version of avr-gcc that comes with Atmel Studio 6.0 (for Windows, 
 unfortunately), -mmcu=atxmega128b1 is accepted:

 $ cat xmegab1test.c

 #include avr/io.h

 int main(void)
 {
 while(1)
 {
 //TODO:: Please write your application code
 }
 }

 $ 'C:\Program Files\Atmel\Atmel Studio 
 6.0\extensions\Atmel\AVRGCC\3.4.0.65\AVRToolchain\bin\avr-gcc' -o /dev/null 
 -mmcu=atxmega128b1 xmegab1test.c -Wall -Wextra

 $ echo $?
 0

 $ 'C:\Program Files\Atmel\Atmel Studio 
 6.0\extensions\Atmel\AVRGCC\3.4.0.65\AVRToolchain\bin\avr-gcc' --version
 avr-gcc.exe (AVR_8_bit_GNU_Toolchain_3.4.0_663) 4.6.2
 Copyright (C) 2011 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 $ 'C:\Program Files\Atmel\Atmel Studio 
 6.0\extensions\Atmel\AVRGCC\3.4.0.65\AVRToolchain\bin\avr-gcc' --target-help 
 -mlist-devices
 The following options are target specific:
   -mcall-prologuesUse subroutines for function prologues and
   epilogues
   -mint8  Use an 8-bit 'int' type
   -mlist-devices  Print the list of parts supported while printing
   --target-help
   -mmcu=MCU   Select the target MCU
   -mno-interrupts Change the stack pointer without disabling
   interrupts
   -mpmem-wrap-around  Make the linker relaxation machine assume that a
   program counter wrap-around occurs.
   -mrelax Relax branches
   -mshort-calls   Use rjmp/rcall (limited range) on 8K devices
   -mtiny-stackChange only the low 8 bits of the stack pointer

 List of parts supported by avr-gcc:
 at90s2313   __AVR_AT90S2313__
 at90s2323   __AVR_AT90S2323__
 at90s2333   __AVR_AT90S2333__
 at90s2343   __AVR_AT90S2343__
 attiny22__AVR_ATtiny22__
 attiny26__AVR_ATtiny26__
 at90s4414   __AVR_AT90S4414__
 at90s4433   __AVR_AT90S4433__
 at90s4434   __AVR_AT90S4434__
 at90s8515   __AVR_AT90S8515__
 at90c8534   __AVR_AT90C8534__
 at90s8535   __AVR_AT90S8535__
 ata6289 __AVR_ATA6289__
 ata5272 __AVR_ATA5272__
 attiny13__AVR_ATtiny13__
 attiny13a   __AVR_ATtiny13A__
 attiny2313  __AVR_ATtiny2313__
 attiny2313a __AVR_ATtiny2313A__
 attiny24__AVR_ATtiny24__
 attiny24a   __AVR_ATtiny24A__
 attiny4313  __AVR_ATtiny4313__
 attiny44__AVR_ATtiny44__
 attiny44a   __AVR_ATtiny44A__
 attiny84__AVR_ATtiny84__
 attiny84a   __AVR_ATtiny84A__
 attiny25__AVR_ATtiny25__
 attiny45__AVR_ATtiny45__
 attiny85__AVR_ATtiny85__
 attiny261   __AVR_ATtiny261__
 attiny261a  __AVR_ATtiny261A__
 attiny461   __AVR_ATtiny461__
 attiny461a  __AVR_ATtiny461A__
 attiny861   __AVR_ATtiny861__
 attiny861a  __AVR_ATtiny861A__
 attiny43u   __AVR_ATtiny43U__
 attiny87__AVR_ATtiny87__
 attiny48__AVR_ATtiny48__
 attiny88__AVR_ATtiny88__
 attiny80__AVR_ATtiny80__
 attiny828   __AVR_ATtiny828__
 at86rf401   __AVR_AT86RF401__
 at43usb355  __AVR_AT43USB355__
 at76c711__AVR_AT76C711__
 atmega103   __AVR_ATmega103__
 at43usb320  __AVR_AT43USB320__
 ata5505 __AVR_ATA5505__
 at90usb82   __AVR_AT90USB82__
 at90usb162  __AVR_AT90USB162__
 atmega8u2   __AVR_ATmega8U2__
 atmega16u2  __AVR_ATmega16U2__
 atmega32u2  __AVR_ATmega32U2__
 attiny167   __AVR_ATtiny167__
 attiny1634  __AVR_ATtiny1634__
 ata6285 __AVR_ATA6285__
 ata6286 __AVR_ATA6286__
 atmega8 __AVR_ATmega8__
 atmega8a__AVR_ATmega8A__
 atmega48__AVR_ATmega48__
 atmega48a   __AVR_ATmega48A__
 atmega48pa  __AVR_ATmega48PA__
 atmega48p   __AVR_ATmega48P__
 atmega88__AVR_ATmega88__
 atmega88a   __AVR_ATmega88A__
 atmega88p   __AVR_ATmega88P__
 atmega88pa  __AVR_ATmega88PA__
 atmega8515  __AVR_ATmega8515__
 atmega8535  __AVR_ATmega8535__
 atmega8hva  __AVR_ATmega8HVA__
 at90pwm1__AVR_AT90PWM1__
 at90pwm2__AVR_AT90PWM2__
 at90pwm2b   __AVR_AT90PWM2B__
 at90pwm3__AVR_AT90PWM3__
 at90pwm3b   __AVR_AT90PWM3B__
 at90pwm81   __AVR_AT90PWM81__
 at90pwm161  __AVR_AT90PWM161__
 ata5790 

Bug#684226: gcc-avr: Add ATXMEGA128B1 support

[Hakan Ardo]

Hi,
that is an old patch for gcc 4.5 that's supposed to have been
incorporated with gcc 4.7 which is what we currently use. Maybe the
name was changed? There is support for the following xmega128 devices:

atxmega128a1 atxmega128a1u atxmega128a3 atxmega128d3

On Wed, Aug 8, 2012 at 1:16 AM, Andrew Varner a...@avarner.servebeer.com 
wrote:
 Package: gcc-avr
 Version: 1:4.7.0-2
 Severity: wishlist
 Tags: patch

 Please add support for XMEGA128B1. I believe the only patch needed is here:
 http://distribute.atmel.no/tools/opensource/avr-gcc/gcc-4.5.1/50-gcc-4.5.1-new-devices.patch

 Unfortunately, I can't figure out how to compile gcc-avr from source, so I 
 can't test this hypothesis.

 Versions of packages gcc-avr depends on:
 ii  binutils-avr2.20.1-2 Binary utilities supporting 
 Atmel'
 ii  libc6   2.11.3-4 Embedded GNU C Library: Shared 
 lib
 ii  libgmp102:5.0.5+dfsg-2   Multiprecision arithmetic library
 ii  libmpc2 0.9-4multiple precision complex 
 floatin
 ii  libmpfr43.1.0-5  multiple precision floating-point
 ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

 gcc-avr recommends no packages.

 Versions of packages gcc-avr suggests:
 ii  avr-libc  1:1.8.0-2  Standard C library for Atmel AVR 
 d
 pn  gcc-4.2   none (no description available)
 pn  gcc-doc   none (no description available)
 pn  task-c-devel  none (no description available)

 -- no debconf information



-- 
Håkan Ardö


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#678584: (no subject)

[Hakan Ardo]

Thanx for the patch and sorry for being slow with this. I'll try to
have this fixed within the next few days. Feel free to NMU if you
like, just keep me informed please.

On Wed, Jul 25, 2012 at 11:23 AM, Eduard Bloch e...@gmx.de wrote:
 avr-l...@packages.debian.org
 Subject: Re: avr-libc manpages override libc manpages if PATH contains (for
  example) /usr/lib/ccache
 Reply-To:
 In-Reply-To: 2012060422.ga31...@sli.dy.fi

 severity 678584 serious
 tags 678584 +patch
 thanks

 Hallo,
 * Sami Liedes [Sat, Jun 23 2012, 01:04:22AM]:

 Steps to reproduce (MANPATH is not set and /etc/manpath.config has not
 been modified from the default):

 1. export PATH=/usr/lib/ccache:/usr/bin:/bin
 2. man 3 printf

 Expected result:

 2. man page for printf(3) from libc is shown

 Actual result:

 2. man page for avr_stdio(3) from avr-libc is shown instead

 Which might justify a reason for severity serious - breaks unrelated
 software.

 And it's even worse. The avr-man command which AFAICS was supposed to
 get the right manpages from the alternative path, is NOT WORKING!

 $ avr-man errno
 No manual entry for errno

 Looking at the script, I see that it refers to
 /usr/share/doc/avr-libc/man and not to /usr/lib/share... so it looks for
 me like the root cause is the wrong installation path of the manpages.

 Unless the maintainer reacts, I plan to NMU this package in a couple of
 days. Patch is attached, however untested because the build is FTBFSing
 on my workstation system. Will be investigated ASAP.

 This is pdfTeX, Version 3.1415926-2.4-1.40.13 (TeX Live 2012/Debian)
  restricted \write18 enabled.
 ---! /home/ed/.texmf-var/web2c/pdftex/pdflatex.fmt doesn't match pdftex.pool
 (Fatal format file error; I'm stymied)
 make[5]: [refman.pdf] Fehler 1 (ignoriert)
 makeindex refman.idx
 Input index file refman.idx not found.
 Usage: makeindex [-ilqrcgLT] [-s sty] [-o ind] [-t log] [-p num] [idx0 idx1 
 ...]
 make[5]: *** [refman.pdf] Fehler 1

 --
 Lassen Sie sich 'Sklaventreiber' auf die Stirn tätowieren. Das ist
 ehrlich, da wissen wir alle woran wir sind.
 -- Volker Pispers



-- 
Håkan Ardö


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#677059: avr-libc: Manpages installed in strange directory

[Hakan Ardo]

Hi,
they cant be placed among the standard manpages as they conflict with
the native libc manpages in manpages-dev. The intention is that you
read them using avr-man instead of man. That way those files are
considered datafiles of avr-man and the poliy places such files under
/usr/lib/. However avr-man seem to be currently broken, so it should
be fixed.

An alternative would be to consider them architecture-dependent man
pages and place them under /usr/share/man/man3/avr/. Yet another
option would be to place them under  /usr/share/man/man3 but with an
.3avr suffix. Any preferences?

On Mon, Jun 11, 2012 at 1:43 PM, Matthias Urlichs matth...@urlichs.de wrote:
 Package: avr-libc
 Version: 1:1.8.0-2
 Severity: normal

 /usr/lib/share/man/man3

 ??? not exactly policy compliant, I'd say. Or easily discoverable.

 -- System Information:
 Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (700, 'testing'), (650, 'unstable'), (600, 'stable'), (550, 
 'experimental')
 Architecture: amd64 (x86_64)

 Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: 
 LC_ALL set to en_US.UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages avr-libc depends on:
 ii  binutils-avr  2.20.1-2
 ii  gcc-avr       1:4.7.0-2

 avr-libc recommends no packages.

 avr-libc suggests no packages.

 -- no debconf information





-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#675759: avr-libc/pgmspace.h is not ANSI compliant

[Hakan Ardo]

Hi,
thanx for the report. This does not seem to be debian specific so
please consider reporting it upstream aswell:

http://savannah.nongnu.org/bugs/?group=avr-libc

On Sun, Jun 3, 2012 at 10:02 AM, Bernhard bewoe...@yahoo.de wrote:
 Package: avr-libc
 Version: 1.8.0-2
 Severity: normal

 Hello,

 the header file pgmspace.h uses the inline-attribute.
 This attribute is not part of ANSI C.

 My programs are compiled with the option -ansi.
 Here is a minimal test program:

 #include avr/io.h
 #include avr/pgmspace.h

 int main (void)
 {
       while (1);
       return (0);
 }

 Please compile this with:
 $ avr-gcc -mmcu=atmega644p -ansi file

 Compilation aborts because of the non-ansi include attribute in pgmspace.h

 In GCC manual:
 there is the predefined macro __STRICT_ANSI__ available, if parameter
 -ansi is used.
 Please don't use the inline-attribute in case of __STRICT_ANSI__.

 In avr-libc manual:
 it is described, that this library has to be an ansi-c library.
 This is described in chapter 1.2.

 If you need more informations, please let me know.

 Best regards
 Bernhard





-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#674077: Regression: AVR-GCC: arithmetics produce completely wrong result

[Hakan Ardo]

Hi,
this is fixed in the 4.7 release which is currently in experimental,
but should be released to unstable soon.

On Tue, May 22, 2012 at 11:56 PM, Nicolas Schodet
schodet-report...@ni.fr.eu.org wrote:
 Package: gcc-avr
 Version: 1:4.5.3-4
 Severity: important


 There is a bug in 30-gcc-4.5.1-fixedpoint-3-4-2010.patch which is
 included in the debian package, please see
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52474

 Thanks,

 Nicolas Schodet.





-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#645822: Sparc FTBFS is fixed by --disable-checking

[Hakan Ardo]

Thanx, I'll apply and release as soon as I verified that it still builds on x86.

On Fri, Nov 18, 2011 at 9:46 PM, Jurij Smakov ju...@wooyd.org wrote:
 Hello,

 I've just confirmed that gcc-avr builds successfully on sparc if
 --disable-checking is dropped from configure options.

 Best regards,
 --
 Jurij Smakov                                           ju...@wooyd.org
 Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC






-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#648612: Patches with incorrect paths

[Hakan Ardo]

Are you saying that chunks with ./binutils works while chunks with
./gas does not? I've just tried to rebuild on a freshly update
chroot and it works just fine. Might this be due to some issue with
your system?

On Mon, Nov 14, 2011 at 12:01 AM, Adam Baxter volta...@voltagex.org wrote:
 I'm not entirely sure how to provide a patch to a patch, but the patches
 that dpkg-buildpackage fails on are:

 36-binutils-2.20.1-assembler-options.patch:+++ ./gas/config/tc-avr.c
 2011-02-08 11:01:47.0 -0600
 55-binutils-2.20.1-atxmega128b1.patch:+++ ./gas/config/tc-avr.c
 2010-11-12 11:35:32.0 -0600
 55-binutils-2.20.1-atxmega128b1.patch:+++ ./gas/doc/c-avr.texi    2010-11-12
 11:36:39.0 -0600
 59-binutils-2.20.1-atmega32_5_50_90_pa.patch:+++ ./gas/config/tc-avr.c
 2011-02-16 15:22:24.0 -0600
 59-binutils-2.20.1-atmega32_5_50_90_pa.patch:+++ ./gas/doc/as.info
 2011-02-17 11:59:53.0 -0600
 59-binutils-2.20.1-atmega32_5_50_90_pa.patch:+++ ./gas/doc/c-avr.texi
 2011-02-16 15:42:20.0 -0600

 in debian/atmel_patches

 the paths, at least for me, needed to be gas/ and not .gas/




-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#640398: avr-libc-user-manual.pdf.gz is not readable

[Hakan Ardo]

Hi,
thanx for the report, it does indeed seem like the pdf is broken.

On Sun, Sep 4, 2011 at 9:43 PM, Yann Dirson ydir...@free.fr wrote:
 Package: avr-libc
 Version: 1:1.7.1-2
 Severity: normal

 I could not read anything more than the chapter bookmarks with any of
 evince, xpdf, gv, pdftotext (no acroread here, but it does not count
 as not being part of Debian any more).  Looks like there is a
 problem somewhere...

 -- System Information:
 Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'oldstable'), (500, 'unstable'), (500, 
 'stable'), (101, 'experimental')
 Architecture: amd64 (x86_64)

 Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores)
 Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash

 Versions of packages avr-libc depends on:
 ii  binutils-avr                  2.20.1-2   Binary utilities supporting 
 Atmel'
 ii  gcc-avr                       1:4.5.3-2  The GNU C compiler (cross 
 compiler

 avr-libc recommends no packages.

 avr-libc suggests no packages.

 -- no debconf information






-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#634341: gcc-avr: GCC bug 45263 is not taken into account

[Hakan Ardo]

Sorry for the delay and thanx for the patch as well as for the
confirmation. I'll make a new release including it...

On Thu, Aug 11, 2011 at 5:12 PM, Changwoo Ryu cw...@debian.org wrote:
 I confirm the patch. Without it, obvious Arduino sketches don't work.

 This is fixed in upstream version 4.6.2, but 4.6.2 is not available in
 Debian yet.

 --
 Changwoo Ryu cw...@debian.org




-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#594279: gcc-avr: non-standard gcc/g++ used for build (gcc-4.3)

[Hakan Ardo]

Any chance of having it reintroduced? Latest upstream version is based
on gcc 4.3.4. The avr backend of gcc is developed somewhat separated
from main gcc and only synced occasionally.

On Thu, Mar 31, 2011 at 12:39 PM, Julien Cristau jcris...@debian.org wrote:
 severity 594279 serious
 kthxbye

 On Wed, Aug 25, 2010 at 05:58:55 +, Matthias Klose wrote:

 Package: gcc-avr
 Version: 1:4.3.5-1
 Severity: normal
 User: debian-...@lists.debian.org
 Usertags: non-standard-compiler, gcc-4.3

 This package builds with a non standard compiler version; please check
 if this package can be built with the default version of gcc/g++.

 Please keep this report open until the package uses the default
 compiler version for the package build.

 The severity of this report is likely to be raised before the release.

 gcc-4.3-source is no longer in sid, bumping to serious severity.

 Cheers,
 Julien






-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#594279: gcc-avr: non-standard gcc/g++ used for build (gcc-4.3)

[Hakan Ardo]

It's the gcc source tar archive. If avr-gcc is the only package still
needing it, I suppose it would make sens to place it in the gcc-avr
source package.

On Thu, Mar 31, 2011 at 1:09 PM, Matthias Klose d...@debian.org wrote:
 On 31.03.2011 13:05, Hakan Ardo wrote:
 Any chance of having it reintroduced? Latest upstream version is based
 on gcc 4.3.4. The avr backend of gcc is developed somewhat separated
 from main gcc and only synced occasionally.

 I would like to avoid it if possible.  I'll have a look what you are using 
 from
 the gcc-4.3-source package. maybe it's easy to just add the tarball into the
 gcc-avr package?






-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#611525: pulseaudio-module-zeroconf: missing dependency on rygel

[Hakan Ardo]

Package: pulseaudio-module-zeroconf
Version: 0.9.21-3+b1
Severity: normal

The zeroconf features does not seem to work without installing rygel, so
pulseaudio-module-zeroconf should depend on it.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages pulseaudio-module-zeroconf depends on:
ii  libavahi-client3 0.6.27-2Avahi client library
ii  libavahi-common3 0.6.27-2Avahi common library
ii  libc62.11.2-6Embedded GNU C Library: Shared lib
ii  libcap2  1:2.19-3support for getting/setting POSIX.
ii  libgdbm3 1.8.3-9 GNU dbm database routines (runtime
ii  libpulse00.9.21-3+b1 PulseAudio client libraries
ii  pulseaudio   0.9.21-3+b1 PulseAudio sound server

Versions of packages pulseaudio-module-zeroconf recommends:
ii  avahi-daemon  0.6.27-2   Avahi mDNS/DNS-SD daemon

pulseaudio-module-zeroconf suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#608940: ftpwatch should be in /usr/bin not /usr/sbin

[Hakan Ardo]

Hi,
thanx for the repport, I'll move it to /usr/bin.

On Tue, Jan 4, 2011 at 8:12 PM, Florian Lohoff f...@zz.de wrote:
 Package: ftpwatch
 Version: 1.20
 Severity: minor


 Hi,
 i think ftpwatch should be in /usr/bin not /usr/sbin as its not
 a system binary. Its for general user consumption as also the
 manpage states:

        Every user who wants to use it should install it
        into his crontab file.

 FHS States:

 3.14.1 Purpose
        Utilities used for system administration (and other root-only commands)
        are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin contains
        binaries essential for booting, restoring, recovering, and/or repairing
        the system in addition to the binaries in /bin.15 Programs executed
        after /usr is known to be mounted (when there are no problems) are
        generally placed into /usr/sbin.  Locally-installed system
        administration programs should be placed into /usr/local/sbin.16

 and continues:

 4.10 /usr/sbin : Non-essential standard system binaries
 4.10.1 Purpose
        This directory contains any non-essential binaries used exclusively by
        the system administrator. System administration programs that are
        required for system repair, system recovery, mounting /usr, or other
        essential functions must be placed in /sbin instead.24

 /usr/sbin is root only for system administration which ftpwatch is
 IMHO not ...

 Flo

 -- System Information:
 Debian Release: 5.0.6
  APT prefers stable
  APT policy: (500, 'stable')
 Architecture: i386 (i686)

 Kernel: Linux 2.6.26-2-686 (SMP w/4 CPU cores)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
 LC_ALL set to en_US.utf-8)
 Shell: /bin/sh linked to /bin/bash

 Versions of packages ftpwatch depends on:
 ii  perl                     5.10.0-19lenny2 Larry Wall's Practical Extraction
 ii  perl-modules [libnet-per 5.10.0-19lenny2 Core Perl modules

 ftpwatch recommends no packages.

 ftpwatch suggests no packages.

 -- no debconf information






-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#550985: xmega support, 128 KB avrs

[Hakan Ardo]

Hi,
xmega devices are currently supported using gcc 4.3.4, but there are
still no patch-sets for gcc 4.4.

On Fri, Jul 30, 2010 at 4:19 AM, Scott Howard showard...@gmail.com wrote:
 Hi, I'm just checking up on the status of this bug and patch (for
 xmega devices).

 Arduino is now in testing, so there will be an influx of users using gcc-avr.

 Regards,
 Scott






-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#587574: avr-libc: Missing processor spec - wdt.h include file.

[Hakan Ardo]

Hi,
thanx for the report. As it's not debian specific I've forwarded it upstream:

  https://savannah.nongnu.org/bugs/index.php?30600

On Tue, Jun 29, 2010 at 11:32 PM, Frank Miles f...@u.washington.edu wrote:
 Package: avr-libc
 Version: 1:1.6.8-1
 Severity: normal


 There is no processor selection for the atmega325P in the wdt.h include file.
 Please add a:

        || defined(__AVR_ATmega325__) \

 around line 215.  Thanks!

 -- System Information:
 Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
 Architecture: amd64 (x86_64)

 Kernel: Linux 2.6.32 (SMP w/8 CPU cores; PREEMPT)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages avr-libc depends on:
 ii  binutils-avr                  2.20-3     Binary utilities supporting 
 Atmel'
 ii  gcc-avr                       1:4.3.4-1  The GNU C compiler (cross 
 compiler

 avr-libc recommends no packages.

 avr-libc suggests no packages.

 -- no debconf information






-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#482356: avr-binutils 2.20-2 in debian/testing are still lacking coff-avr support

[Hakan Ardo]

Yes, there is currently no coff-avr support for version 2.20. When the
coff-avr patch is ported to binutils 2.20 I'll apply it...

On Fri, Jan 1, 2010 at 11:04 PM, wzabo...@elektron.elka.pw.edu.pl
w.zabolo...@elka.pw.edu.pl wrote:
 The coff-avr support is needed for testing of AVR code with VMLAB (
 http://www.amctools.com/vmlab.htm ).
 Unfortunately, the version  2.20-2 , which is available in testing still
 lacks this support.
 I have to use the avr-objcopy extracted from the old 2.18 version of
 avr-binutils to generate coff from elf.







-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#558335: avr-objdump disassembles lpm rX, Z wrongly

[Hakan Ardo]

On Tue, Dec 1, 2009 at 4:55 PM, Elrond
elrond+bugs.debian@samba-tng.org wrote:
 Hi Hakan,

 Thanks for your quick investigations!

 * Can I tag the bug confirmed?

Yes, I can reproduce it.

 * Do you need any further input from me to continue with
  this issue?

Probably not, but if so I'll let you know :)

-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#558335: avr-objdump disassembles lpm rX, Z wrongly

[Hakan Ardo]

Hi,
thanx for the report. I'll look into it...

On Sat, Nov 28, 2009 at 1:17 AM, Elrond
elrond+bugs.debian@samba-tng.org wrote:

 Package: binutils-avr
 Version: 2.20-2

 Here's the problem in very short:

  avr% avr-objdump -d bug-lpm.o
   try_asm:
    0:   25 91           lpm     r18, Z+
    2:   24 91           lpm     r18, Z+
    4:   08 95           ret

 The longer description can be found at [1].

 Which brings us to the strange part of this issue:

 I reported this upstream [1] but upstream claims, that it
 is fixed in 2.20. And they suggest, that this is a problem
 in the debian packaging.
 I hope you can clear this thing up much faster than I can.


    Elrond


 [1] http://sourceware.org/bugzilla/show_bug.cgi?id=10964






-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#558335: avr-objdump disassembles lpm rX, Z wrongly

[Hakan Ardo]

Hi,
it seams to be the patch adding support for xmega devices that
intoruces this bug.

On Sun, Nov 29, 2009 at 10:46 AM, Hakan Ardo ha...@ardoe.net wrote:
 Hi,
 thanx for the report. I'll look into it...

 On Sat, Nov 28, 2009 at 1:17 AM, Elrond
 elrond+bugs.debian@samba-tng.org wrote:

 Package: binutils-avr
 Version: 2.20-2

 Here's the problem in very short:

  avr% avr-objdump -d bug-lpm.o
   try_asm:
    0:   25 91           lpm     r18, Z+
    2:   24 91           lpm     r18, Z+
    4:   08 95           ret

 The longer description can be found at [1].

 Which brings us to the strange part of this issue:

 I reported this upstream [1] but upstream claims, that it
 is fixed in 2.20. And they suggest, that this is a problem
 in the debian packaging.
 I hope you can clear this thing up much faster than I can.


    Elrond


 [1] http://sourceware.org/bugzilla/show_bug.cgi?id=10964






 --
 Håkan Ardö




-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#554468: binutils-avr: Compile stop with incompatiblity problems

[Hakan Ardo]

OK,
I'm afraid that I've not got access to that source. But I've tried to
compile a file test4.c containing:

  volatile int cnt;
  int main() {
while (1) cnt++;
return 0;
  }

Using a similar commandline:

  avr-gcc -DMASTER -Wall -Wstrict-prototypes -g2 -Os -mmcu=atmega128
-mno-tablejump -fpack-struct -fno-common -gdwarf-2 -mcall-prologues
-DSTACK_OVERFLOW_CHECK -D'FIRMWARE_BACKUP_START=(0x1L)'
-D'FIRMWARE_BACKUP_END=((0x1L + (0xE000L - 0L)))'
-D'FIRMWARE_START=(0L)' -D'FIRMWARE_END=(0xE000L)'
-D'BOOTLOADER_START=(0x1E000L)' -D'BOOTLOADER_END=(0x1FC00L)'
-I/srv/home/michael/Projects/rtm/rtm5101
-I/srv/home/michael/Projects/rtm/rtm5101/include -c -o test4.o test4.c
  avr-ld -mavr5 test4.o /usr/lib/gcc/avr/4.3.4/avr51/libgcc.a -o firmware.elf

and that works just fine here. Could you verify that this is working
for you too. If thats the case, the problem is most likely in the
linker script /srv/home/michael/Projects/rtm/rtm5101/hal/atmega128.lds,
which might have to be updated...


On Thu, Nov 5, 2009 at 6:10 AM, Michael Ott mich...@king-coder.de wrote:
 Hello Hakan!

 what are you trying to compile?
 From Pigeon Point: BMR-AVR-AMCm 2.0.0

  Package: binutils-avr
  Version: 2.20-1
  Severity: grave
  Justification: renders package unusable
 
  Compile PPS source code
 
  Get the following errors:
  avr-gcc -DMASTER -Wall -Wstrict-prototypes -g2 -Os -mmcu=atmega128 
  -mno-tablejump -fpack-struct -fno-common -gdwarf-2 -mcall-prologues 
  -DSTACK_OVERFLOW_CHECK -D'FIRMWARE_BACKUP_START=(0x1L)' 
  -D'FIRMWARE_BACKUP_END=((0x1L + (0xE000L - 0L)))' 
  -D'FIRMWARE_START=(0L)' -D'FIRMWARE_END=(0xE000L)' 
  -D'BOOTLOADER_START=(0x1E000L)' -D'BOOTLOADER_END=(0x1FC00L)' 
  -I/srv/home/michael/Projects/rtm/rtm5101 
  -I/srv/home/michael/Projects/rtm/rtm5101/include -c -o hal.o hal.c
  echo SECTIONS { .sdr.file : { sdr_file_start = .; \
                 *(.data) sdr_file_end = .; }}  sdr-data.o.lds
  avr-ld -mavr5 -r -o sdr-data.o -b binary 
  /srv/home/michael/Projects/rtm/rtm5101/sdr-data.bin -b elf32-avr -T 
  sdr-data.o.lds
  rm -f sdr-data.o.lds
  avr-ld -mavr5 -T/srv/home/michael/Projects/rtm/rtm5101/hal/atmega128.lds 
  -\( init.o hal.o sdr-data.o libhal.o ../app/libapp.o ../lib/lib.a 
  ../app/libcompat/libcompat.a -\) \
             /usr/lib/gcc/avr/4.3.4/avr51/libgcc.a -o firmware.elf
  avr-ld: avr:51 architecture of input file `init.o' is incompatible with 
  avr output
  avr-ld: avr:51 architecture of input file `hal.o' is incompatible with avr 
  output
  avr-ld: avr:51 architecture of input file `../lib/lib.a(checksum.o)' is 
  incompatible with avr output
  avr-ld: avr:51 architecture of input file `../lib/lib.a(memcmp.o)' is 
  incompatible with avr output
  avr-ld: avr:51 architecture of input file `../lib/lib.a(memcmp_P.o)' is 
  incompatible with avr output
  avr-ld: avr:51 architecture of input file `../lib/lib.a(memcpy.o)' is 
  incompatible with avr output
  avr-ld: avr:51 architecture of input file `../lib/lib.a(memcpy_P.o)' is 
  incompatible with avr output
  avr-ld: avr:51 architecture of input file `../lib/lib.a(memcpy_P_far.o)' 
  is incompatible with avr output
  avr-ld: avr:51 architecture of input file `../lib/lib.a(memset.o)' is 
  incompatible with avr output
  avr-ld: avr:51 architecture of input file `../lib/lib.a(parse_tm.o)' is 
  incompatible with avr output
  avr-ld: avr:51 architecture of input file `../lib/lib.a(hex2int.o)' is 
  incompatible with avr output
  make[1]: *** [firmware.elf] Error 1
  make[1]: Leaving directory `/srv/home/michael/Projects/rtm/rtm5101/hal'
  make: *** [all] Error 2
 
  Works with testing version of binutils-avr
 
 
 
  -- System Information:
  Debian Release: squeeze/sid
   APT prefers unstable
   APT policy: (700, 'unstable'), (650, 'testing'), (600, 'stable'), (1, 
  'experimental')
  Architecture: i386 (i686)
 
  Kernel: Linux 2.6.30-2-686 (SMP w/1 CPU core)
  Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
  Shell: /bin/sh linked to /bin/dash
 
  Versions of packages binutils-avr depends on:
  ii  libc6                  2.10.1-5          GNU C Library: Shared 
  libraries
  ii  zlib1g                 1:1.2.3.3.dfsg-15 compression library - runtime
 
  binutils-avr recommends no packages.
 
  Versions of packages binutils-avr suggests:
  ii  binutils                      2.20-2     The GNU assembler, linker and 
  bina
 
  -- no debconf information
 
 
 



 --
 Håkan Ardö
 CU

  Michael

 --
    ,''`.
   : :' :   Michael Ott
   `. `'    e-mail: michael at king-coder dot de
     `-


 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iEYEARECAAYFAkryXi4ACgkQC3RUCgaMhSwhNwCdHHtwATcocN3V2WG52nZ2JQzl
 UzwAn0q764v3s5H+w8fjNBRZ6oSMeSo5
 =7cwb
 -END PGP SIGNATURE-





-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#554468: binutils-avr: Compile stop with incompatiblity problems

[Hakan Ardo]

Hi,
what are you trying to compile?

On Wed, Nov 4, 2009 at 8:39 PM, Michael Ott mich...@king-coder.de wrote:
 Package: binutils-avr
 Version: 2.20-1
 Severity: grave
 Justification: renders package unusable

 Compile PPS source code

 Get the following errors:
 avr-gcc -DMASTER -Wall -Wstrict-prototypes -g2 -Os -mmcu=atmega128 
 -mno-tablejump -fpack-struct -fno-common -gdwarf-2 -mcall-prologues 
 -DSTACK_OVERFLOW_CHECK -D'FIRMWARE_BACKUP_START=(0x1L)' 
 -D'FIRMWARE_BACKUP_END=((0x1L + (0xE000L - 0L)))' -D'FIRMWARE_START=(0L)' 
 -D'FIRMWARE_END=(0xE000L)' -D'BOOTLOADER_START=(0x1E000L)' 
 -D'BOOTLOADER_END=(0x1FC00L)' -I/srv/home/michael/Projects/rtm/rtm5101 
 -I/srv/home/michael/Projects/rtm/rtm5101/include -c -o hal.o hal.c
 echo SECTIONS { .sdr.file : { sdr_file_start = .; \
                *(.data) sdr_file_end = .; }}  sdr-data.o.lds
 avr-ld -mavr5 -r -o sdr-data.o -b binary 
 /srv/home/michael/Projects/rtm/rtm5101/sdr-data.bin -b elf32-avr -T 
 sdr-data.o.lds
 rm -f sdr-data.o.lds
 avr-ld -mavr5 -T/srv/home/michael/Projects/rtm/rtm5101/hal/atmega128.lds -\( 
 init.o hal.o sdr-data.o libhal.o ../app/libapp.o ../lib/lib.a 
 ../app/libcompat/libcompat.a -\) \
            /usr/lib/gcc/avr/4.3.4/avr51/libgcc.a -o firmware.elf
 avr-ld: avr:51 architecture of input file `init.o' is incompatible with avr 
 output
 avr-ld: avr:51 architecture of input file `hal.o' is incompatible with avr 
 output
 avr-ld: avr:51 architecture of input file `../lib/lib.a(checksum.o)' is 
 incompatible with avr output
 avr-ld: avr:51 architecture of input file `../lib/lib.a(memcmp.o)' is 
 incompatible with avr output
 avr-ld: avr:51 architecture of input file `../lib/lib.a(memcmp_P.o)' is 
 incompatible with avr output
 avr-ld: avr:51 architecture of input file `../lib/lib.a(memcpy.o)' is 
 incompatible with avr output
 avr-ld: avr:51 architecture of input file `../lib/lib.a(memcpy_P.o)' is 
 incompatible with avr output
 avr-ld: avr:51 architecture of input file `../lib/lib.a(memcpy_P_far.o)' is 
 incompatible with avr output
 avr-ld: avr:51 architecture of input file `../lib/lib.a(memset.o)' is 
 incompatible with avr output
 avr-ld: avr:51 architecture of input file `../lib/lib.a(parse_tm.o)' is 
 incompatible with avr output
 avr-ld: avr:51 architecture of input file `../lib/lib.a(hex2int.o)' is 
 incompatible with avr output
 make[1]: *** [firmware.elf] Error 1
 make[1]: Leaving directory `/srv/home/michael/Projects/rtm/rtm5101/hal'
 make: *** [all] Error 2

 Works with testing version of binutils-avr



 -- System Information:
 Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (650, 'testing'), (600, 'stable'), (1, 
 'experimental')
 Architecture: i386 (i686)

 Kernel: Linux 2.6.30-2-686 (SMP w/1 CPU core)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages binutils-avr depends on:
 ii  libc6                  2.10.1-5          GNU C Library: Shared libraries
 ii  zlib1g                 1:1.2.3.3.dfsg-15 compression library - runtime

 binutils-avr recommends no packages.

 Versions of packages binutils-avr suggests:
 ii  binutils                      2.20-2     The GNU assembler, linker and 
 bina

 -- no debconf information






-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#550985: gcc: New upstream release 4.4.1 available

[Hakan Ardo]

Hi,
I'm preparing an update to 4.3.4 with a patch to support the xmega
devices. I can't find any xmega support for 4.4 so I'm staying with
4.3 for now...

On Wed, Oct 14, 2009 at 5:49 PM, Bernhard bewo...@online.de wrote:
 Package: gcc-avr
 Version: 1:4.3.3-1
 Severity: wishlist

 Hello,

 Since July 2009, there is version 4.4.1 of GCC available.
 Please upgrade the package to this new upstream release.

 Thank you.

 Regards
 Bernhard





-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#543016: Bug#518742: avr toolchain FTBFS

[Hakan Ardo]

Hi,
I'm working on it. The main problem is that I have to use the source
from gcc-source and binutill-source packages, which are constantly
changing and the avr specific patches have to be updated every time.
There have been suggestions about using an exact version dependency on
the source packages, but the release managers don't like that. There
have also been a suggestion to include the binutils and gcc src in the
avr specific packages but the general thought about that is that it
will make our archive too big.

On Sat, Oct 24, 2009 at 6:12 PM, Luk Claes l...@debian.org wrote:
 Hi

 gcc-avr and binutils-avr fail to build from source since quite some
 months. If there is no progress in the near future, I'm afraid I'll be
 forced to remove the avr packages from testing. Please have a look at
 fixing the build errors.

 Cheers

 Luk






-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#540660: dvb-apps: Missing muxes

[Hakan Ardo]

Package: dvb-apps
Version: 1.1.1+rev1207-3
Severity: normal

Hi,
there are two muxes missing in dvb-t/se-Horby_Sallerup. Please add:

T 65000 8MHz 3/4 NONE QAM64 8k 1/4 NONE
T 57000 8MHz 3/4 NONE QAM64 8k 1/4 NONE


  Tahnx



# diff -c /usr/share/dvb/dvb-t/se-Horby_Sallerup se-Horby_Sallerup
*** /usr/share/dvb/dvb-t/se-Horby_Sallerup  2008-09-05
11:52:04.0 +0200
--- se-Horby_Sallerup   2009-08-09 15:18:16.0 +0200
***
*** 1,5 
--- 1,7 
  # Sweden - Hörby/Sallerup
  # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
+ T 65000 8MHz 3/4 NONE QAM64 8k 1/4 NONE
+ T 57000 8MHz 3/4 NONE QAM64 8k 1/4 NONE
  T 48200 8MHz 3/4 NONE QAM64 8k 1/4 NONE
  T 50600 8MHz 3/4 NONE QAM64 8k 1/4 NONE
  T 63400 8MHz 3/4 NONE QAM64 8k 1/4 NONE


-- System Information:
Debian Release: 3.1
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages dvb-apps depends on:
ii  libc6 2.7-14 GNU C Library: Shared libraries
ii  makedev   2.3.1-82   creates device files in /dev
ii  udev  0.093-1/dev/ and hotplug management daemo

dvb-apps recommends no packages.

-- no debconf information



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#534973: stable updates

[Hakan Ardo]

I don't know, but I would agree that the risk is small enough to drop
the matter and close the case.

On Tue, Jul 7, 2009 at 7:09 AM, Michael S.
Gilbertmichael.s.gilb...@gmail.com wrote:
 On Mon, 6 Jul 2009 21:44:44 +0200 Thijs Kinkhorst wrote:
  version 1:1.5.2-5 that I released to unstable is suitable for stable
  aswell. Prior to this bugfix unstable and stable both contained
  version 1:1.5.2-4. Attached is a patch with the fix. Do you want me to
  build it for stable aswell?

 Thank you for getting in touch with us. Judging from the context in which 
 this
 bug manifests itself, I think releasing a DSA for it is overkill. It happens
 when creating a new X-Face header, which is something you would do rarely,
 mostly not with any random image you didn't check out before, always as an
 unprivileged user and what can happen is a crash of the conversion which is
 harly harmful. The security implications of this are very minor. Normally
 there's a process to fix minor security issues through a stable point update
 but I think this one is even too minor for that. It's great that testing and
 unstable are fixed for the future, but I propose that we just leave it at
 that and consider this case closed.

 i would agree.  the implications (a user-initiated application crash on
 invalid input) are so minor that this probably should not have been
 tagged as a security concern nor given a CVE in the first place.
 although, has the possibility of code injection been fully ruled out?

 mike






-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#534973: stable updates

[Hakan Ardo]

Hi,
version 1:1.5.2-5 that I released to unstable is suitable for stable
aswell. Prior to this bugfix unstable and stable both contained
version 1:1.5.2-4. Attached is a patch with the fix. Do you want me to
build it for stable aswell?

On Sun, Jul 5, 2009 at 12:59 AM, Michael S.
Gilbertmichael.s.gilb...@gmail.com wrote:
 reopen 534973
 fixed 534973 1:1.5.2-5
 thanks

 hello,

 please assist the security team to prepare updates for this issue in
 the stable releases.  thank you.

 mike






-- 
Håkan Ardö


patch
Description: Binary data

Bug#534973: compface: bufer overflow in xbm-file

[Hakan Ardo]

Hi,
thx for the report. Attached is a patch fixing the buffer overflow.
I'll prepare a new release tonight.

On Sun, Jun 28, 2009 at 7:10 PM, metalho...@hushmail.com wrote:
 Subject: compface: bufer overflow in xbm-file
 Package: compface
 Version: 1:1.5.2-4
 Severity: grave
 Justification: user security hole
 Tags: security

 *** Please type your report below this line ***

 please note that serius bufer overflow vuln in compface:

  http://milw0rm.org/exploits/8982

 -- System Information:
 Debian Release: 5.0.2
  APT prefers stable
  APT policy: (500, 'stable')
 Architecture: i386 (i686)

 Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash

 Versions of packages compface depends on:
 ii  libc6                         2.7-18     GNU C Library: Shared
 libraries
 pi  libcompfaceg1                 1:1.5.2-4  Compress/decompress
 images for mai

 compface recommends no packages.

 compface suggests no packages.

 -- no debconf information

 --
 Improve your driving ability with a stop at traffic school. Click now!
  http://tagline.hushmail.com/fc/BLSrjkqhynuzyryeUmYRzlGlYnNeBH1StpEla6mapWGfI2Km3snlzpriJVG/







-- 
Håkan Ardö


patch
Description: Binary data

Bug#502448: Missing dependency on libgnomevfs2-extra

[Hakan Ardo]

Package: referencer
Version: 1.1.3-2
Severity: normal

The metadata download features need libgnomevfs2-extra to be nistalled to work.

-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#501424: gcc-avr

[Hakan Ardo]

Hi,
avr-gcc version 1:4.3.2-1 has been uploaded to unstable. It fixes bug
#501424 by dissabling the patches that has been incoporated into
gcc-4.3-source v 4.3.2-1which have propagated to lenny. I did not
include an extra copy of the gcc src code in avr-gcc as people are
conserned about the size of our distribution.

-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#501424: gcc-avr: FTBFS in lenny: patching fails (again)

[Hakan Ardo]

6Hi,
this continuous changing of the src provided by gcc is starting to get
tiresome :) I think we should include a copy of the gcc src in the avr-gcc
src pkg and drop the src-dep on the gcc-src package.

On Wed, Oct 8, 2008 at 6:54 PM, Tobias Klauser [EMAIL PROTECTED] wrote:

 The patch 40-1-gcc-4.3.0-bug-30243.patch was incorporated in gcc-4.3.2
 (which is the version in Lenny according to [1]). So this patch can
 safely be dropped from gcc-avr.

 [1] http://packages.qa.debian.org/g/gcc-4.3.html

 All other patches seem to apply fine.

 Cheers, Tobias

 --
  .''`. Tobias Klauser - Debian enthusiast
  : :'  :tklauser@(distanz|access.unizh).ch
  `. `'` GPG-Key: 0x3A445520
   `-





-- 
Håkan Ardö

Bug#501424: just say no to bad ideas

[Hakan Ardo]

6

On Wed, Oct 8, 2008 at 10:15 PM, Thomas Viehmann [EMAIL PROTECTED] wrote:

 Hi,

  this continuous changing of the src provided by gcc is starting to get
  tiresome :) I think we should include a copy of the gcc src in the
  avr-gcc src pkg and drop the src-dep on the gcc-src package.
 No. As a matter of policy we do not want to have that type of
 duplication. This has been discussed on the various Debian lists
 numerous times.


Yes, that's true. If it is going to work out in the long run I believe we
need some stricter policy on how the debs providing the src are to be
handled. Otherwise this kind of FTBS bugs will show up with every other
release of the gcc pkg.




 Kind regards

 T.
 --
 Thomas Viehmann, http://thomas.viehmann.net/





-- 
Håkan Ardö

Bug#493454: Easy fix

[Hakan Ardo]

Thanx, I'll upload an update.

On Sat, Aug 9, 2008 at 11:18 PM, Jurij Smakov [EMAIL PROTECTED] wrote:
 tags 493454 patch
 thanks

 This is caused by a missing dependency on texlive-extra-utils,
 avr-libc uses epstopdf from this package during build. I'm not
 providing a trivial patch, confirmed that this change causes the
 package to build successfully in pbuilder chroot.

 Cheers.
 --
 Jurij Smakov   [EMAIL PROTECTED]
 Key: http://www.wooyd.org/pgpkey/  KeyID: C99E03CC






-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#482356: #482356 - binutils-avr: add coff-avr support

[Hakan Ardo]

Hi,
thx for the reminder. As of version 2.18-4, the winavr patch
31-binutils-2.18-avr-coff.patch is applied. Is that sattisfying or did
the supplied patch contain anything more?

On Sun, Aug 3, 2008 at 11:51 PM, Andrew O. Shadoura [EMAIL PROTECTED] wrote:
 Hello.

 Sorry for pinging you, but please, take a look at this bug.
 Thanks.

 --
 WBR, Andrew




-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#491560: binutils-avr: downgrading to 2.18-3 works

[Hakan Ardo]

Hi,
the problem is that you need to upgrade avr-gcc to 1:4.3.0-3, because
I had to move the /usr/avr dir to become fhs compatible. I suppse I
should have made the new binutils conflict with the old gcc to reflect
this, but I missed that. The new gcc has been stuck in unstable
because of some build problem (#490310) , I'll look in to and try to
make a new gcc release asap.

On Mon, Jul 21, 2008 at 4:28 PM, Alexander Neumann [EMAIL PROTECTED] wrote:
 Hi Hakan,

 * Alexander Neumann [EMAIL PROTECTED] wrote:
 I verified this bug on several machines, downgrading from 2.18-4 to 2.18-3
 works.  I also set the severity from 'normal' to 'important', because this
 bug renders the package unusable.

 Will you be able to upload a fixed version BEFORE the FREEZE this week?

 I think that this would be a very important goal, otherwise a broken version
 of this package would be shipped with lenny... Feel free to concat me, if
 you need any assistance.

 Cheers,
 - Alexander




-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#490310: Bug#491560: binutils-avr: downgrading to 2.18-3 works

[Hakan Ardo]

Hi,
the build problem of gcc-avr seems to be that a few of the patches I
apply has now been applied to the src provided by gcc-src.

To prevent this kind of problems in the future do you think it's a
good idea to Build-Depend on an exact version of gcc-4.3-source? I
tried something like that some years ago but it messed up the
transactions to testing...

Another solution would be to duplicate the gcc source in gcc-avr.

On Mon, Jul 21, 2008 at 4:28 PM, Alexander Neumann [EMAIL PROTECTED] wrote:
 Hi Hakan,

 * Alexander Neumann [EMAIL PROTECTED] wrote:
 I verified this bug on several machines, downgrading from 2.18-4 to 2.18-3
 works.  I also set the severity from 'normal' to 'important', because this
 bug renders the package unusable.

 Will you be able to upload a fixed version BEFORE the FREEZE this week?

 I think that this would be a very important goal, otherwise a broken version
 of this package would be shipped with lenny... Feel free to concat me, if
 you need any assistance.

 Cheers,
 - Alexander




-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#491399: /usr/bin/avr-gcc: calling functions with division from an isr

[Hakan Ardo]

Hi,
in a realtime system, this kind of behaviour can be caused by a lot of
things and it's not at all clear that it's the compiler. If you are
possitive it's the compiler I would suggest that you file an upstream
bug-repport as describe in:

  /usr/share/doc/gcc-4.3/README.Bugs

On Sat, Jul 19, 2008 at 9:03 AM, Jasen Betts [EMAIL PROTECTED] wrote:
 Package: gcc-avr
 Version: 1:4.3.0-2
 Severity: important
 File: /usr/bin/avr-gcc


 I put a small piece of code that does uint8_t division (modulo (%)
 operator actually) in a function and called it from an isr
 this worked fine until I started making heavy use of modulo and division
 in the main part of the program - suddenly the main part stops
 working

 moving the modulo operation into the ISR caused the bug to go away.

 -- System Information:
 Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
 Architecture: i386 (i686)

 Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
 Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash

 Versions of packages gcc-avr depends on:
 ii  binutils-avr  2.18-3 Binary utilities supporting 
 Atmel'
 ii  libc6 2.7-10 GNU C Library: Shared libraries
 ii  libgmp3c2 2:4.2.2+dfsg-3 Multiprecision arithmetic library
 ii  libmpfr1ldbl  2.3.1.dfsg.1-2 multiple precision floating-point

 gcc-avr recommends no packages.

 -- no debconf information






-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#486844: avr-libc: FHS violation

[Hakan Ardo]

Hi,
no I think /usr/lib/avr is better. These are cross-compilation files,
and should not be mixed with the native files.

I have this fixed and will release as soon as I've done some more testing...

On Sun, Jul 6, 2008 at 9:23 PM, Dmitry E. Oboukhov [EMAIL PROTECTED] wrote:
OK, where to?

 May be so?

 /usr/avr/include- /usr/include/avr
 /usr/avr/bin- /usr/lib/binutils-avr
 /usr/avr/lib- /usr/lib/avr-libc

 --
 ... mpd is off

 . ''`. Dmitry E. Oboukhov
 : :'  : [EMAIL PROTECTED]
 `. `~' GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.6 (GNU/Linux)

 iD8DBQFIcRusq4wAz/jiZTcRAraSAJwIg14QTYT33MtxfuOQxx3prcJ7nwCgqadG
 f+i/PYgCnQkpJszfgoclppc=
 =aAX9
 -END PGP SIGNATURE-





-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#486844: avr-libc: FHS violation

[Hakan Ardo]

OK, where to?

On Wed, Jun 18, 2008 at 4:49 PM, Bernd Zeimetz [EMAIL PROTECTED] wrote:
 Package: avr-libc
 Severity: serious


 According to the FHS, /usr/avr is not a valid directory, so your package
 is violating the Debian Policy 9.1.1.

 Please move the files somwhere else.

 Thanks,

 Bernd






-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#486219: avr-libc-user-manual.pdf lacking page numbers in the index

[Hakan Ardo]

Hi,
thanx for the repport, we probably have to run tex once more during
the build, I'll look into it...

On Sat, Jun 14, 2008 at 1:58 PM, Jonas Meyer [EMAIL PROTECTED] wrote:
 Package: avr-libc
 Version: 1:1.6.2-1
 Severity: minor

 in the Module Index all page numbers are only visible as ?? in evince. for
 example:

 alloca.h: Allocate space in the stack ??
 assert.h: Diagnostics ??

 I'd like to print the manual so being able to just click the links doesn't
 help.
 Thanks, Jonas

 -- System Information:
 Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
 Architecture: amd64 (x86_64)

 Kernel: Linux 2.6.25-1-amd64 (SMP w/2 CPU cores)
 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash

 -- no debconf information






-- 
Håkan Ardö



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#474674: easy fix

[Hakan Ardo]

Hi,
thanx I was waiting for some patches that should have been released by
now before doing a new release, but I guess it silly to wait any
longer so I'll make a new release tonight...

On Thu, Apr 24, 2008 at 9:55 AM, Marc =?UTF-8?Q?Poulhi=C3=A8s
[EMAIL PROTECTED] wrote:
 Simply change line:

  lib/libiberty.a share/info share/man/man7/gfdl.7* \

  by :

 lib/libiberty.a lib64/libiberty.a share/info share/man/man7/gfdl.7* \

  in the debian/rules file ;) Then it just works ;p

  Marc






-- 
Håkan Ardö

Bug#474674: easy fix

[Hakan Ardo]

Hi,
I'm using:

  http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00847.html

that patch will be included in 4.3.0-2 which I will release as soon as
I've confirmed it's working (==today).

On Thu, Apr 24, 2008 at 10:56 AM, Marc =?UTF-8?Q?Poulhi=C3=A8s
[EMAIL PROTECTED] wrote:
 Hakan Ardo [EMAIL PROTECTED] writes:

   Hi,
   thanx I was waiting for some patches that should have been released by
   now before doing a new release, but I guess it silly to wait any
   longer so I'll make a new release tonight...

  I'm currently developing on avr6 and I'm trying to port a patch against
  gcc 4.2.0 to gcc 4.3.0. What are the chances for this patch to be
  applied on debian packages ? I have no clue why this support is not
  already in mainstream gcc (even if I can see that there is some
  preliminary support, such has struct field for 3 bytes PC).






-- 
Håkan Ardö

Bug#474674: easy fix

[Hakan Ardo]

Hi again,
it seams like this was not enough. The winavr and freebsd maintainers
have apparently been working on a 4.3 release with avr6 support for
some time, but no release yet. I suppose we'll make another 4.3
release without avr6 in the meantime...

On Thu, Apr 24, 2008 at 11:13 AM, Hakan Ardo [EMAIL PROTECTED] wrote:
 Hi,
  I'm using:

   http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00847.html

  that patch will be included in 4.3.0-2 which I will release as soon as
  I've confirmed it's working (==today).

  On Thu, Apr 24, 2008 at 10:56 AM, Marc =?UTF-8?Q?Poulhi=C3=A8s

 [EMAIL PROTECTED] wrote:


  Hakan Ardo [EMAIL PROTECTED] writes:
  
 Hi,
 thanx I was waiting for some patches that should have been released by
 now before doing a new release, but I guess it silly to wait any
 longer so I'll make a new release tonight...
  
I'm currently developing on avr6 and I'm trying to port a patch against
gcc 4.2.0 to gcc 4.3.0. What are the chances for this patch to be
applied on debian packages ? I have no clue why this support is not
already in mainstream gcc (even if I can see that there is some
preliminary support, such has struct field for 3 bytes PC).
  
  
  



  --
  Håkan Ardö




-- 
Håkan Ardö

Bug#362270: [Bug gas/2626] Problems with LPM on attiny26

[Hakan Ardo]

Hi,
I only forwarded this bugrepport from the debian bts, the fix was done
(as far as I can tell) by joachim dot falk at gmx dot de, and you
should probably contribute it to him and not to me.

On 14 Feb 2008 13:04:51 -, nickc at redhat dot com
[EMAIL PROTECTED] wrote:

  --- Additional Comments From nickc at redhat dot com  2008-02-14 13:04 
 ---
  Hi Hakan,

   Thanks for submitting this fix.  I have applied it along with these 
 changelog
  entries.

  Cheers
   Nick

  include/opcode/ChangeLog
  2008-02-14  Hakan Ardo  [EMAIL PROTECTED]

 PR gas/2626
 * avr.h (AVR_ISA_2xxe): Define.

  gas/ChangeLog
  2008-02-14  Hakan Ardo  [EMAIL PROTECTED]

 PR gas/2626
 * config/tc-avr.c (mcu_types): Change the ISA tyoe of the attiny26
 to AVR_ISA_2xxe.
 (avr_operand): Disallow post-increment addressing in the lpm
 instruction for the attiny26.


  --
What|Removed |Added
  
  Status|WAITING |RESOLVED
  Resolution||FIXED




  http://sourceware.org/bugzilla/show_bug.cgi?id=2626

  --- You are receiving this mail because: ---
  You reported the bug, or are watching the reporter.




-- 
Håkan Ardö

Bug#457213: /usr/libexec is not FHS-compliant

[Hakan Ardo]

Hi,
I suppose those files should be moved to /usr/lib/gcc/avr/4.2.2/?

On Dec 20, 2007 6:45 PM, Ivan Shmakov [EMAIL PROTECTED] wrote:
 Package: gcc-avr
 Version: 4.2.2-1

 Though I cannot say for sure whether I like this particular
 respect of FHS or not, but still FHS (as of 2.3) doesn't define
 `libexec' as a valid `/usr' subdirectory.

 $ dpkg -c ftp.debian.org/debian/pool/main/g/gcc-avr/gcc-avr_4.2.2-1_i386.deb \
   | grep -F libexec
 drwxr-xr-x root/root 0 2007-12-15 23:03 ./usr/libexec/
 drwxr-xr-x root/root 0 2007-12-15 23:03 ./usr/libexec/gcc/
 drwxr-xr-x root/root 0 2007-12-15 23:03 ./usr/libexec/gcc/avr/
 drwxr-xr-x root/root 0 2007-12-15 23:03 ./usr/libexec/gcc/avr/4.2.2/
 -rwxr-xr-x root/root   3473364 2007-12-15 23:03 
 ./usr/libexec/gcc/avr/4.2.2/cc1
 -rwxr-xr-x root/root   3939092 2007-12-15 23:03 
 ./usr/libexec/gcc/avr/4.2.2/cc1plus
 -rwxr-xr-x root/root 90540 2007-12-15 23:03 
 ./usr/libexec/gcc/avr/4.2.2/collect2
 drwxr-xr-x root/root 0 2007-12-15 23:03 
 ./usr/libexec/gcc/avr/4.2.2/install-tools/
 -rwxr-xr-x root/root 10640 2007-12-15 23:03 
 ./usr/libexec/gcc/avr/4.2.2/install-tools/fixproto
 -rwxr-xr-x root/root175844 2007-12-15 23:03 
 ./usr/libexec/gcc/avr/4.2.2/install-tools/fix-header
 $







-- 
Håkan Ardö

Bug#421088: avr-libc: Please recompile to get the new devices working...

[Hakan Ardo]

Hi,
yes, I will release version 1.4.6 any day now. I have to update the
newdevices patch of binutils first though, because currently it has
the wrong architecture for at90usb82, preventing avr-libc from
compiling.

Sorry for the long delay...

On 8/13/07, Lars Noschinski [EMAIL PROTECTED] wrote:
 severity 421088 minor
 thanks

 Now that avr-gcc is updated, would it be possible to recompile avr-libc
 for support of the new devices?




-- 
Håkan Ardö