Re: Policy 3.9.0.0 released
Russ Allbery wrote: > Debian Policy 3.9.0.0 has been released. The next time you upload your > packages, please review them against the upgrading checklist in the > debian-policy package and see if they require changes for the new version > of Policy. > [...] > 5.6.8, 7.1, 11.1.1 > Architecture wildcards may be used in addition to specific > architectures in `debian/control' and `*.dsc' Architecture > fields, and in architecture restrictions in build relationships. Why is this allowed and still all packages are send to all architectures? This creates a lot of false "failed ... build of ..." mails. In the log of these builds on those architectures only appears something like: not in arch list or does not match any arch wildcards: linux-any all -- Emil Langrock -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201006290055.06113.emil.langr...@gmx.de
Automatic debug packages
Hi, I browsed a little bit in the goals which were planned for squeeze and noticed that the debug packages aka ddebs[1] weren't implemented in the debian infrastructure. I thought that many things happened [2] and there were also some wrappers implemented [3] to automatically generate those packages. Even a project as part of google summer of code 2009 was finished and its result were published [4]. But it seems that none of it is really accepted. What is the direction we should follow for Wheezy[5]? Should we remove our special -dbg packages or at least stop to create new -dbg packages? Kind regards, Emil [1] http://wiki.debian.org/AutomaticDebugPackages [2] http://debug.debian.net/ [3] https://launchpad.net/ubuntu/+source/pkg-create-dbgsym [4] http://code.google.com/p/google-summer-of-code-2009- debian/downloads/detail?name=Emilio_PozueloMonfort.tar.bz2&can=2&q= [5] http://release.debian.org/wheezy/goals.txt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201103080048.28079.emil.langr...@gmx.de
Link-time optimization in debian packages
Hi, I have currently the problem that I have to use large, computing intensive applications [1,2]. These are usually implemented in many source files. I used in the past pseudo c files which include all other c files [3]. Of course, this is a hack and don't work in many situation due to conflicting local symbols. I played around a little bit with GCC's LTO [4]. It is really impressive for this kind of applications. I had a size reduction and speed increase with the tested applications. Of course, it was just a small testset and not really scientific. Link time-optimization exchanges the meaning of flags slightly [5]. It is currently necessary to provide the optimization related flags from CFLAGS/CXXFLAGS also in LDFLAGS. Otherwise the LTO will not really to a optimization step. I already found some smaller problems related to weird asm usage in some pic library code [6], but I would doubt that this is a big show blocker and will be fixed soon(tm). My question is now whether there are already plans to use LTO in Debian packages, any big debian related studies, policies, release goals, ...? It could also be interesting for large projects like Iceweasel, LibreOffice, ... Maybe the KDE Debian Package maintainer have a reason why they don't use KDE4_ENABLE_FINAL --- which would also be an argument against LTO. [1] http://packages.qa.debian.org/p/povray.html [2] http://packages.qa.debian.org/m/mednafen.html [3] see KDE4_ENABLE_FINAL in all KDE libraries/applications [4] http://gcc.gnu.org/wiki/LinkTimeOptimization [5] http://gcc.gnu.org/wiki/lto/OptionHandling [6] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49286 -- Emil Langrock -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201106051318.43581.emil.langr...@gmx.de
