Re: Upcoming changes to supported architectures
On Thu, Aug 14, 2008 at 05:56:33PM -0700, Steve Langasek wrote: > If we aren't really running > into resource constraints linked to the architecture count, it's a poor use > of people's time to have to redeploy all of the ftp-master infrastructure on > a separate host. True. I would rather like to see the m68k porters to spend their time on real porting issues than on establishing the infrastructure that is needed because of the immanent drop. > > If you disagree - please provide sane alternative suggestions. > In the absence of an explanation why this change is needed, I suggest "don't > change what's not broken" as a sane alternative. I believe that changing the release scheme to not release the whole archive in one release but do some sort of subreleases (base, X, database, ...) is not going to be considered as "sane alternative"... ;) -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij_public_key.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming changes to supported architectures
pe, 2008-08-15 kello 09:59 +0200, Ingo Juergensmann kirjoitti: > True. I would rather like to see the m68k porters to spend their time on > real porting issues than on establishing the infrastructure that is needed > because of the immanent drop. It seems to me that _if_ the proposed change happens, it would make most sense to set up a single ports machine to handle the infrastructure for all the ports, rather than once for each port. I don't have an opinion on whether the proposed change is sane (to use Joerg's word), or well argued, but if it happens, conserving the effort caused by it seems sensible. Although: does it strike anyone else that this is becoming fairly close to an outright fork of Debian? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming changes to supported architectures
On Fri, Aug 15, 2008 at 05:51:00AM +0200, Joerg Jaspert wrote: > > Is this a unanimous decision of the ftp team? You say that discussions were > > had at DebConf 8, but not all of the ftp team (or even all of the ftp > > masters) are present there... > I know that not all of us have been here. Where is the point? > JFTR, this was passed via an m68k porter, release people, other ftp > people, dpl and a dsa... Well, "passed via an m68k porter" doesn't mean that m68k as a port is happy about being dropped out of Debian. It's more like dealing with something sanely that's inevitable since Vancouver. > >> If you disagree - please provide sane alternative suggestions. > > In the absence of an explanation why this change is needed, I suggest "don't > > change what's not broken" as a sane alternative. > The fact that we currently have *no* guidelines at all is broken, so we fix > it. It would be nice, though, to have a written guideline now as well how to get back in. I got the impression that there's currently just an idea how to drop those archs in questions, but not how to help or make it easier for them to get back in again. > Now, we get complaints if decisions are made on a case by case basis. We > get complaints if we provide guidelines that are easy and clear. What do > people want? People always complain about those who have the power. It's just natural. ;) Anyway, I hope that ftp-masters will support the m68k port in either direction that will be made by the m68k porter meeting in Kiel in two weeks... -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij_public_key.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495192: ITP: libclass-adapter-perl -- Perl implementation of the "Adapter" Design Pattern
Package: wnpp Severity: wishlist Owner: Vincent Danjean <[EMAIL PROTECTED]> * Package name: libclass-adapter-perl Version : 1.04 Upstream Author : Adam Kennedy <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/Class-Adapter/ * License : Perl (GPL+Artistic) Programming Lang: Perl Description : Perl implementation of the "Adapter" Design Pattern The Class::Adapter class is intended as an abstract base class for creating any sort of class or object that follows the Adapter pattern. . The term Adapter refers to a "Design Pattern" of the same name, from the famous "Gang of Four" book "Design Patterns". Although their original implementation was designed for Java and similar single-inheritance strictly-typed langauge, the situation for which it applies is still valid. . An Adapter in this Perl sense of the term is when a class is created to achieve by composition (objects containing other object) something that can't be achieved by inheritance (sub-classing). . This is similar to the Decorator pattern, but is intended to be applied on a class-by-class basis, as opposed to being able to be applied one object at a time, as is the case with the Decorator pattern. PS: this perl module is a dependency of Koha. I do not know it at all. I wrote the description from the documentation but I would accept any proposed improvment. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming changes to supported architectures
On Fri, Aug 15, 2008 at 11:07:08AM +0300, Lars Wirzenius wrote: > pe, 2008-08-15 kello 09:59 +0200, Ingo Juergensmann kirjoitti: > > True. I would rather like to see the m68k porters to spend their time on > > real porting issues than on establishing the infrastructure that is needed > > because of the immanent drop. > It seems to me that _if_ the proposed change happens, it would make most > sense to set up a single ports machine to handle the infrastructure for > all the ports, rather than once for each port. I don't have an opinion > on whether the proposed change is sane (to use Joerg's word), or well > argued, but if it happens, conserving the effort caused by it seems > sensible. Well, I've no doubt that the drop will happen. There's already to much happening to make that plan to drop archs becoming reality. But yes, it would make sense to have a single ports machine or a single infrastructure to handle those dropped ports. So far the argueing was mostly because of space constraints (sometimes traffic as well). I think the archive split has helped with the space issues on the primary mirros. IMHO, the time would have been better spent to think over the release scheme of releasing >>7000 packages for all archs and save space that way instead of plans to drop archs. But: YMMV. For me it makes not that much sense to build and upload such packages as atlas3 and others for m68k. But changing this would mean a change in the "build all packages for all archs" mantra. > Although: does it strike anyone else that this is becoming fairly close > to an outright fork of Debian? Surprised? I would be happy when this wasn't forced on us, though... And it means that I'll need to abandon my backports.org mirror in favour of the m68k mirror (space constraints ;-)... -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij_public_key.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming changes to supported architectures
Why do I see a deja-vue? I think we had this already some years ago.
On Thu, Aug 14, 2008 at 10:25:38PM -0700, Steve Langasek wrote:
> So the current architectures I see wishlist bugs for on ftp.d.o are s390x,
> sh[34]{,eb}, netbsd-i386, and kfreebsd-{i386,amd64}.
The sh* ports are not dead? I've not seen anything from them for years.
Also from the kernel point of view, there are sh2, 3, 4 and 5, the
first three as both little and big endian. And when it goes for the
compiler it only gets worse, it lists 23 multilib variants.
> Doesn't s390x have the same problem as sparc64, where it's not actually
> beneficial to build the whole system for this target?
There is some. IBM likes to add new op-codes to every processor release
and with a higher minimum supported type they can be used. They often
provide a speed benefit. Also the instruction format is identical
between the 31 and 64bit code. I would like to use multiarch, but this
is still not ready.
Bastian
--
History tends to exaggerate.
-- Col. Green, "The Savage Curtain", stardate 5906.4
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming changes to supported architectures
On Fri, Aug 15, 2008 at 05:25:38AM +, Steve Langasek wrote:
> So the current architectures I see wishlist bugs for on ftp.d.o are s390x,
> sh[34]{,eb}, netbsd-i386, and kfreebsd-{i386,amd64}.
>
> Which of these are currently in a more releasable state than hurd-i386?
kfreebsd has a fully working toolchain, and has a very good linux
emulation layer which (modulo a relibtoolization for the harder cases)
theorically allow an excellent archive coverage. Additionnally, having
kfreebsd brings ZFS to Debian FWIW.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpvC9IakYNf0.pgp
Description: PGP signature
Bug#495198: ITP: libtest-minimumversion-perl -- perl module to test if code requires newer perl than expected
Package: wnpp Severity: wishlist Owner: Vincent Danjean <[EMAIL PROTECTED]> * Package name: libtest-minimumversion-perl Version : 0.008 Upstream Author : Ricardo SIGNES <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/Test-MinimumVersion/ * License : Perl (GPL + Artistic) Programming Lang: Perl Description : perl module to test if code requires newer perl than expected Test::MinimumVersion is a test module to make it easier to notice that you've accidentally made your dist require a newer version of perl than you meant to. Best regards, Vincent PS: suggestion of improved descriptions are welcome -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495197: ITP: libfile-find-rule-perl-perl -- common rules for searching for Perl things
Package: wnpp Severity: wishlist Owner: Vincent Danjean <[EMAIL PROTECTED]> * Package name: libfile-find-rule-perl-perl Version : 1.04 Upstream Author : Adam Kennedy <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/File-Find-Rule-Perl/ * License : Perl (GPL + Artistic) Programming Lang: Perl Description : common rules for searching for Perl things File::Find::Rule::Perl provides methods for finding various Perl-related files. It specializes the generic module File::Find::Rule. Best regards, Vincent PS: description improvments are welcome -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495196: ITP: libperl-minimumversion-perl -- find a minimum required version of perl for Perl code
Package: wnpp Severity: wishlist Owner: Vincent Danjean <[EMAIL PROTECTED]> * Package name: libperl-minimumversion-perl Version : 0.15 Upstream Author : Adam Kennedy <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/Perl-MinimumVersion/ * License : Perl (GPL + Artistic) Programming Lang: Perl Description : find a minimum required version of perl for Perl code Perl::MinimumVersion takes Perl source code and calculates the minimum version of perl required to be able to run it. Because it is based on PPI, it can do this without having to actually load the code. . Currently it tests both the syntax of your code, and the use of explicit version dependencies such as "require 5.005". . Future plans are to also add support for tracing module dependencies. Best regards, Vincent PS: description improvments are welcome -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming changes to supported architectures
Le Fri, Aug 15, 2008 at 09:59:01AM +0200, Ingo Juergensmann a écrit : > > I believe that changing the release scheme to not release the whole archive > in one release but do some sort of subreleases (base, X, database, ...) is > not going to be considered as "sane alternative"... ;) Hi Ingo That is sad, I would love it to happen… The management of the userless packages on specialised arches is a time sink that in addition poisons the relationships between package maintainers and porters (or at least between me and the porters). I really think that we should be more user-driven for these issuses: If users want some categories of packages, let's work hard to provide to them. If nobody shows up... let's concentrate on other issues. Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming changes to supported architectures
On Fri, Aug 15, 2008 at 06:45:30PM +0900, Charles Plessy wrote: > Le Fri, Aug 15, 2008 at 09:59:01AM +0200, Ingo Juergensmann a écrit : > > I believe that changing the release scheme to not release the whole archive > > in one release but do some sort of subreleases (base, X, database, ...) is > > not going to be considered as "sane alternative"... ;) > That is sad, I would love it to happen... The management of the userless > packages on specialised arches is a time sink that in addition > poisons the relationships between package maintainers and porters > (or at least between me and the porters). I really think that we should > be more user-driven for these issuses: If users want some categories of > packages, let's work hard to provide to them. If nobody shows up... > let's concentrate on other issues. Well, currentlz the porters can add packages to N-F-U, which originally is intended to store information that is not suitable for some archs, e.g. because of missing hardware or something similar. "Abusing" N-F-U for exclusion of "unwanted" packages is a workaround maybe, but not a good one. Currently Debian lacks the ability to release a subset of packages for some archs. For example I think XFCE4 would be sufficient to most users on m68k when they want to use X11 on their machines. That means that non-depending packages for Gnome, Wmaker, KDE could be build on a best-effort basis and stored somewhere else on separate/willing mirrors. If that would be possible a lot of porting work could be saved (as in building those packages on these slower archs and dealing with bugs) that could be spent in porting more important issues (like glibc, binutils,...). This would, of course, break with the current "build all packages on all archs and let the users decide" policy in some way, but it gives a better flexibility and aims at subrelease scheme, where the archive is split up into subsections (as they are present yet) and being able to release those in separate release (base, important, X11, Desktop, KDE, Gnome, databases, ...). This would benefit the users because the base system could be released every 2 years for example whereas the desktop related sections could be released more often. Yes, of course this means a lot of work to do and I dont know if this is doable with the current ftp-master infrastructure, but I think it`s solvable/doable and Debian would benefit in the long run as well. The archive will be ever growing and dropping archs when space gets limited is not a good solution to this problem, IMHO... -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij_public_key.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495206: ITP: libtest-script-perl -- cross-platform basic tests for scripts
Package: wnpp Severity: wishlist Owner: Vincent Danjean <[EMAIL PROTECTED]> * Package name: libtest-script-perl Version : 1.03 Upstream Author : Adam Kennedy * URL : http://search.cpan.org/dist/Test-Script/ * License : Perl (GPL + Artistic) Programming Lang: Perl Description : cross-platform basic tests for scripts The intent of this module is to provide a series of basic tests for scripts in the bin directory of your Perl distribution. . Further, it aims to provide them with perfect platform-compatibility and in a way that is as unobtrusive as possible. . That is, if the program works on a platform, then Test::Script should also work on that platform. Best regards, Vincent -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495205: ITP: libparse-cpan-meta-perl -- module to parse META.yml and other similar CPAN metadata files
Package: wnpp Severity: wishlist Owner: Vincent Danjean <[EMAIL PROTECTED]> * Package name: libparse-cpan-meta-perl Version : 0.03 Upstream Author : Adam Kennedy * URL : http://search.cpan.org/dist/Parse-CPAN-Meta/ * License : Perl (GPL + Artistic) Programming Lang: Perl Description : module to parse META.yml and other similar CPAN metadata files Parse::CPAN::Meta is a parser for META.yml files, based on the parser half of YAML::Tiny. . It supports a basic subset of the full YAML specification, enough to implement parsing of typical META.yml files, and other similarly simple YAML files. . If you need something with more power, move up to a full YAML parser such as YAML, YAML::Syck or YAML::LibYAML. . Parse::CPAN::Meta provides a very simply API of only two functions, based on the YAML functions of the same name. Wherever possible, identical calling semantics are used. Best regards, Vincent -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495207: ITP: libtest-cpan-meta-perl -- test module to validate a CPAN META.yml file
Package: wnpp Severity: wishlist Owner: Vincent Danjean <[EMAIL PROTECTED]> * Package name: libtest-cpan-meta-perl Version : 0.12 Upstream Author : Barbie <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/Test-CPAN-Meta/ * License : Perl (GPL + Artistic) Programming Lang: Perl Description : test module to validate a CPAN META.yml file The Test::CPAN::Meta module was written to ensure that a META.yml file, provided with a standard distribution uploaded to CPAN, meets the specifications that are slowly being introduced to module uploads, via the use of package makers and installers such as ExtUtils::MakeMaker, Module::Build and Module::Install. Best regards, Vincent -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tools/ and dftp on mirrors
Am 2008-08-07 09:42:31, schrieb Daniel Moerner: > Hello, > > Although it is doubtful that anyone actually uses all of those zip > files in order to install debian, I think it is very likely that other > linux sites point to the debian/tools directory to inform people where > to download rawrite and md5sum, two relatively common utilities needed > if you have a linux system at hand. I don't think this is a reason to > stop their removal, however. A quick google search reveals that while > Apple points to the Debian mirrors, > (http://docs.info.apple.com/article.html?artnum=71921) the document > was created in 1999. It's probably safe to remove them. Hmmm, this mean, "loadlin.exe" would be removed too? Since I do some embedded stuff using DJGPP I used loadlin.exe to boot a linux basic installation from withing MS/DR-DOS or TDDOS. Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: tools/ and dftp on mirrors
Michelle Konzack, le Mon 11 Aug 2008 20:09:23 +0200, a écrit : > Hmmm, this mean, "loadlin.exe" would be removed too? loadlin is used for the win9x support too. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495213: ITP: js2-mode -- Emacs mode for editing Javascript programs
Package: wnpp
Severity: wishlist
Owner: Vincent Bernat <[EMAIL PROTECTED]>
* Package name: js2-mode
Version : 20080616a
Upstream Author : Steve Yegge <[EMAIL PROTECTED]>
* URL : http://code.google.com/p/js2-mode/
* License : GPLv2+
Programming Lang: Emacs LISP
Description : Emacs mode for editing Javascript programs
This JavaScript editing mode supports:
- the full JavaScript language through version 1.7
- support for most Rhino and SpiderMonkey extensions from 1.5 to 1.7
- accurate syntax highlighting using a recursive-descent parser
- syntax-error and strict-mode warning reporting
- "bouncing" line indentation to choose among alternate indentation points
- smart line-wrapping within comments (Emacs 22+) and strings
- code folding:
- show some or all function bodies as {...}
- show some or all block comments as /*...*/
- context-sensitive menu bar and popup menus
- code browsing using the imenu' package
- typing helpers (e.g. inserting matching braces/parens)
- many customization options
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming changes to supported architectures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a local mirror of m68k, and both kfreebsd ports, and they're roughly 70-80GB including source. If ries has become so full that space is becoming an issue, then dropping arm, hurd-i386, and m68k is a stopgap move at best (your only going to recover maybe 50GB, 10 for hurd (it only has half the archive built), and 20 each for arm and m68k). As for CPU usage and RAM, I'm not really seeing it; dak itself only is "executed" during dinstall, where automatic processing of all dak queues are run. GPG signatures are checked during import, which should not be much of a burden. The only thing that should be CPU intensive is apt-ftparchive generate, and only when importing a new archive or rebuilding the packages files after trashing the cache files (on modest hardware, it takes apt-ftparchive to do a full rebuild of an architecture roughly 40 minutes, but unless there is an issue with the caching, I don't see what the burden on resources is. As for chopping up the archive into subsections, dak itself can handle managing multiple archives pretty well (I'm not sure how great it is about moving stuff from section to section, but that can be fixed with a simple python script). It makes sense for me that each section that already exists could be divided, so instead of say, just unstable, have unstable-net, unstable-devel, unstable-base, etc. This has the wonderful added bonus that having a new architecture could have their own testing for sections they have fully built. For some of the larger package groups (KDE, GNOME, XFCE), those can each be their own section. Each architecture's porters can choose what sections to include. I'd say go one step farther and have a release manager appointed from each section to handle that release; which has the added bonus of also revealing the workload on the current RMs. Priority should determine if something MUST be present to do any release. Pretty much make it so anything that is Priority required or higher must be built, and the rest is up to the architecture porters. As for architectures wanting to get into debian, shX is currently looking at least four ports just to handle the subarchs (that's a discussion for another time), netbsd-* is dead (has been since '02),. kfreebsd-* is pretty close to releasable; they've got the archive built in the high 80s, and are keeping up). It seems to me the current policy of the ftp-masters is to only accept a port once its fully built and releasable; armel is the only relatively new port, and that was completely staged on d-ports, and didn't join sid on the archive until it was reasonable. When did it that become debian policy? Running a dak server is not the easiest task in the world (d-ports uses mini-dak), and configuring and managing a local wanna-build isn't that easy, especially considering there is virtually no documentation, and a lot of of it is trial and error. All other ports were built within sid itself, hell, m68k was the first port of debian, which created the buildd and wanna-build infrastructure alll other ports use! An added note on this subject is the constant trouble of adding SSH keys to buildd.d.o. and general wanna-build administration. hurd-i386 currently hosts their w-b on debian-ports, and m68k has had constant issues getting keys added to the point of sheer lucidity. How hard is it to copy and paste a few lines into buildd-m68k authorized keys? It just seems that any more with less then 100 users seems to be well a second class citizen. A part of me wonders when other ports with limited userbases are going to start getting dropped; for me, one of the biggest strengths of Debian was the fact that it runs on pretty much everything (only Gentoo can match in platforms supported at last count). As for dropping architectures, this was proposed as part of the vancouver proposal, but I don't understand why we're following this if the rest of the proposal was NEVER implemented. According to the proposal, the four most popular architectures (i386, amd64, ia64, and powerpc) would remain on ftp-master, and the rest would become second-class citizens, and be moved to scc.debian.org. That same server would also run a full blown dak and handle accepting new architecutres. As far as I can tell, that never happened, and debian simply changed that architectures must be fully bootstrapped and built before they will be accepted vs. just requiring three DDs to advocate the port. I also read that doorstop.debian.org would be created for hosting newer architecture, which would run dak and such; again, never implemented. Right now,all we have debian-ports, which isn't even an official Debian service for hosting new architectures, and is currently maxed out. If the problem with adding new architectures is that reis is maxed out, the solution is not dropping old architectures, its upgrading the server since just removing older ones is a stopgap solutions at best. I've been told ther
Bug#495218: ITP: libsms-send-perl -- Driver-based API for sending SMS messages
Package: wnpp Severity: wishlist Owner: Vincent Danjean <[EMAIL PROTECTED]> * Package name: libsms-send-perl Version : 0.05 Upstream Author : Adam Kennedy <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/SMS-Send/ * License : Perl (GPL + Artistic) Programming Lang: Perl Description : Driver-based API for sending SMS messages The SMS::Send perl module is intended to provide a driver-based single API for sending SMS and MMS messages. The intent is to provide a single API against which to write the code to send an SMS message. . At the same time, the intent is to remove the limits of some of the previous attempts at this sort of API, like "must be free internet-based SMS services". . SMS::Send drivers are installed separately, and might use the web, email or physical SMS hardware. It could be a free or paid. The details shouldn't matter. . You should not have to care how it is actually sent, only that it has been sent (although some drivers may not be able to provide certainty). Best regards, Vincent PS: as always, suggestion to improve description is welcome -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming changes to supported architectures
On Fri, Aug 15, 2008, Bastian Blank wrote: > There is some. IBM likes to add new op-codes to every processor release > and with a higher minimum supported type they can be used. They often > provide a speed benefit. Also the instruction format is identical > between the 31 and 64bit code. I would like to use multiarch, but this > is still not ready. Can't you simply raise the port's requirement, just like we dropped support for i386 in i386? I think it would be a sensible thing to do if a large protion of the port's user have newer hardware than the oldest that the port supports, but I have no idea whether this is the case. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#495196: ITP: libperl-minimumversion-perl -- find a minimum required version of perl for Perl code
Hello, On Fri, Aug 15, 2008 at 11:29:15AM +0200, Vincent Danjean wrote: > Description : find a minimum required version of perl for Perl code > > Perl::MinimumVersion takes Perl source code and calculates the minimum > version of perl required to be able to run it. Because it is based on > PPI, it can do this without having to actually load the code. > . > Currently it tests both the syntax of your code, and the use of explicit > version dependencies such as "require 5.005". > . > Future plans are to also add support for tracing module dependencies. You should avoid the comments (last 2 paragraphs) on the status of the package, in particular the "future plans". -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Some autobuilders wait for build-indep dependencies
On Mon, Aug 11, 2008 at 11:29:53AM +0200, Francisco Moya wrote: > Hi, > > I've uploaded a new version of zeroc-ice packages which essentially > falls back to target build-arch whenever the autobuilder tries the build > target on architectures other than i386. I hope the Build-Options > control field or a similar approach will enter the Debian policy soon so > that I can remove the kludge. DO NOT DO THAT. Building a package does not only happen on your own system or on buildd hosts; it also happens on end-user hosts, or on the machines of fellow developers. I don't *want* to have to deal with an NMU where I first have to rewire the entire debian/rules file before I can build a decent package on my powerpc-based laptop, thank you. It's unfortunate that build-arch currently isn't really implemented, but that's what currently the state is, so you'll have to go with it. Make sure everything you need for both "clean", "build", and "binary-arch" is installed for your build, and upload that. Please. For reference, sbuild (the building part of buildd) currently uses "dpkg-buildpackage -B" as the job that does the actual building. You're welcome to patch dpkg so that that will call build-arch, but until then... -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian on the FreeRunner -- now official
Dear OpenMoko community, the FSO packaging team of the Debian project[1] is happy to announce that we have started to provide installation procedures and packages required to have your FreeRunner[2] run Debian-powered. This means that you can use your favorite tools such as apt-get and the other >20.000 packages on your FreeRunner, including the freesmartphone.org[3] software stack. You can also develop applications for your FreeRunner the “Debian way”. To install Debian onto your MicroSD card, alongside your current Image on the internal Flash, see the instructions at http://wiki.debian.org/DebianOnFreeRunner These will provide you with a minimal Debian installation plus everything required to use zhone. From there on, you are free to modify your system as you wish – with the full power and flexibility of the Debian system. Note that Debian does not try provide yet another software stack (or “Distribution” in the OpenMoko slang) next to 2007.2, 2008.8 or FSO, but rather an alternative base, comparable to OpenEmbedded[3]. We are looking forward to also support other stacks such as the Stable Hybrid Release[4], once they are ready for that. All this is still very new and was created during at the DebConf 8 in Mar de Plata since last week. This means that there are still bugs and other things to improve. You are invited to join the development by subscribing to the smartphone-standards[5] mailing list that the Debian team shares with the FSO team. There is also a wiki page[6] with more information on the pkg-fso team, including a TODO section. I’d like to thank Jon “maddog” Hall from Koolu[7] for lending me an additional device for installation tests, and all the other testers at DebConf and elsewhere that helped us to remove at least some of the bugs. But don’t worry – I’m sure there are some bugs left for you! Please send replies and further discussion to the smartphone-standards[5] mailing list, but note that you have to subscribe to that list first. Enjoy! Joachim Breitner on behalf of the pkg-fso team: Philipp Kern Jan Lübbe Luca Capello [1] http://www.debian.org [2] http://wiki.openmoko.org/wiki/Neo_FreeRunner [3] http://wiki.openembedded.net/ [4] http://wiki.openmoko.org/wiki/Stable_Hybrid_Release [5] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards [6] http://wiki.debian.org/pkg-fso [7] http://www.koolu.com/ -- Joachim "nomeata" Breitner Debian Developer [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Debian on the FreeRunner -- now official
On Fri, Aug 15, 2008 at 1:04 PM, Joachim Breitner <[EMAIL PROTECTED]> wrote: > the FSO packaging team of the Debian project[1] is happy to announce > that we have started to provide installation procedures and packages > required to have your FreeRunner[2] run Debian-powered. Will you be moving the pkg-fso packages to Debian experimental or sid at some point? > To install Debian onto your MicroSD card, alongside your current Image > on the internal Flash, see the instructions at >http://wiki.debian.org/DebianOnFreeRunner This wiki page should probably moved into the InstallingDebianOn namespace: http://wiki.debian.org/InstallingDebianOn -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming changes to supported architectures
On 11478 March 1977, Ingo Juergensmann wrote: >> > In the absence of an explanation why this change is needed, I suggest >> > "don't >> > change what's not broken" as a sane alternative. >> The fact that we currently have *no* guidelines at all is broken, so we fix >> it. > It would be nice, though, to have a written guideline now as well how to get > back in. I got the impression that there's currently just an idea how to > drop those archs in questions, but not how to help or make it easier for > them to get back in again. it is included in my post. - If a removed architecture later can prove it will be able to make the next official release, it can be re-included into the official archive. This step additionally needs the acceptance of the Security, the Release and the Debian Admin Team. (It needs security autobuilders, porter machines, etc.) > Anyway, I hope that ftp-masters will support the m68k port in either > direction that will be made by the m68k porter meeting in Kiel in two > weeks... The same as we offer every other architecture going out or trying to come in. -- bye, Joerg I'm a blabbermouth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Some autobuilders wait for build-indep dependencies
I already know that people do also build their own packages, thanks. You do not need to "rewire" the debian/rules in order to build zeroc-ice binary-arch packages but AFAIK in your PowerPC you cannot currently build zeroc-ice binary-all packages, no matter what I do. You do not need to issue an NMU if you find some binary-all packages that could be built in architectures other than i386. Report the bug and I will add them in the next release. The kludge will add another exception. Note that this is not a guarantee to be able to build binary-all but perhaps you could build binary/libzeroc-ice-java (?) The zeroc-ice build dependencies are right to the best of my knowledge, but dpkg-buildpackage -B do not currently check them all. Target build must satisfy Build-Depends-Indep (cf. Debian Policy 7.7) but dpkg-buildpackage fail to enforce that for binary-arch builds. This is a feature rather than a bug in my opinion. This makes it possible to use target build while the transition path to build-arch is defined. Simply stated, zeroc-ice is a package with lots of dependencies. I'll do my best to get most of it working in as much architectures as possible. But I won't remove features in some architectures just to homogeneize the behaviour of debian/rules. Therefore I'm eager to receive suggestions on how to make it *better* supported on any architecture. But I won't accept "DO NOT DO THAT" statements unless properly supported on the Debian Policy. Regards, F. Moya -Original Message- From: Wouter Verhelst [mailto:[EMAIL PROTECTED] Sent: Fri 15/08/2008 16:53 To: FRANCISCO MOYA FERNANDEZ Cc: debian-devel@lists.debian.org Subject: Re: Some autobuilders wait for build-indep dependencies On Mon, Aug 11, 2008 at 11:29:53AM +0200, Francisco Moya wrote: > Hi, > > I've uploaded a new version of zeroc-ice packages which essentially > falls back to target build-arch whenever the autobuilder tries the build > target on architectures other than i386. I hope the Build-Options > control field or a similar approach will enter the Debian policy soon so > that I can remove the kludge. DO NOT DO THAT. Building a package does not only happen on your own system or on buildd hosts; it also happens on end-user hosts, or on the machines of fellow developers. I don't *want* to have to deal with an NMU where I first have to rewire the entire debian/rules file before I can build a decent package on my powerpc-based laptop, thank you. It's unfortunate that build-arch currently isn't really implemented, but that's what currently the state is, so you'll have to go with it. Make sure everything you need for both "clean", "build", and "binary-arch" is installed for your build, and upload that. Please. For reference, sbuild (the building part of buildd) currently uses "dpkg-buildpackage -B" as the job that does the actual building. You're welcome to patch dpkg so that that will call build-arch, but until then... -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22
Bug#495278: ITP: libacts-as-list-ruby -- Provides the capabilities for sorting and reordering elements on ActiveRecord-based lists
Package: wnpp Severity: wishlist Owner: Gunnar Wolf <[EMAIL PROTECTED]> * Package name: libacts-as-list-ruby Version : 2007.10.12 Upstream Author : David Heinemeier Hansson <[EMAIL PROTECTED]> * URL : http://github.com/rails/acts_as_list * License : MIT Programming Lang: Ruby Description : Provides sorting and reordering on ActiveRecord-based listings This plugin allows any list of elements from a table based on ActiveRecord to be treated as an ordered list, with primitives for sorting and reordering. . This plugin was written aimed at Rails applications (and is a base Rails plugin), but can be used in any application based upon the ActiveRecord library. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495281: ITP: libaudio-wma-perl -- a perl extension for reading WMA/ASF Metadata
Package: wnpp Severity: wishlist Owner: Cristian Greco <[EMAIL PROTECTED]> * Package name: libaudio-wma-perl Version : 1.1 Upstream Author : Dan Sully <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/Audio-WMA/ * License : Perl (GPL + Artistic) Programming Lang: Perl Description : a perl extension for reading WMA/ASF Metadata This perl module implements several methods which provide access to metadata/tag informations contained in WMA files. Best Regards, Cristian -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) signature.asc Description: Digital signature
Bug#495284: ITP: apf -- easy iptables based firewall system
Package: wnpp Severity: wishlist Owner: Giuseppe Iuculano <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: apf Version : 9.6-4 Upstream Author : R-fx Networks <[EMAIL PROTECTED]> * URL : http://www.r-fx.org/apf.php * License : GPL Programming Lang: bash Description : easy iptables based firewall system Advanced Policy Firewall (APF) is an iptables(netfilter) based firewall system designed around the essential needs of today's Internet deployed servers and the unique needs of custom deployed Linux installations. The configuration of APF is designed to be very informative and present the user with an easy to follow process, from top to bottom of the configuration file. The management of APF on a day-to-day basis is conducted from the command line with the 'apf' command, which includes detailed usage information and all the features one would expect from a current and forward thinking firewall solution. Summary of features: - - detailed and well commented configuration file - - granular inbound and outbound network filtering - - user id based outbound network filtering - - application based network filtering - - trust based rule files with an optional advanced syntax - - global trust system where rules can be downloaded from a central management server - - reactive address blocking (RAB), next generation in-line intrusion prevention - - debug mode provided for testing new features and configuration setups - - fast load feature that allows for 1000+ rules to load in under 1 second - - inbound and outbound network interfaces can be independently configured - - global tcp/udp port & icmp type filtering with multiple methods of executing filters (drop, reject, prohibit) - - configurable policies for each ip on the system with convenience variables to import settings - - packet flow rate limiting that prevents abuse on the most widely abused protocol, icmp - - prerouting and postrouting rules for optimal network performance - - dshield.org block list support to ban networks exhibiting suspicious activity - - spamhaus Don't Route Or Peer List support to ban known "hijacked zombie" IP blocks - - any number of additional interfaces may be configured as firewalled (untrusted) or trusted (not firewalled) - - additional firewalled interfaces can have there own unique firewall policies applied - - intelligent route verification to prevent embarrassing configuration errors - - advanced packet sanity checks to make sure traffic coming and going meets the strictest of standards - - filter attacks such as fragmented UDP, port zero floods, stuffed routing, arp poisoning and more - - configurable type of service options to dictate the priority of different types of network traffic - - intelligent default settings to meet every day server setups - - dynamic configuration of your servers local DNS revolvers into the firewall - - optional filtering of common p2p applications - - optional filtering of private & reserved IP address space - - optional implicit blocks of the ident service - - configurable connection tracking settings to scale the firewall to the size of your network - - configurable kernel hooks (ties) to harden the system further to syn-flood attacks & routing abuses - - advanced network control such as explicit congestion notification and overflow control - - special chains that are aware of the state of FTP DATA and SSH connections to prevent client side issues - - control over the rate of logged events, want only 30 filter events a minute? 300 a minute? - you are the boss - - logging subsystem that allows for logging data to user space programs or standard syslog files - - logging that details every rule added and a comprehensive set of error checks to prevent config errors - - if you are familiar with netfilter you can create your own rules in any of the policy files - - pluggable and ready advanced use of QoS algorithms provided by the Linux - - 3rd party add-on projects that compliment APF features -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkil9/IACgkQNxpp46476aq+UACeMLOoO5PeUxXm/Uzmp39pVXmf emoAoJwcX9p/CpCqgHWlibGIbGCbxX6I =90zt -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495294: i18n.debian.org: [DDTP] Remove wrong language code 'go'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: general Severity: normal User: [EMAIL PROTECTED] Usertags: i18n.debian.org Usertags: ddtp Hi, While generating Translation-* files for the package descriptions, we detected a wrong language code: "go". It is probably a typo for "ko". It has only one translation (base-files) and should be removed from the DDTP database. Kind regards, PS: This bug should be moved to the i18n.debian.org pseudo-package. - -- Felipe Augusto van de Wiel (faw) "Debian. Freedom to code. Code to freedom!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkimCJAACgkQCjAO0JDlykbrmACfQnv9iVYHZRPKErDTtGdncrCr qt4AoM8A+vVsyCNAnhjpvKQ2VUYCTjKz =SSdc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495295: i18n.debian.org: [DDTP] Rename language code "km_KH" to "km"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: general Severity: normal User: [EMAIL PROTECTED] Usertags: i18n.debian.org Usertags: ddtp Hi, While generating Translation-* files for the package descriptions, we detected a wrong language code: "km_KH". It should be renamed to "km". Kind regards, PS: This bug should be moved to the i18n.debian.org pseudo-package. - -- Felipe Augusto van de Wiel (faw) "Debian. Freedom to code. Code to freedom!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkimCSgACgkQCjAO0JDlykaNJQCgwYOr1ZH6B+/evpr/JHSYZYif EgkAoMtuJIvVnFqXdZ/jQUUHsGMNn6bp =6Ltv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possible mass bug filing: The possibility of attack with the help of symlinks in some Debian packages
Ivan Jager wrote: qemu-make-debian-root will continue running even if mkdir failed. Dmitry said the script has -e set - if so the script will not continue running if mkdir failed (unless it somehow overrides the -e check, e.g. mkdir /tmp/file || true). Also, assuming qemu-make-debian-root is running with PID 1234, an attacker is free to change the /tmp/mount.1234 symlink during the execution of the script. If /tmp/mount.1234 is linked to /etc/, the script will mount the freshly created filesystem image on top of /etc, making a lot of programs very sad. An attacker could then change the symlink such that debbootstrap will install anywhere he wants. (which may allow him to overwrite some files, but I haven't looked closely at debbootstrap.) I don't think these attacks are possible if the script aborts when mkdir fails. mkdir won't succeed if there is a symlink. In any case, doing something better would be good because it means an attacker can't run a denial-of-service type attack and prevent the script from running. Brian May -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming changes to supported architectures
Michael Casadevall wrote > kfreebsd-* is pretty close to releasable; they've got the archive > built in the high 80s, and are keeping up). BTW, it may be worth noting that a bunch of packages still include headers: in the Failed part of hurd-i386, 178 packages out of 1320 fail at least because of inclusion of #include (there could be others hidden by other compilation problems). That's 2.29% of the 7748 packages in our wanna-build database!... And we still have 1952 packages in the dep-wait state, a lot of them probably include too... Some of these packages could probably be fixed into automatically disabling some linuxish features, or use more standard headers (like sys/types.h...), but still a bunch of tools use for a very good reason. The 95% figure may have to be revised unless we ask non-linux ports to implement linuxish interfaces... Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the FreeRunner -- now official
Hi, Am Freitag, den 15.08.2008, 14:37 -0300 schrieb Paul Wise: > On Fri, Aug 15, 2008 at 1:04 PM, Joachim Breitner <[EMAIL PROTECTED]> wrote: > > > the FSO packaging team of the Debian project[1] is happy to announce > > that we have started to provide installation procedures and packages > > required to have your FreeRunner[2] run Debian-powered. > > Will you be moving the pkg-fso packages to Debian experimental or sid > at some point? Yes, this is expected once the next englightment snapshot is packages, in about one or two weeks. > > > To install Debian onto your MicroSD card, alongside your current Image > > on the internal Flash, see the instructions at > >http://wiki.debian.org/DebianOnFreeRunner > > This wiki page should probably moved into the InstallingDebianOn namespace: > > http://wiki.debian.org/InstallingDebianOn Hmm, I think i meant to do that, but I was confused that this page starts with „DebianOn is an effort..“. Anyways, the link is out and published, or do you think it’s very important? Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Debian on the FreeRunner -- now official
On Sat, Aug 16, 2008 at 01:08:16AM -0300, Joachim Breitner wrote: > Hmm, I think i meant to do that, but I was confused that this page > starts with „DebianOn is an effort..“. Anyways, the link is out and > published, or do you think it’s very important? Maybe you can just add a redirect page and the needed link in the index page of DebianOn (if any). -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ I'm still an SGML person,this newfangled /\ All one has to do is hit the XML stuff is so ... simplistic -- Manoj \/ right keys at the right time signature.asc Description: Digital signature
Re: Upcoming changes to supported architectures
Well, there was talk about implementing a Platform: field in dpkg to mark a package Linux, Kfreebsd, or Hurd specific without having to adding !kfreebsd-i386, etc. to the arch list or P-a-s. Not sure where that went (although I think dpkg now recognizes the field, which means quinn-diff and perhaps apt-ftparchive would be needed to get it into the Sources file, and such). Putting packages that are unwanted in an architecture for NFU is fine if the port is unreleased, but just a week or go, we had an issue with a package because the S390 buildd admins had deemed it useless and added it to that list. Michael On Fri, Aug 15, 2008 at 9:03 PM, Samuel Thibault <[EMAIL PROTECTED]> wrote: > Michael Casadevall wrote >> kfreebsd-* is pretty close to releasable; they've got the archive >> built in the high 80s, and are keeping up). > > BTW, it may be worth noting that a bunch of packages still include > headers: in the Failed part of hurd-i386, 178 packages out > of 1320 fail at least because of inclusion of #include > (there could be others hidden by other compilation problems). That's > 2.29% of the 7748 packages in our wanna-build database!... And we still > have 1952 packages in the dep-wait state, a lot of them probably include > too... > > Some of these packages could probably be fixed into automatically > disabling some linuxish features, or use more standard headers (like > sys/types.h...), but still a bunch of tools use for a > very good reason. The 95% figure may have to be revised unless we ask > non-linux ports to implement linuxish interfaces... > > Samuel > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
