Re: Recherche administrateur Debian/GNU Linux en RP, teletravail possible
Bonjour Cyril, Dommage qu'il faut tre imprativement de la rgion parisienne parce que je pense avoir le profil de l'annonce. Cordialement, Cyril Bouthors a crit : Bonjour, J'espere que ce type de mail ne derange pas; nous sommes actuellement a la recherche d'un administrateur Debian/GNU Linux (si possible DD). Voici l'annonce: ADMINISTRATEUR SYSTEMES RESEAUX LINUX Localisation : Paris (teletravail possible) Region: France Region Parisienne Type de contrat : CDI Libelle du poste : Administrateur Systemes Debian GNU/Linux Socit : Techno-vi Activit : hbergement massif mutualis de sites internet. Lieu de travail : Paris (les machines sont porte d'Aubervilliers). Rnumration : ngocier Date de dbut : ASAP Langues : Francais, Anglais informatique, Geek ;-) * Exprience : exige dans l'hbergement de site internet Logiciels : Debian, Apache, Bind, MySQL, Proftpd, iptables, Exim, CVS, MRTG, Nagios, SSH ... Languages : Shell, PHP, Perl, SQL, C, C++, HTML ... Dveloppement et mise en production de solutions ncessaire la plateforme d'hbergement (redondance, installation, mise jour remplacement de solutions ...) Support technique : Assurer un support technique auprs des clients via notre site. Astreinte : Astreinte 24/24h assurer 2 semaines par mois. Lorsque que ncessaire, installation de machines dans notre datacenter porte d'Aubervilliers. Conditions impratives : Habiter en region parisienne Avoir une exprience dans l'hbergement de sites web Etre trs l'aise dans l'environement GNU/Linux Envoyer votre CV par email au format PDF a [EMAIL PROTECTED] Cordialement. http://fr.lolix.org/search/offre/offre.php3?id=4364 -- .''`. Khalid El Fathi : :' : [EMAIL PROTECTED] `. `' www.edena-fr.org `-GPG: 1024D/5801E0DA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Recherche administrateur Debian/GNU Linux en RP, teletravail possible
Le 21/03/05 à 19:33 Cyril Bouthors ([EMAIL PROTECTED]) écrivait : Salut, Un dev debian sans expérience en hébergement web a t-il ces chances ? Car si c'est le cas, je t'enverrais mon cv avec grand plaisir ! Merci Bonjour, J'espere que ce type de mail ne derange pas; nous sommes actuellement a la recherche d'un administrateur Debian/GNU Linux (si possible DD). Voici l'annonce: ??? ADMINISTRATEUR SYSTEMES RESEAUX LINUX Localisation : Paris (teletravail possible) Region: France Region Parisienne Type de contrat : CDI Libelle du poste : Administrateur Systemes Debian GNU/Linux Société : Techno-vi Activité : hébergement massif mutualisé de sites internet. Lieu de travail : Paris (les machines sont à porte d'Aubervilliers). Rénumération : à négocier Date de début : ASAP Langues : Francais, Anglais informatique, Geek ;-) * Expérience : exigée dans l'hébergement de site internet Logiciels : Debian, Apache, Bind, MySQL, Proftpd, iptables, Exim, CVS, MRTG, Nagios, SSH ... Languages : Shell, PHP, Perl, SQL, C, C++, HTML ... Développement et mise en production de solutions nécessaire à la plateforme d'hébergement (redondance, installation, mise à jour remplacement de solutions ...) Support technique : Assurer un support technique auprès des clients via notre site. Astreinte : Astreinte 24/24h à assurer 2 semaines par mois. Lorsque que nécessaire, installation de machines dans notre datacenter à porte d'Aubervilliers. Conditions impératives : Habiter en region parisienne Avoir une expérience dans l'hébergement de sites web Etre très à l'aise dans l'environement GNU/Linux Envoyer votre CV par email au format PDF a [EMAIL PROTECTED] Cordialement. http://fr.lolix.org/search/offre/offre.php3?id=4364 -- Cyril Bouthors -- Jean-Michel Kelbert signature.asc Description: Digital signature
Re: status of buildds?
On Tue, Mar 22, 2005 at 07:57:34AM +, Paul Hedderly wrote: I can happily provide two Sun SS20's , one or two U1's and an Acorn RiscPC to help build ARM and Sparc. I'd happily give them a basic install, provide broadband access to them and hand over control to the buildd team. 32-bit SPARCstations are not fast enough to keep up with the archive, and in fact are incapable of building some source packages that require 64-bit syscalls to be present. An Ultra1 may or may not be fast enough to be useful for Sparc; vore, which is borderline on being able to keep up with unstable on its own right now, is an Ultra2 300MHz. I have no idea what reasonable specs would be for an ARM buildd, as I don't think we have any machines to compare it to which would count as reasonable under the proposed rules for release archs. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: How to define a release architecture
Hello, The Vancouver proposals satisfy all of these, potentially at the cost of removing some architectures from the set released by Debian. If we want to avoid that cost, can we come up with another proposal that solves the same problems in a way that satisfies the release team? There was a proposal first made by Marc 'HE' Brockschmidt [1] and than (independently) made by me [2] where we proposed to freeze testing even if some architectures are not ready yet, and use testing-proposed-updates to make the architectures release ready later. As I have elaborated in [2] this approach has the potential to solve the points addressed in the Vancoover proposal. As these proposals where nearly not discussed and especially there were no objections/arguments against it I want to bring up this proposal again as it might have been lost in the noise because the posts were located in the original Bits (Nybbles?)... thread. For the sake of discussion I have attached my proposal (it is a little more detailed than Marcs) at the end of this message. If this is total rubbish please tell me why and refrain from using the rough tone that has become so common in this list recently. As most developers I would like to keep this place a friendly one and I want to enjoy reading the list instead of bristling about it. Greetings Ben [1] http://lists.debian.org/debian-devel/2005/03/msg01372.html [2] http://lists.debian.org/debian-devel/2005/03/msg01647.html --- my original post --- Hello, as a non-DD I am not so tuned into the Debian project as many of you are. However I would like to make a proposal about the hot topic. As I have noticed, most people ojecting against dropping architecures feared for the coherence of the systems. They wanted to be able to have the *same* debian on all there machines and wanted security support and all this stuff for *all* archs. The persons in favour for dropping archs noticed that they delayed the release of sarge and caused a lot of extra work. So I have given this some thought and come with a proposal quite simple: Why not freeze the archive at a given time and make a release for all architectures ready until then. As this code is frozen, the porters can continue to work on the frozen codebase where only patches are allowed which are needed fix the packages for the different architectures. This seems to be the same the security team currently does. The ported architectures would become available as soon as a new revision is released (of course this should happen as soon as a new arch has caught up). This would allow a fast release and keep the burden of the arch support mainly with the porters who would be responsible for making there arch ready for release. It would allow to support each archs as long as there are sufficient developers available who can keep up with porting. The security infrastructure can be shared by all archs. Porters may even decide to skip one release if they are not up to it - this is not that bad if the release cylcle is around 12 month. This is the rough plan, now I will list some details or afterthought (skip them if you are totally annoyed by this proposal anyway): * as there already is, the possibility to exclude packages from archs is always possible making debian a little less uniform - but why should debian fix the issues not properly adressed by the upstream author anyways - if he does not care about the bugs he receives from the debian package it should simply not be relased for this arch * there is no way to *force* the developers to accept the porters patches or care for their concerns any more, but come on - developers are not a community of assholes who want to keep your architectures out of debian * it is even possible to release with a subset of the packages (only the important ones and increase each step * People missing their arch in the first release will likely complain, but the other option would have been to delay all the other archs until this arch keeps up (which might indeed have happened faster if the whole release was delayed because everyone would press the obstacles - but I think that is unfair against the archs which are release ready...) * I intentionally disregarded the problem of the mirror size and buildd because the mirror problem received a lot of good suggestions and I believe the buildd problem could be solved with additional hardware and if not architectures not up to date could simply be considered release ready and will have to wait another round... Of course there is much to think about and to fine tune but it is a proposal trying to combine the request of all users. This might be totally unrealistic as I said I have no deep insight into the debian architecture but _I_ think it is a good proposal. Please let me know what you think
Re: How to define a release architecture
On Tue, Mar 22, 2005 at 09:12:45AM +0100, Benjamin Mesing wrote: Hello, The Vancouver proposals satisfy all of these, potentially at the cost of removing some architectures from the set released by Debian. If we want to avoid that cost, can we come up with another proposal that solves the same problems in a way that satisfies the release team? There was a proposal first made by Marc 'HE' Brockschmidt [1] and than (independently) made by me [2] where we proposed to freeze testing even if some architectures are not ready yet, and use testing-proposed-updates to make the architectures release ready later. As I have elaborated in [2] this approach has the potential to solve the points addressed in the Vancoover proposal. As these proposals where nearly not discussed and especially there were no objections/arguments against it I want to bring up this proposal again as it might have been lost in the noise because the posts were located in the original Bits (Nybbles?)... thread. Except Steve said his criteria's where non-negotiable, so ... Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to define a release architecture
Steve Langasek [EMAIL PROTECTED] writes: On Mon, Mar 21, 2005 at 09:51:25PM +0100, Falk Hueffner wrote: Matthew Garrett [EMAIL PROTECTED] writes: * the release architecture must be publicly available to buy new Avoids a situation where Debian is keeping an architecture alive. I don't understand this. What is the problem with Debian is keeping an architecture alive? What problem are you trying to solve here? Given that there are architectures that have been end-of-lifed (but *are* still available for purchase new) that we've had problems keeping our autobuilders running for, I think it's a fair guess that hardware that truly is no longer available for purchase is going to be costly for the project to continue to support for a stable release. This is too vague for me. Aside from concerns about the availability and cost of replacement hardware, Has this really been a problem for Debian? it's likely that new systems will continue to be sold for some time after the chip manufacturers stop designing new (faster, better) chips, so such systems are not going to be keeping up with the increase in CPU demands of compiling the archive. There's already another criterion for this, which captures this far better. This adds up to a lot of effort for a dead-end architecture. Do you believe that such ports are going to command enough interest to be able to keep up with Debian's stable support requirements for more than 2 1/2 years (18mo. release cycle + 1 year support for oldstable) after being discontinued as a product? Given that you'll probably not be able to buy an i386 box in a few years anymore, I'd say yes. But I see little point in trying to guess here. Ports that cannot keep up should be filtered by the other criterions. Furthermore, do you believe that the limited resources of DSA (which will *always* be limited, no matter how big you say you want the team to be, because there's *always* more to do than there are people to do it) should be spent keeping stable security buildds for such architectures running, instead of on tasks that are useful to users of living architectures? This is again pretty vague. You basically say that we need to drop architectures, and we should drop those that are not living. Firstly, this particular criterion is not effective at dropping architectures: currently, all of our architectures can be bought new. Secondly, it doesn't seem like a good criterion for determining livingness: arm, mips, and m68k are basically immune to this for the next 10 years or so, since they are used in embedded systems and can be produced very cheaply. I already mentioned i386 as a contrast. In summary, it seems like this criterion isn't trying to solve some particular problem, but it just generally targeted towards cutting down the number of architectures. I already have doubts as to whether this is a reasonable premise, but even if I accept it, it seems neither effective nor particularly well-motivated. * the value of N above must not be 2 This effectively sets an upper limit on the length of time a single package may take to build, which helps ensure that doing things like security fixes for Openoffice doesn't become a problem. If the point is to set an upper limit on the length of time a single package may take to build, why not take that directly as a criterion? Wouldn't this also be an arbitrary penalty on slower architectures, though? Of course it would. But if the point is to set an upper limit on build time, that would be a good thing and not arbitrary. Build time for a single package is also only one of the concerns; the other big one being that it's much more likely to get security wrong for one out of ten buildds, rather than for one out of three. What do you mean by getting security wrong? Can you give an example? Is there evidence that this is a problem for the architectures that currently have many buildds? -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels
Petter Reinholdtsen [EMAIL PROTECTED] wrote: [Sven Luther] No, he is not, as far as i am concerned, unless he presents his apologies first. For what? Commenting on your wast amount of email posted the last few days, and his suggestion that the amount of email could make the ftpmasters delete mails by mistake? I can not really believe that is your problem, so please enlighten me. No, that is not acceptable, and probably not the right reason for this. Until evidence proves otherwise, it is just because they don't care to read those emails, and that that email address is simply forwarded to /dev/null. I didn't say it was acceptable. I tried to put it in perspective. I'm well aware of at least some of the communication issues with the ftpmasters, but truly believe these problems are because the ftpmasters are overworked, not because they are evil. And I believe this even though one of the ftpmasters told me on IRC to stop wasting his time when I wanted to discuss making the list of packages in NEW public. I put it on the account of misjudgement during stress, not evil will. I suspect you would be better off if you accepted that misjudgement and mistakes happen also for the ftpmasters. After all, your emails haven't been the perfect examples of rational and clear speek either (though not as hostile as others on the list. :). I do not hold that against you, and wish you didn't hold such miscommunications and and misjudgements against the other volunteers in Debian. That would be a solution. But then are the ftp-masters ready to get the problems they receive publicly visible ? I didn't propose to make it all public. request-tracker is capable of fine grained access control. No, a professional attitude would have them reply to the people they are working with. Again, I agree that the ftpmaster role should reply to all requests. But if the volunteers filling this role are very busy, it does not help to shout at them and send even more email. A different solution must be found, and I hope and believe we are on our way to a solution to the problems the project is facing. but this have become the norm these past couple month, and Steve's 'proposal' was the last straw. I guess I do not read the proposal the way you read it. I read it as a document describing the problems the release team and the ftpmaster experiences with the release process, and their ideas on how to improve the situation. But first and formost, I read the proposal as a good step forward for the release of sarge. After all, the ideas for reorganizing the process for etch wasn't the most important part of the vancouver announcement. The most important part was that the release managers and the ftpmasters are coordinated in their work to release Sarge. Since the meeting 189 packages have been processed from the NEW queue. I believe this is the result of the meeting, where the ftpmasters was able to meet with prospective ftpmaster assistant. I also believe the increased effort to release sarge is a result of this meeting. Well, this email is already getting fairly long. Enough hot air from me this time, I believe. I am truly sorry for loosing you. You have done a good job helping Debian progress the state of free software, and it is sad that you decide to throw in the towel because of hard language from a fellow Debian volunteer. :( -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: How to define a release architecture
On Tue, Mar 22, 2005 at 09:36:46AM +0100, Falk Hueffner wrote: On Mon, Mar 21, 2005 at 09:51:25PM +0100, Falk Hueffner wrote: Matthew Garrett [EMAIL PROTECTED] writes: * the release architecture must be publicly available to buy new Avoids a situation where Debian is keeping an architecture alive. I don't understand this. What is the problem with Debian is keeping an architecture alive? What problem are you trying to solve here? Given that there are architectures that have been end-of-lifed (but *are* still available for purchase new) that we've had problems keeping our autobuilders running for, I think it's a fair guess that hardware that truly is no longer available for purchase is going to be costly for the project to continue to support for a stable release. This is too vague for me. sigh Does the release team now have to do price shopping on replacement parts for buildds before it can say that it doesn't want to support dying platforms? Aside from concerns about the availability and cost of replacement hardware, Has this really been a problem for Debian? One of the delays affecting getting lully.d.o back on line, AIUI, was a dead power supply that was non-trivial to replace. This is a case of scarce hardware impacting a port even *before* it has ceased to become available for sale. This adds up to a lot of effort for a dead-end architecture. Do you believe that such ports are going to command enough interest to be able to keep up with Debian's stable support requirements for more than 2 1/2 years (18mo. release cycle + 1 year support for oldstable) after being discontinued as a product? Given that you'll probably not be able to buy an i386 box in a few years anymore, I'd say yes. But I see little point in trying to guess here. Ports that cannot keep up should be filtered by the other criterions. Really? You can still buy 486 chips new for use in embedded applications (or so we've been told in previous threads about C++ ABI breakage); but you think that x86 as a class will cease to become available in a matter of a few years? Furthermore, do you believe that the limited resources of DSA (which will *always* be limited, no matter how big you say you want the team to be, because there's *always* more to do than there are people to do it) should be spent keeping stable security buildds for such architectures running, instead of on tasks that are useful to users of living architectures? This is again pretty vague. You basically say that we need to drop architectures, and we should drop those that are not living. Firstly, this particular criterion is not effective at dropping architectures: currently, all of our architectures can be bought new. Secondly, it doesn't seem like a good criterion for determining livingness: arm, mips, and m68k are basically immune to this for the next 10 years or so, since they are used in embedded systems and can be produced very cheaply. I already mentioned i386 as a contrast. You didn't answer the question I asked. Do you believe that DSA should be spending its limited resources keeping hardware running for dead architectures? And given that none of our current architectures are dead, why is it important to argue this point? Build time for a single package is also only one of the concerns; the other big one being that it's much more likely to get security wrong for one out of ten buildds, rather than for one out of three. What do you mean by getting security wrong? Can you give an example? Is there evidence that this is a problem for the architectures that currently have many buildds? Is reason dead? Do I really have to have proof of past buildd compromises to argue that it's betting against the odds to not consider sheer number of machines a security concern? Do you really think that if there *was* proof of past buildd compromises in Debian, anyone would give a damn about whether we have security support for etch? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: *** SPAM *** Re: A new arch support proposal, hopefully consensual (?)
On Mon, Mar 21, 2005 at 04:31:44PM -0800, Mike Fedyk wrote: Sven Luther wrote: Ok, this is the easy part, and also what the vancouver-proposal included, the difference comes in how the minority-arches are handled, and my proposal is a 'including' proposal, while the vancouver-proposal was 'excluding'. 4) each non-tier1 arches will have its own testing infrastructure, which would take both unstable and testing in account. 5) packages are built out of unstable into an arch-specific unstable binary repository on a separate machine (altough many minority arches may share this infrastructure). This allows for source package version skew on a per arch level. In the worst case, each non-tier1 arch could have a different source package version when compared to tier1 and all of the other non-tier1 arches. To have the least possibility for source package version skew, the non-tier1 arches should branch off of tier1-testing instead of tier1-unstable. That was my first proposal, but i am not sure if it makes sense. The version skew may happen, but i feel it will be minimal. All these arches will build from unstable, the packages will go into arch-unstable instead of arch. Here we have our first chance of source skew : A) source skew due to the delay due to the build lag of the arches in question this will be limited to a couple of days in the best case, and to one version, and only for packages recently uploaded and not yet built. It is a function of the upload rate and time for build of the packages. The second version skew happens when there is a package in arch-unstable which has migrated to testing in the tier1 archive, but failed to do so in the arch-testing because of arch-specific breakage : B) source skew due to arch-specific RC bugs. This is also something transitory and easily quantifiable. Furthermore, since the waste majority of packages build correctly, it is also a rather small and something that is supposed to resorb itself, in particular since the fix will be uploaded to tier1-unstable too. On the contrary building from tier1-testing has the problem that an individual package or even arch fix may be withold from the tier2 arches for a longer period of time, as we have seen, and thus that the porting effort if needed may well start only later. So, after reflexion, i believe that the build-from-unstable, with per-arch-testing scripts slaved to the main testing for migration is a better solution than building-from-testing as i first proposed. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 21, 2005 at 11:23:05PM +0100, Tollef Fog Heen wrote: * Wouter Verhelst | On Sun, Mar 20, 2005 at 12:00:23PM +1000, Anthony Towns wrote: | Darren Salt wrote: | I demand that Anthony Towns may or may not have written... | Put them behind a firewall on a trusted LAN, use them to develop software | for arm chips, and then just follow unstable or run non-security-supported | snapshots. Apart from writing software for embedded arm things, I can't | see | the value | Linux desktop box comes to mind... | | But why would you spend over 1000 pounds on an arm Linux desktop box | instead of a few hundred pounds on a random i386 desktop box? | | Because it's cool. In both senses of the word (have you ever had to | measure the temperature of an i386 box?) (amd64, but I guess the point still applies): : [EMAIL PROTECTED] ~ acpi -V Thermal 1: ok, 26.0 degrees C I think the room temperature is 19°C. : [EMAIL PROTECTED] ~ acpi -V Thermal 1: ok, 34.0 degrees C (This is my home box, so a little less air circulation there.) Not exactly hot, are they? And what is the size of the fan, and how much noise does it generate ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two thougts about testing
Hi Joerg! Joerg Friedrich [EMAIL PROTECTED]: reading larger parts of the recent threads triggered by the 'Vancouver proposal' brought me to write this mail. Over the last two years testing became more and more a second (almost) stable distribution instead of being a preparation area for the next release. Now there is even security support it is not a officially supported release. Nevertheless I believe that testing is a good idea. But it suffers from some problems. 1. The number of packages Debian never stopped growing, and there are packages which are unmaintained but they are still in the archive. Hey, if noone is willing to maintain a package, wait a grace period (30 days) and remove it from unstable and testing. If somone needs it, he could step forward and maintain it. Where are orphaned packages without bugs or only minor or normal bugs, they should be hold in testing. If RC-bugs remain unfixed for a period, I agree with removing, but this is common practice, I think. Perhaps somethimes too slow. ;-) Perhaps wnpp websites could be improved to show a ranking list of packages which will be removed soon and why. A Section Removal Candidates in DWN could be also helpful. 2. Unstable to testing migration is one way Packages migrate to testing automaticly, but removal requires manual action. I noticed that some developers work hard to get a package or a specific version into testing, but if a new (rc) bug occurs after the migration, nothing happens. At least optional and extra packages should be removed automaticly if a new rc bug emerges. E.g. if noone claims to fix the bug, an extra package should be removed from testing after one, an optional after two weeks. And also all packages which depend on the buggy one. I fully agree. I had already suggested similar idea before. http://lists.debian.org/debian-devel/2004/10/msg01565.html Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * * Linux-Info-Tag in Dresden, am 29. Oktober 2005 * Info: http://www.linux-info-tag.de * pgpbhBuCaHKrR.pgp Description: PGP signature
How to show $arch releaseability (was: Re: How to define a release architecture)
On Tuesday 22 March 2005 08:22, Sven Luther wrote: On Mon, Mar 21, 2005 at 08:39:58PM -0300, Henrique de Moraes Holschuh wrote: On Tue, 22 Mar 2005, Peter 'p2' De Schrijver wrote: No. There needs to be some override procedure like we have for maintainers not doing their job. But that's beyond the scope of this discussion. In this case, there is nothing to override, because the overrides are actually changing something in the teams so that the team changes their mind (that might actually mean there is nobody who opposed the change in the team anymore, in a worst-case scenario). So, this should not be a point of contention in this sphere at all. It belongs in some other level. Let's drop this point as a contention point, then? No, this is the main problem, that there is no counter power or limitation to what they can decide. We saw this already in the amd64 GR issue, and we can either accept their decission or have them resign in masse and be prepared to replace them. There is no accountability, and altough the DPL supposedly mandated them, he has no actual power to do anything about it. If (for whatever reasons) none of the people behind the release team is willing to work on an arch, there is nothing anybody can do to force them to. Not tech-ctte, not the DPL, no GR, nothing! Yes, they can (and if they become crazy in the head they probably should) be removed from their position then but this doesn't magically do the work needed for a release. As Steve mentioned in another mail[1], one of the points where arches offload work onto the release team is 3) chasing down, or just waiting on (which means, taking time to poll the package's status to find out why a bug tagged 'testing' is still open), missing builds or fixes for build failures on individual architectures that are blocking RC bugfixes from reaching testing This is something I believe porters should be able to do on their own. Without delegation from the DPL, blessing via a GR or any other procedural smoke-screen. As long as people interested in an arch don't pay someone for it and they don't find someone else who does it for it currently looks to me that they will have to do it themselves, since the current release team is no longer willing to do it for them. I already hear people complaining but until now they did it, why do they suddenly stop it now??. To which I can only answer that we are talking about etch which we want to release in two years time, that are two years anyone who is interested can demonstrate that he (or she) is commited and capable that the arch in question is a viable candidate for testing/stable proper. How could this be shown? 1) One could hack britney that it mirrors REGULAR testing and additionally moves packages from $arch iff they are fit, or removes the package from your local testing iff propagating it in REGULAR testing would get the arch out of sync. With this one has a good measure of how good ones arch is keeping up with testing. 2) Trying to get/keep ones local testing repository up to speed leads directly to the problems, the release team had (has) to solve for sarge. 3) This problems can be solved by quick autobuilding, working with maintainers, porter-NMUs and so on. 4) Finally one can publically demonstrate (by showing the working local repository) that one is committed and capable of running testing for $arch. Regards, David [1] http://lists.debian.org/debian-devel/2005/03/msg02334.html -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: How to define a release architecture
On Mon, Mar 21, 2005 at 05:28:51PM -0800, Steve Langasek wrote: On Mon, Mar 21, 2005 at 09:51:25PM +0100, Falk Hueffner wrote: Matthew Garrett [EMAIL PROTECTED] writes: * the release architecture must be publicly available to buy new Avoids a situation where Debian is keeping an architecture alive. I don't understand this. What is the problem with Debian is keeping an architecture alive? What problem are you trying to solve here? Given that there are architectures that have been end-of-lifed (but *are* still available for purchase new) that we've had problems keeping our autobuilders running for, I think it's a fair guess that hardware that truly is no longer available for purchase is going to be costly for the project to continue to support for a stable release. ... The only sarge architectures that are likely of being affected by your must be publicly available to buy new rule during the next 10 years are hppa and alpha (dunno about s390). Both architectures had a long lifespan during which many machines were produced and damned fast machines are likely being produced until the last day when they'll be produced. For both of these architectures, HP still offers servers today. And if HP one day stops with this, they will still have to offer replacement parts for their costumers for _many_ years. Debian has good connections with HP. Wouldn't an arrangement with HP of getting hardware plus some years of support being an alternative to your announcement that you plan to drop the hppa and alpha architectures from Debian releases? Steve Langasek cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
packaging vmwaredsp-1.1
i'm trying to package vmwaredsp-1.1, which allows vmware to use esd/arts as a means to access sound. the problem i'm having is when i run dpkg-buildpackage -rfakeroot instead of installing the libraries in debian/tmp, it tries to put them straight into /usr/lib, which obviously fails. below is the output of dpkg-buildpackage -rfakeroot, as well as a copy of my (small) Makefile. any help would be appreciated. thanks. dh_clean -k dh_installdirs # Add here commands to install the package into debian/tmp /usr/bin/make install DESTDIR=/home/markybob/vmwaredsp-1.1/debian/tmp make[1]: Entering directory `/home/markybob/vmwaredsp-1.1' install -c -m libvmdsp.so /usr/lib install: cannot create regular file `/usr/lib/libvmdsp.so': Permission denied make[1]: *** [install] Error 1 make[1]: Leaving directory `/home/markybob/vmwaredsp-1.1' make: *** [install] Error 2 [EMAIL PROTECTED]:~/vmwaredsp-1.1$ [EMAIL PROTECTED]:~/vmwaredsp-1.1$ cat Makefile PLUGINS := libvmdsp_esd.so libvmdsp_arts.so all: libvmdsp.so $(PLUGINS) LIBS_libvmdsp_esd.so := -lesd -L. -lvmdsp LIBS_libvmdsp_arts.so := -lartsc -L. -lvmdsp lib%.so: %.o gcc -shared -Wl,-version-script=$(basename $^).map -o $@ $^ [EMAIL PROTECTED] -lpthread -ldl -lc %.o: %.c gcc -c -W -Wall -O2 -o $@ $^ execvmx: execvmx.o execvmx.o: execvmx.c test: test.c gcc -o $@ -W -Wall -O2 $ -ldl install: libvmdsp.so $(PLUGINS) install -c -m libvmdsp.so /usr/lib for a in $(PLUGINS); do install -c -m 644 $$a /usr/lib; done clean: rm -f *.so test execvmx *.o [EMAIL PROTECTED]:~/vmwaredsp-1.1$ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to define a release architecture
On Mirt, 2005-03-22 at 00:11 +0100, Peter 'p2' De Schrijver wrote: If Debian is keeping an arch alive so much that one can still buy it new, I certainly can't see why we should not continue releasing for that arch, however. So I'd say Matthew's explanation is not perfect. But the reasoning behind it is not difficult to spot. Throwing out this requirement makes sense, if and only if there is another way to get sure a released arch will not be left stranded. So, let's work on these alternate ways, so that this rule can be removed. It's not because you can't buy a new machine, the arch suddenly stops being useful. I think the point of this requirement is to support it we need buildds in the future for security fixes. Hence while I might like my mips box, etc. it would be irresponsible for us to do a release that we could not support in e.g. two years time when the motherboards of our buildds die. Perhaps this clause could be refined, though: should it be a sub-arch requirement and not just an arch one; or could we specify that its OK to release if we have a given stock of replacement hardware available (e.g. given our good relationship with HP, its likely we could get sufficient Alpha hardware for several years after HP finally stop shipping Alphas). Cheers, Peter (p2). Regards Alastair McKinstry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to show $arch releaseability (was: Re: How to define a release architecture)
On Tue, Mar 22, 2005 at 11:02:47AM +0100, David Schmitt wrote: On Tuesday 22 March 2005 08:22, Sven Luther wrote: On Mon, Mar 21, 2005 at 08:39:58PM -0300, Henrique de Moraes Holschuh wrote: On Tue, 22 Mar 2005, Peter 'p2' De Schrijver wrote: No. There needs to be some override procedure like we have for maintainers not doing their job. But that's beyond the scope of this discussion. In this case, there is nothing to override, because the overrides are actually changing something in the teams so that the team changes their mind (that might actually mean there is nobody who opposed the change in the team anymore, in a worst-case scenario). So, this should not be a point of contention in this sphere at all. It belongs in some other level. Let's drop this point as a contention point, then? No, this is the main problem, that there is no counter power or limitation to what they can decide. We saw this already in the amd64 GR issue, and we can either accept their decission or have them resign in masse and be prepared to replace them. There is no accountability, and altough the DPL supposedly mandated them, he has no actual power to do anything about it. If (for whatever reasons) none of the people behind the release team is willing to work on an arch, there is nothing anybody can do to force them to. Not tech-ctte, not the DPL, no GR, nothing! Yes, they can (and if they become crazy in the head they probably should) be removed from their position then but this doesn't magically do the work needed for a release. The problem is when they actively oppose work. Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to define a release architecture
On Tue, Mar 22, 2005 at 07:45:00AM +, Alastair McKinstry wrote: I think the point of this requirement is to support it we need buildds in the future for security fixes. Hence while I might like my mips box, etc. it would be irresponsible for us to do a release that we could not support in e.g. two years time when the motherboards of our buildds die. Mips is extremely alive and it was a huge surprise if new mips-based products weren't available ten years from now. Perhaps this clause could be refined, though: should it be a sub-arch requirement and not just an arch one; or could we specify that its OK to release if we have a given stock of replacement hardware available (e.g. given our good relationship with HP, its likely we could get sufficient Alpha hardware for several years after HP finally stop shipping Alphas). The release team's announcement affects only hppa and alpha in the forseeable future. And in both cases an arrangement with HP could erase the problems. Regards Alastair McKinstry cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: packaging vmwaredsp-1.1
On Tue, Mar 22, 2005 at 04:43:56AM -0600, Marcos Pinto wrote: i'm trying to package vmwaredsp-1.1, which allows vmware to use esd/arts as a means to access sound. the problem i'm having is when i run dpkg-buildpackage -rfakeroot instead of installing the libraries in debian/tmp, it tries to put them straight into /usr/lib, which obviously fails. below is the output of dpkg-buildpackage -rfakeroot, as well as a copy of my (small) Makefile. any help would be appreciated. thanks. It does exactly what your install target in your Makefile comprises. ... install -c -m libvmdsp.so /usr/lib ... You need to change the destination to $(DESTDIR)/usr/lib Uwe -- MMK GmbH, Universitaetsstr. 11, 58097 Hagen [EMAIL PROTECTED] Tel: +2331 840446Fax: +2331 843920 signature.asc Description: Digital signature
Re: How to define a release architecture
On Tue, Mar 22, 2005 at 07:45:00AM +, Alastair McKinstry wrote: On Máirt, 2005-03-22 at 00:11 +0100, Peter 'p2' De Schrijver wrote: If Debian is keeping an arch alive so much that one can still buy it new, I certainly can't see why we should not continue releasing for that arch, however. So I'd say Matthew's explanation is not perfect. But the reasoning behind it is not difficult to spot. Throwing out this requirement makes sense, if and only if there is another way to get sure a released arch will not be left stranded. So, let's work on these alternate ways, so that this rule can be removed. It's not because you can't buy a new machine, the arch suddenly stops being useful. I think the point of this requirement is to support it we need buildds in the future for security fixes. Hence while I might like my mips box, etc. it would be irresponsible for us to do a release that we could not support in e.g. two years time when the motherboards of our buildds die. The arch should still be available, but a big enough collection of existing machines will do here IMO. Not that this holds for mips as there are new MIPS based systems available. Both broadcom and PMC announced new MIPS based chips for example. And there is AMD (Alchemy) and a bunch of others using MIPS as well. Cheers, Peter (p2). signature.asc Description: Digital signature
Re: The 98% and N=2 criteria (was: Vancouver meeting - clarifications)
On Sat, Mar 19, 2005 at 09:52:18AM -0600, Gunnar Wolf wrote: Steve Langasek dijo [Fri, Mar 18, 2005 at 11:32:08PM -0800]: There are packages we recognize will be of little use in certain architectures - say, KDE on m68k, qemu on a !i386, etc. They should be built anyway on all architectures where expected to run be buildable, anyway, as a QA measure - many subtle bugs appear as the result of architecture-specific quirks. Architecture: any means build anywhere. We could introduce a second header, say, Not-deploy-for: or Not-required-for:. This would mean that KDE _would_ be built for m68k if the buildds are not too busy doing other stuff, and probably would not enter our archive (or would enter a different section - just as we now have contrib and non-free, we could introduce not-useful ;-) ) As pointed out in a recent thread, most of the core hardware portability issues are picked up just by building on the big three -- i386, powerpc, amd64. If we know the software isn't going to be used, is it actually useful to build it as a QA measure? What value is there, in fact, in checking for bugs that will only be tripped while building software that isn't going to be used? As you say, _most_ of the issues are triggered by one of those three chips, not all. And, by not making a hard requirement to compile the packages which will not be used, you are not holding the project back waiting for m68k's KDE. Probably m68k will _never_ compile KDE, as I doubt their buildds are ever idle - But what do you prefer, say, for our ia64 buildd, to just sit there waiting for a new package to arrive, or to start compiling something that will be useful only for QA, and only probably? But, er, ia64 isn't a slow architecture at all, so there's no reason that the packages being built there wouldn't be usable in the real world -- ia64 should build kde, and then upload it, because it's useful. What was being proposed here, OTOH, was to build packages for architectures where the packages wouldn't be used in the real world due to architecture constraints. I can think of two great reasons not to use random, never-to-be-used packages as a means of doing QA on embedded architectures: it's a waste of electricity, and it doesn't bring a benefit in proportion to the effort. If we find that our toolchains for embedded architectures are weak, then we should certainly try to do better QA on them -- by finding tests that are relevant to the real world, not just by proving that our buildds are heavyweight compilation champions. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Ubuntu Patches
On Mon, Mar 21, 2005 at 07:29:24PM -0800, Thomas Bushnell BSG wrote: Um, so these patches, are they bugfixes? Not necessarily, many of Ubuntu patches are just enhancements that _could_ be made in Debian. See for example http://bugs.debian.org/246935, they might or might not have the corresponding 'wishlist' severity (RFE) bug filed in Debian's BTS. If you take a look at the patches yourself you would probably understand it better. Regards Javier PS: I spotted this bug in Ubuntu before Matt had time to put it in the BTS but that's just probably because they were overloaded with their release at the time. signature.asc Description: Digital signature
Re: How to define a release architecture
The only sarge architectures that are likely of being affected by your must be publicly available to buy new rule during the next 10 years are hppa and alpha (dunno about s390). Given IBM's track record in backwards compatibility I don't expect s390 to die at all :) Even the latest zSeries can still run IBM 360 code afaik. Cheers, Peter (p2). signature.asc Description: Digital signature
Re: How to define a release architecture
On Tue, 22 Mar 2005, Sven Luther wrote: On Mon, Mar 21, 2005 at 08:39:58PM -0300, Henrique de Moraes Holschuh wrote: On Tue, 22 Mar 2005, Peter 'p2' De Schrijver wrote: No. There needs to be some override procedure like we have for maintainers not doing their job. But that's beyond the scope of this discussion. In this case, there is nothing to override, because the overrides are actually changing something in the teams so that the team changes their mind (that might actually mean there is nobody who opposed the change in the team anymore, in a worst-case scenario). So, this should not be a point of contention in this sphere at all. It belongs in some other level. Let's drop this point as a contention point, then? No, this is the main problem, that there is no counter power or limitation to what they can decide. We saw this already in the amd64 GR issue, and we can either accept their decission or have them resign in masse and be prepared to replace them. Then start another thread in -project about the accountability issue. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: my thoughts on the Vancouver Prospectus
On Mon, Mar 21, 2005 at 08:08:57PM +0100, Wouter Verhelst wrote: On Fri, Mar 18, 2005 at 06:44:46PM -0800, Steve Langasek wrote: On Mon, Mar 14, 2005 at 10:48:10PM -0500, Branden Robinson wrote: The next stage in the process is to actually sell the proposed changes for etch to the developers at large[2]. There are several points which can and should be discussed; I myself am not certain what the motivations for some criteria are, and it would be good to have those documented so that we can tell if an when they no longer apply. Let me offer some examples: * Why is the permitted number of buildds for an architecture restricted to 2 or 3? - Architectures which need more than 2 buildds to keep up with package uploads on an ongoing basis are very slow indeed; while slower, low-powered chips are indeed useful in certain applications, they are a) unlikely to be able to usefully run much of the software we currently expect our ports to build, Please leave it to our users to define what is useful. Does this mean build it all and let the users decide for themselves what they want to use? Or does it mean ask the users before getting rid of packages that aren't used on the architectures? If the former, that doesn't seem to leave much room for ever improving the return porters to embedded/slow systems will ever get on their buildd investment, does it? and b) definitely too slow in terms of single-package build times to avoid inevitably delaying high-priority package fixes for RC bugs. I would not have any problem with multi-staged security announcements, for example. Well, I guess just as I can't speak on behalf of all users and say they won't use KDE on m68k, you can't speak on behalf of them and say they're ok with having delayed security support for m68k. :) The security team seems historically unconvinced that staggered security announcements are worthwhile -- at least partly this is because staggered security announcements are more work, AIUI. In any case, you'd have to persuade them that this is a good idea before the release team could consider it. - If an architecture requires more than 3 buildds to be on-line to keep up with packages, we are accordingly spreading thin our trust network for binary packages. I'm sure I'll get flamed for even mentioning it, but one concrete example of this is that the m68k port, today, is partially dependent on build daemons maintained by individuals who have chosen not to go through Debian's New Maintainer process. This is absolutely not the case. It is true that some of our buildd machines have a local admin that are not developers or at least in NM; but * That is equally true for the buildd hosts of some of the other architectures (e.g., s390, or sparc) * Nobody has ever been offered to maintain a buildd host who was not at least in NM. I did train Matthias Ulrichs and Goswin von Brederlow when they were, but Goswin's machines were disconnected from w-b even before he was rejected. I'm also quite sure today I won't do that again, precisely because Goswin was rejected and I don't want to think of what might've happened had he been able to upload trojanized binaries (not that I think he would have done so). I'm interested in what your base for the above assertion is. Merely a misunderstanding about the current state of affairs with the m68k port, it seems. Certainly with all the fuss Ingo has made over this issue in the past, I had the impression that it was actually a current issue -- not a hypothetical. Whether or not these particular individuals should be trusted, the truth is that when you have to have 10 buildds running to keep up with unstable, it's very difficult to get a big-picture view of the security of your binary uploads. Security is only as strong as the weakest link. True; but these concerns can be better addressed by spelling out some security requirements (and somehow ensuring they are being followed) rather than imposing some random, unrelated, limit to the number of hosts in use. FSVO better; having explicit security standards is good, but increasing the number of people (and machines) involved still increases the chances that somewhere, they will fail to be met. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: How to show $arch releaseability (was: Re: How to define a release architecture)
Sven Luther [EMAIL PROTECTED] wrote: The problem is when they actively oppose work. I have not seen the release team actively oppose useful work. I don't /think/ I've seen them actively oppose useless work, either. I'm fairly sure I've seen them actively oppose work that would delay the release, which sounds like their job. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to define a release architecture
On Mon, Mar 21, 2005 at 11:13:40PM +, Matthew Garrett wrote: ... People are far too busy picking on small details of proposals they don't like instead of coming up with a decent and comprehensive set of solutions. If you don't like what's been proposed, produce something better. For the most part, that's how Debian works. My proposal is: Change the release process to a release process without testing. Rationale: The whole release team plus Anthony Towns who's the main developer of testing signed the following statement: -- snip -- We project that applying these rules for etch will reduce the set of candidate architectures from 11 to approximately 4 ([...]). This will drastically reduce the architecture coordination required in testing, giving us a more limber release process and (it is hoped) a much shorter release cycle on the order of 12-18 months. -- snip -- If your release process has problems with the current number of architectures, you have two choices: - announce that you plan to drop two third of the architectures - change the release process I'd prefer the second choice. Testing has it's advantages. You know that all packages have there dependencies fulfilled [1], were built on all architectures, and some kinds of bugs are less likely to make it into testing. But testing also has it's costs (read e.g. what Steve listed as three points that probably account for more of my release management time than anything else [2] - they are testing specific tasks). Testing helps with some problems like ensuring that all dependencies are fulfilled and that packages have been built on all architectures - but this information is also available elsewhere. What instead? What about the simple pre-testing release process: - announce a freeze date - freeze unstable at the announced date - work a few months on improving frozen until it's in a releasable state I do believe that such a simple release process would allow releasing once a year with a dozen architectures. And if the buildd on an architecture wasn't able to keep up with unstable it wasn't nice - but it wasn't a problem for the release management since it was enough if the buildd started to keep up with frozen after the freeze (and the number of daily uploads to frozen should be much smaller than the number of daily uploads to frozen). This would therefore make (at least from a release management point of view) all discussions regarding the required speed of buildds obsolete. cu Adrian [1] but build dependencies are still not tracked [2] http://lists.debian.org/debian-devel/2005/03/msg02334.html -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to define a release architecture
On Mon, Mar 21, 2005 at 05:28:51PM -0800, Steve Langasek wrote: This adds up to a lot of effort for a dead-end architecture. Do you believe that such ports are going to command enough interest to be able to keep up with Debian's stable support requirements for more than 2 1/2 years (18mo. release cycle + 1 year support for oldstable) after being discontinued as a product? I'm assuming you're talking about m68k here. If not, please correct me. m68k has been EOLed in desktop hosts for about 10 years now. There are still people interested in it, who install Linux on their old hardware for the first time, even today. I think that pretty much translates to an answer of 'yes' to the above question. Furthermore, do you believe that the limited resources of DSA (which will *always* be limited, no matter how big you say you want the team to be, because there's *always* more to do than there are people to do it) should be spent keeping stable security buildds for such architectures running, instead of on tasks that are useful to users of living architectures? There is some overlap between the groups of 'DSA' and 'buildd admins', but a) that overlap is not absolute, and b) that overlap is not necessary. If the DSA people do not have enough time to spend in keeping stable security buildds for old architectures running, they are welcome to hand over buildd maintenance to other people; there are enough experienced people to take over, if required. If you're also talking about m68k here, then your point is moot; there are no people involved with DSA that maintain any m68k buildd host. * the value of N above must not be 2 This effectively sets an upper limit on the length of time a single package may take to build, which helps ensure that doing things like security fixes for Openoffice doesn't become a problem. If the point is to set an upper limit on the length of time a single package may take to build, why not take that directly as a criterion? It is even more objective. It might also encourage people to split unreasonably large packages. Wouldn't this also be an arbitrary penalty on slower architectures, though? Yes. In the specific case of OpenOffice.org, the point is moot. OpenOffice.org requires some assembly glue, so needs to be ported to every architecture it runs on; currently, there are OpenOffice.org packages for i386, powerpc, sparc, and s390; none for any of the slower architectures, and doing them wouldn't be possible without someone spending their time on it anyway. In the general case, as I have said before, I don't think anyone would take offense at a security announcement being sent out containing MD5sums for packages for i386, sparc, powerpc, alpha, ia64 and s390, with a message like 'packages for m68k, mips, mipsel, arm, and hppa will be announced when ready' if the delay would become unacceptable, or so. The porters don't control the size of the largest packages in the archive; and package sizes do continue to go up, just like everything else. Not just that; package build times for equally-sized packages continue to go up as well, because of increased optimisation. Build time for a single package is also only one of the concerns; the other big one being that it's much more likely to get security wrong for one out of ten buildds, rather than for one out of three. Are there any specific concerns, or is this just a general feeling that we m68k people might not know what we're doing, security-wise? If the latter, spelling out a security policy that we have to follow might be another alternative. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
Sven Luther wrote: Still i believe i have made some constructive proposals, and even if my first posts may have been a bit too aggressive, for which i apologize, or too many, i think it is also a prove of the passion which lies on this issue. Something which has the potential to affect many of what we believe debian is, and which is handled by utter contempt, at least in the initial posting. I give my support to Sven. And I think there is many more people in this list who should apologize, too. And I believe that the Vancouver proposal, if implemented as intended up to now, will not only affect what Debian really *is*, but in some ways will *destroy* what Debian is. Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to define a release architecture
On Tue, Mar 22, 2005 at 01:11:32AM -0800, Steve Langasek wrote: On Tue, Mar 22, 2005 at 09:36:46AM +0100, Falk Hueffner wrote: This is too vague for me. sigh Does the release team now have to do price shopping on replacement parts for buildds before it can say that it doesn't want to support dying platforms? Paying for m68k buildd hardware has generally been the responsability of the buildd maintainers, with a few notable exceptions (maxing out the RAM of all our buildd hosts was one). In general, paying for buildd hardware most certainly has never been the release team's responsability, so I fail to see why they should worry about it. Aside from concerns about the availability and cost of replacement hardware, Has this really been a problem for Debian? One of the delays affecting getting lully.d.o back on line, AIUI, was a dead power supply that was non-trivial to replace. This is a case of scarce hardware impacting a port even *before* it has ceased to become available for sale. If this problem even exists with hardware that is still available to buy new, then how would a criterion of 'must be available to buy new' help aleviate the the problem? [...] You didn't answer the question I asked. Do you believe that DSA should be spending its limited resources keeping hardware running for dead architectures? No. They never did, and they never should. The fact that some people are involved with both DSA and buildd maintenance doesn't mean DSA, as a group, has anything to do with buildd maintenance. And given that none of our current architectures are dead, why is it important to argue this point? Because the criterion of 'must not require more than two buildd hosts' would effectively kill off some of our architectures, for no real reason. Build time for a single package is also only one of the concerns; the other big one being that it's much more likely to get security wrong for one out of ten buildds, rather than for one out of three. What do you mean by getting security wrong? Can you give an example? Is there evidence that this is a problem for the architectures that currently have many buildds? Is reason dead? Do I really have to have proof of past buildd compromises to argue that it's betting against the odds to not consider sheer number of machines a security concern? Yes. We've had buildd hosts ever since Debian 2.0, which is ages old now, and restricted buildd hosts have apparently not ever become compromised, while some of our non-restricted hosts have. This makes me think that the security on buildd hosts is better than those on general developer-accessible machines, and that, thus, we should not look at restricted hosts rather than the general accessible machines. Right? If there are concerns regarding security, I think it's best to name them and deal with them, rather than imposing arbitrary limits which do nobody any good. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ubuntu Patches
On Mon, Mar 21, 2005 at 07:29:24PM -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: The only distinction here is between merely publishing the patches on our website, and pushing the patch to the Debian maintainer immediately. We publish all of our patches relative to Debian on a regular basis, and make an honest effort to sort and separate them to the extent that this can be automated. Um, so these patches, are they bugfixes? Some are bug fixes, some are enhancements, some are Ubuntu branding, some are a result of different policy decisions (e.g. the desktop should look this way), etc. The last two, for instance, would typically be noise as far as Debian's concerned. In the case of bug fixes that we found out about due to an RC bug that we imported from debbugs, we have a clear policy that we should push them back. Others are left up to the judgement of individual Ubuntu developers, but still do often get pushed back when time and sense allows. To try to clarify why it doesn't seem to make sense in practice to have a simple policy of sending back all patches, I'll take the example most familiar to me. My Ubuntu installer changes roughly divide down into the following categories (and this is a slightly unusual case since I have commit access in both Debian and Ubuntu, I guess, but bear with me): * Ubuntu branding. Enormous patches due to having to update .po files as well, and really not very interesting to anyone, but it has to be done. (Making this easier for people to do, somehow, would be nice; I estimate a few man-weeks of largely tedious work to produce a fully custom-branded and translated installer from scratch at the moment. Handling branding and translations in the d-i manual is a particularly thorny and unsolved problem.) * Deliberately different distribution policy. For instance, Ubuntu assumes a single CD, patches out some installer questions as a result, and does stuff like copying desktop packages to the hard disk in the first stage so that you can ditch the CD altogether after the first reboot. Doesn't make sense for Debian, at least not unless we can figure out a way to make this switchable at a high level in the installer build process, which isn't easy. I'm more or less resigned to carrying these patches for a long time. Since debconf questions are asked programmatically, patches to change question structure can often be larger than you might expect (c.f. partman-auto, base-config). * Accelerated changes due to different schedules. For instance, Ubuntu assumes a 2.6 kernel, and now the installer uses hotplug and udev rather than discover and devfs to match this. I made all these changes in such a way that they could be merged back to Debian with suitable conditionals, so that even if Debian e.g. doesn't want to use hotplug in the installer, it should be switchable by a small change in the debian-installer build process. However, with d-i largely frozen for sarge and these changes still highly experimental until recently, I didn't want to merge them back yet. I intend to land them after sarge when large d-i development work is more appropriate; but that didn't change the fact that we wanted to make the change for Ubuntu on our own schedule. (Life is so much easier when Debian isn't in a freeze.) * Generally-applicable bug fixes. Often I just apply these with my Debian hat on, because it's less work all round that way: I have a less complicated patch to merge, and some d-i hacker doesn't have to run around applying my patches even though I already have commit access. Sometimes code is already divergent due to freezes or whatever, and I just have to apply it in both places. Sometimes I'm in a tearing hurry because we're doing a release the next day and have other priorities as a result, and this is where bug-fix patches are most likely to fall through the cracks due to human error; fortunately we have the Big Pile of Patches to refer to, thanks to Scott, and I can go through when things are less busy and try to sync up. * Generally-applicable new features. The installer isn't somewhere where you find a lot of these any more, and there's only so much code that one person can write, but there are a few. In the case of rescue mode, after answering a couple of dozen similar questions from Ubuntu users I was interested enough in it off my own bat to go off and write the bulk of the code in my spare time, commit it to the debian-installer Subversion repository, and then merge it into Ubuntu for more general testing, which worked fairly well. I've yet to decide what to do about Kickstart support, which is very new, lightly tested, has a fair bit of Ubuntu-specific code in it, and includes at least two very scary hacks about whose correctness
Re: How to define a release architecture
* Wouter Verhelst ([EMAIL PROTECTED]) [050322 13:05]: In the general case, as I have said before, I don't think anyone would take offense at a security announcement being sent out containing MD5sums for packages for i386, sparc, powerpc, alpha, ia64 and s390, with a message like 'packages for m68k, mips, mipsel, arm, and hppa will be announced when ready' if the delay would become unacceptable, or so. I have heared that the current scripts used on security.debian.org do not really support this. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to define a release architecture
On Tue, Mar 22, 2005 at 01:28:18PM +0100, Andreas Barth wrote: * Wouter Verhelst ([EMAIL PROTECTED]) [050322 13:05]: In the general case, as I have said before, I don't think anyone would take offense at a security announcement being sent out containing MD5sums for packages for i386, sparc, powerpc, alpha, ia64 and s390, with a message like 'packages for m68k, mips, mipsel, arm, and hppa will be announced when ready' if the delay would become unacceptable, or so. I have heared that the current scripts used on security.debian.org do not really support this. Implementing whatever will come out of this will require some extra coding anyway; it won't hurt to have to add the security.d.o scripts to the list of 'things that need changes'. Sorry, but that's not a valid argument. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to define a release architecture
* Wouter Verhelst ([EMAIL PROTECTED]) [050322 13:35]: On Tue, Mar 22, 2005 at 01:28:18PM +0100, Andreas Barth wrote: * Wouter Verhelst ([EMAIL PROTECTED]) [050322 13:05]: In the general case, as I have said before, I don't think anyone would take offense at a security announcement being sent out containing MD5sums for packages for i386, sparc, powerpc, alpha, ia64 and s390, with a message like 'packages for m68k, mips, mipsel, arm, and hppa will be announced when ready' if the delay would become unacceptable, or so. I have heared that the current scripts used on security.debian.org do not really support this. Implementing whatever will come out of this will require some extra coding anyway; it won't hurt to have to add the security.d.o scripts to the list of 'things that need changes'. Sorry, but that's not a valid argument. It was not meant as we can't do it, but as we need to put time into that if we decide to do it. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to show $arch releaseability (was: Re: How to define a release architecture)
On Tue, 22 Mar 2005 11:02:47 +0100, David Schmitt [EMAIL PROTECTED] wrote: [snip] As Steve mentioned in another mail[1], one of the points where arches offload work onto the release team is 3) chasing down, or just waiting on (which means, taking time to poll the package's status to find out why a bug tagged 'testing' is still open), missing builds or fixes for build failures on individual architectures that are blocking RC bugfixes from reaching testing And it's not just the number of arches. Slow arches really do make more work, and it's not just about migrations to testing. There's a concrete example right now that shows why a large number of slow autobuilders, working in parallel, isn't a great solution. (Although distcc is another story, if its results are truly reproducible.) The latest uim FTBFS twice on ARM because of the removal of howl dependencies from gnome packages. The rebuilt gnome-vfs2 still hadn't made it to unstable as of the second try, so the archive wasn't in a state that any package dependent on one of its binary packages could be autobuilt. It would probably build now, but Steve doesn't want to submit it a third time until the build-depends have actually been inspected for stray libhowl.la files -- and I can't really blame him. We are not swimming in arm buildd cycles. The inspection will be a painful process for anyone who doesn't have an otherwise idle ARM handy. Sure, he (or I) can massage the build log to construct URLs for files in pool, and pull them to $fast_box, unpack, and inspect. But an arm porter is in a better position to do this inspection, since apt-get build-dep will work without a bunch of script-fu. Of course, that's going to pollute the box; so do it in a nice new chroot. Better have a mirror of a sane snapshot of unstable handy. There are things that can be done to make this easier, starting with better facilities for snapshotting chroots and overlaying them using device-mapper or unionfs. But it does take some commitment by people who have (access to) boxes they can experiment on -- and preferably also skills in many programming languages and laboratory-scale systems administration. Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to show $arch releaseability (was: Re: How to define a release architecture)
On Tue, Mar 22, 2005 at 12:45:56PM +, Michael K. Edwards wrote: On Tue, 22 Mar 2005 11:02:47 +0100, David Schmitt [EMAIL PROTECTED] wrote: As Steve mentioned in another mail[1], one of the points where arches offload work onto the release team is 3) chasing down, or just waiting on (which means, taking time to poll the package's status to find out why a bug tagged 'testing' is still open), missing builds or fixes for build failures on individual architectures that are blocking RC bugfixes from reaching testing The inspection will be a painful process for anyone who doesn't have an otherwise idle ARM handy. Sure, he (or I) can massage the build log to construct URLs for files in pool, and pull them to $fast_box, unpack, and inspect. But an arm porter is in a better position to do this inspection, since apt-get build-dep will work without a bunch of script-fu. Eh, not particularly. This inspection can be done on any machine, and there's no reason not to just use the fastest one available to you (whether that's by CPU, or network); what's needed here is to first identify which packages that were used in the build were broken, which can't be done with apt-get build-dep even on arm; and then verify whether the packages in question have been fixed in a newer version. In general, just looking at apt-get build-dep doesn't guarantee that you haven't overlooked the problem that caused the build failure in the first place, and it isn't even guaranteed to install the same *packages* (let alone package *versions*) as sbuild. ARM porters aren't in a better *position* to do this kind of thing, but I certainly expect them to have more *incentive* to do this kind of thing for their port. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: How to show $arch releaseability
Hi, Michael K. Edwards: The latest uim FTBFS twice on ARM because of the removal of howl dependencies from gnome packages. The rebuilt gnome-vfs2 still hadn't made it to unstable as of the second try, so the archive wasn't in a state that any package dependent on one of its binary packages could be autobuilt. That sounds more like a case of too-loose build-dependencies to me rather than architecture specific problems. This can also hit i386, the fact that it hit ARM this time is sheer coincidence. Simon signature.asc Description: OpenPGP digital signature
Re: How to show $arch releaseability (was: Re: How to define a release architecture)
On Tue, Mar 22, 2005 at 12:45:56PM +, Michael K. Edwards wrote: On Tue, 22 Mar 2005 11:02:47 +0100, David Schmitt [EMAIL PROTECTED] wrote: [snip] As Steve mentioned in another mail[1], one of the points where arches offload work onto the release team is 3) chasing down, or just waiting on (which means, taking time to poll the package's status to find out why a bug tagged 'testing' is still open), missing builds or fixes for build failures on individual architectures that are blocking RC bugfixes from reaching testing And it's not just the number of arches. Slow arches really do make more work, and it's not just about migrations to testing. There's a concrete example right now that shows why a large number of slow autobuilders, working in parallel, isn't a great solution. (Although distcc is another story, if its results are truly reproducible.) The latest uim FTBFS twice on ARM because of the removal of howl dependencies from gnome packages. Except that arm doesn't *have* a large number of slow autobuilders, working in parallel. They have four, and are having problems keeping up right now. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to show $arch releaseability (was: Re: How to define a release architecture)
On Tue, 22 Mar 2005 04:58:33 -0800, Steve Langasek [EMAIL PROTECTED] wrote: Eh, not particularly. This inspection can be done on any machine, and there's no reason not to just use the fastest one available to you (whether that's by CPU, or network); what's needed here is to first identify which packages that were used in the build were broken, which can't be done with apt-get build-dep even on arm; and then verify whether the packages in question have been fixed in a newer version. In general, just looking at apt-get build-dep doesn't guarantee that you haven't overlooked the problem that caused the build failure in the first place, and it isn't even guaranteed to install the same *packages* (let alone package *versions*) as sbuild. Diffing the logs against a successful build on powerpc caught the libpanel-applet2-dev (source gnome-vfs2) version skew immediately, and looking at the changelog confirmed that the version arm pulled in was built against libhowl and was enough to cause the failure. But if you want to be certain that there isn't additional breakage hiding behind that, you need to inspect the actual packages. Here's what I had in mind: apt-get --download-only build-dep uim on a clean chroot, arm host, against snapshot.debian.net for the appropriate date gets you 95% of the way to a matching build system. Match (cd /var/cache/apt/archives ls *.deb) against perl -ane 'print $1\n if m#^Unpacking.*/([^/]*\.deb)\)#' arm.log and you find a couple of packages for which you need to fetch the precise version from snapshot. dpkg --contents gets you enough information for this particular case, but in general you want to actually install them and at least run configure to verify, say, that autoreconf did the right thing -- and that requires $arch. Doesn't necessarily have to be your own, if you're a DD and have access to developer boxes; but it helps to have a quick way to bypass debootstrap, and that takes a little planning ahead. I'd be interested in seeing something equally simple that follows the same logic as the apt-get step but doesn't have to be done from $arch. Bonus points if it monitors buildd failures and pulls packages to a local mirror promptly so one doesn't have to go fishing around on snapshot. Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
Mike Fedyk [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: I was thinking of having support in the buildd to fetch source, check a local patch archive for fixes, patch source, build package, add patch to each debs /usr/share/doc/package/. Would that satisfy the GPL or other DFSG licenses? As long as the patches are made available to the same people who can get the binaries, you should be set. Though, just for ease of access, it should be made available in a similar way to what the tier1 arches do for their sources. Mike As I said, the patch relative to the debian source package would be in the deb. I believe the changes file and version can be made to make DAK keep the right source version in the archive. So people that have the deb do have the patch and can get the source to apply it to. The idea for this comes from having some 5 line patch to add amd64 support to a package and maintainers that don't add the patch for several uploads. I guess for tier1/2 archs porters can just NMU them in. But for tier3, totaly new ports or experimental archives like the gcc-4.0 compiled amd64 one where the patches might not be ready for unstable this could be usefull. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to show $arch releaseability
Simon Richter wrote: Hi, Michael K. Edwards: The latest uim FTBFS twice on ARM because of the removal of howl dependencies from gnome packages. The rebuilt gnome-vfs2 still hadn't made it to unstable as of the second try, so the archive wasn't in a state that any package dependent on one of its binary packages could be autobuilt. That sounds more like a case of too-loose build-dependencies to me rather than architecture specific problems. This can also hit i386, the fact that it hit ARM this time is sheer coincidence. Not exactly, because build-dependencies are seldomly tested on i386. Thiemo signature.asc Description: Digital signature
Re: How to define a release architecture
On Tue, Mar 22, 2005 at 01:13:15PM +0100, Wouter Verhelst wrote: On Tue, Mar 22, 2005 at 01:11:32AM -0800, Steve Langasek wrote: You didn't answer the question I asked. Do you believe that DSA should be spending its limited resources keeping hardware running for dead architectures? No. They never did, and they never should. The fact that some people are involved with both DSA and buildd maintenance doesn't mean DSA, as a group, has anything to do with buildd maintenance. - the Debian System Administrators (DSA) must be willing to support debian.org machine(s) of that architecture - there must be a developer-accessible debian.org machine for the architecture. Who maintains crest.debian.org? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Buildd redundancy (was Re: Bits (Nybbles?) from the Vancouver...)
On Mon, Mar 21, 2005 at 01:44:37PM -0800, Steve Langasek wrote: On Mon, Mar 21, 2005 at 06:23:30PM +0100, Wouter Verhelst wrote: On Sat, Mar 19, 2005 at 02:12:50PM -0800, Steve Langasek wrote: TTBOMK, even m68k has one buildd admin per buildd False. There are some of us who currently don't maintain more than one buildd host, but with the exception of Roman, we all have (or have had) more than one buildd host under our responsability. I meant that there were buildds to which only one admin had access. Ah, that way. Most buildds have two or three admins that can log and handle things. TTBOMK, there is no single person that has access to /all/ m68k buildd hosts, but that isn't really needed. It could be the case that there are hosts to which only one person has access, yes (I'm not quite sure about cts' machines); but I would consider that a bug. ISTR seeing comments from m68k admins in the recent past that they would have to check with Stephen Marenka about missing packages, for instance; but maybe this was longer ago than I realized. We don't generally touch eachother's hosts for non-urgent matters, but that's just a matter of courtesy. Also, it could be that the particular person you were talking to did not have access to the buildd host in question; it doesn't necessarily mean only Stephen had access. As a recent example, to fix the XFree86 -11 mess, Adam Conrad and (to a lesser extent) I logged in to most buildd hosts and fixed the chroots; after we were done, there were only two of them left to go, IIRC. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 21, 2005 at 11:23:05PM +0100, Tollef Fog Heen wrote: * Wouter Verhelst | Because it's cool. In both senses of the word (have you ever had to | measure the temperature of an i386 box?) (amd64, but I guess the point still applies): Not exactly, as I assume the amd64 designers took more care about heat and cooling than the (original) i386 designers did. But yeah, I didn't expect this. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
* Sven Luther | And what is the size of the fan, and how much noise does it generate ? My home box is a 92mm which generates 20dB. The other one I'm not sure about, but probably a noisy 60mm (since it's in a server room and I don't care about noise there). -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to show $arch releaseability (was: Re: How to define a release architecture)
On Tue, 22 Mar 2005 14:15:13 +0100, Wouter Verhelst [EMAIL PROTECTED] wrote: [snip] Except that arm doesn't *have* a large number of slow autobuilders, working in parallel. They have four, and are having problems keeping up right now. Precisely. And four is already pushing the point of diminishing returns, unless you have a good mechanism for enforcing rules like builds against existing packages derived from gnome-vfs2 will be no good; don't schedule uim until libpanel-applet2-dev, etc. have actually made it into unstable where buildds can get at them. Otherwise you get this kind of race condition. Maybe someone already experienced in wanna-build hacking could implement a sort of write barrier field in changelog entries, perhaps as urgency: flush. This would force all packages that build-depend on foo-dev (built from foo) to wait until foo/foo-dev makes it to unstable for $arch before they can be scheduled on an $arch buildd. It would also notify appropriate humans that everything that build-depends on foo-dev needs to be rebuilt, and facilitate scheduling of these builds ahead of their reverse build dependencies. And so forth. This would help reduce pointless FTBFS like this uim run. But the bottom line is that some rebuild sequences are intrinsically sequential, and late in a release cycle is when they hit the hardest, because issues like the howl license finally get forced. Cheers, 0 Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to show $arch releaseability
On Tue, 22 Mar 2005 14:07:32 +0100, Simon Richter [EMAIL PROTECTED] wrote: That sounds more like a case of too-loose build-dependencies to me rather than architecture specific problems. This can also hit i386, the fact that it hit ARM this time is sheer coincidence. Should the uim maintainer have to add versioned build-depends because gnome-vfs2 had to drop howl support? Without good tracking tools, that's tough. Something like the urgency: flush mechanism would be better. i386 doesn't get hit by it often because most people upload i386 binaries and the wanna-build queue is almost always empty. Race conditions are exposed by parallel architectures. Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
More DDTP problems
The questions below were posted at long time in the DDTP-Coors list, but weren't replied :((( IMHO the ddts code needs a revision to correct bugs, I am wrong? This revision is possible? I can help. # Hi, there are questions made by me at long time but there are no answers :(. Could anybody replies? --- 1 I don't understand what's hapenning with the pt_BR description of the package apache2-mpm-prefork. The status of translation is: packageapache2-mpm-prefork md5sum affbcce10589b4575143937c01409d80 packageapache2-mpm-prefork translator reviewer 0 reviewer 1 reviewer 2 reviewed 000 But if I send an email with the SUBJECT GET apache2-mpm-prefork pt_BR, the server replies: # package has already been sent to another translator, # in case you want to review it, please send a mail to the server # with subject: REVIEW apache2-mpm-prefork And, if I send an email with the SUBJECT REVIEW apache2-mpm-prefork pt_BR, the server replies: ERROR: requested package (apache2-mpm-prefork) is not translated review apache2-mpm-prefork pt_BR Know anybody what is the problem and how to resolve? --- 2 there is some way to remove a reviwer from a description? I sent an email to ddts with the command: change data md5sum reviewer 0 I tried too: change data md5sum reviewer 0 '' but didn't work :( --- 3 I don't understand the informations below: list data ef398adbb0c8fcc3f4c7848adcd3768a md5sum ef398adbb0c8fcc3f4c7848adcd3768a package bugs 63358 translator [EMAIL PROTECTED] reviewer 0 Luis Flavio Rocha [EMAIL PROTECTED] reviewer 1 Krishnamurti Lelis Lima Vieira Nunes [EMAIL PROTECTED] reviewer 2 Tiago Saboga [EMAIL PROTECTED] reviewed 011 Description: The GNU Bourne Again SHell Bash is an sh-compatible command language interpreter that executes commands read from the standard input or from a file. Bash also incorporates useful features from the Korn and C shells (ksh and csh). . Bash is ultimately intended to be a conformant implementation of the IEEE Posix Shell and Tools specification (IEEE Working Group 1003.2). Description-pt_BR: ... data c53ad38dbe57dadfc23150b4f7af0260 md5sum c53ad38dbe57dadfc23150b4f7af0260 packagebash translator [EMAIL PROTECTED] reviewer 0 [EMAIL PROTECTED] reviewer 1 Regis Fernandes Gontijo [EMAIL PROTECTED] reviewer 2 Fabio Brito [EMAIL PROTECTED] reviewed 001 Description: The GNU Bourne Again SHell Bash is an sh-compatible command language interpreter that executes commands read from the standard input or from a file. Bash also incorporates useful features from the Korn and C shells (ksh and csh). . Bash is ultimately intended to be a conformant implementation of the IEEE POSIX Shell and Tools specification (IEEE Working Group 1003.2). . Included in the bash package is the Programmable Completion Code, by Ian Macdonald. . Statically linked. Description-pt_BR: ... data 52dfe58c1d37394e71d1196084683052 md5sum 52dfe58c1d37394e71d1196084683052 package bugs 63025 63354 translator [EMAIL PROTECTED] reviewer 0 Luis Flavio Rocha [EMAIL PROTECTED] reviewer 1 Krishnamurti Lelis Lima Vieira Nunes [EMAIL PROTECTED] reviewer 2 Tiago Saboga [EMAIL PROTECTED] reviewed 001 Description: The GNU stdc++ library NOTE: This is not a final release, but taken from the CVS gcc-2_95-branch (dated 20010522). . This package contains an additional runtime library for C++ programs built with the GNU compiler. Description-pt_BR: ... data 2c261c1ebc9164110dfa1e231f40 md5sum 2c261c1ebc9164110dfa1e231f40 packagelibstdc++2.10-glibc2.2 bugs 63370 translator [EMAIL PROTECTED] reviewer 0 Luis Flavio Rocha [EMAIL PROTECTED] reviewer 1 Krishnamurti L. L. V. Nunes [EMAIL PROTECTED] reviewer 2 Tiago Saboga [EMAIL PROTECTED] reviewed 001 Description: The GNU stdc++ library NOTE: This is not a final release, but taken from the CVS gcc-2_95-branch (dated 2001-10-02). . This package contains an additional runtime library for C++ programs built with the GNU compiler. Description-pt_BR: ... data 33bee2a0f243491d5637625cbf72fcfe md5sum 33bee2a0f243491d5637625cbf72fcfe package bugs 62885 62892 translator [EMAIL PROTECTED] reviewer 0 Luis Flavio Rocha [EMAIL PROTECTED] reviewer 1 Krishnamurti L. L. V. Nunes [EMAIL PROTECTED] reviewer 2 Tiago Saboga [EMAIL PROTECTED] reviewed 010 Description: Kernel logging daemon The klogd daemon listens to kernel message sources and is responsible for prioritizing and processing operating system messages. The klogd daemon can run as a client of syslogd or optionally as a standalone program. Klogd can now be used to decode EIP addresses if it can
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 21, 2005 at 06:50:22PM -0800, Steve Langasek wrote: ... The top three things I've spent release management time on that I shouldn't have had to are, in no discernable order: 1) processing new RC bug reports to set sarge/sid tags appropriately, so that the RC bug list for sarge bears some resemblance to reality 2) prodding maintainers to get all packages associated with library soname transitions synchronized so that they can progress into testing together (seems to require an average of 2-3 iterations, and 3-4 weeks) 3) chasing down, or just waiting on (which means, taking time to poll the package's status to find out why a bug tagged 'testing' is still open), missing builds or fixes for build failures on individual architectures that are blocking RC bugfixes from reaching testing Taken together, these probably account for more of my release management time than anything else, including actual work on release-critical bugs. ... Is it correct that none of these three points that account for most of your release management time would exist in a release process without testing? Steve Langasek cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to define a release architecture
On Tue, Mar 22, 2005 at 05:31:58AM -0800, Steve Langasek wrote: On Tue, Mar 22, 2005 at 01:13:15PM +0100, Wouter Verhelst wrote: On Tue, Mar 22, 2005 at 01:11:32AM -0800, Steve Langasek wrote: You didn't answer the question I asked. Do you believe that DSA should be spending its limited resources keeping hardware running for dead architectures? No. They never did, and they never should. The fact that some people are involved with both DSA and buildd maintenance doesn't mean DSA, as a group, has anything to do with buildd maintenance. - the Debian System Administrators (DSA) must be willing to support debian.org machine(s) of that architecture - there must be a developer-accessible debian.org machine for the architecture. Who maintains crest.debian.org? Uh, sorry, I was confused there; I thought you were only talking about maintaining buildd machines for architectures. In any case, the burden to maintain one (or two) hosts as general developer-accessible machines is far lighter than to impede DSA with having to maintain all buildd hosts... -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to show $arch releaseability (was: Re: How to define a release architecture)
On Tue, Mar 22, 2005 at 01:51:57PM +, Michael K. Edwards wrote: On Tue, 22 Mar 2005 14:15:13 +0100, Wouter Verhelst [EMAIL PROTECTED] wrote: [snip] Except that arm doesn't *have* a large number of slow autobuilders, working in parallel. They have four, and are having problems keeping up right now. Precisely. And four is already pushing the point of diminishing returns, unless you have a good mechanism for enforcing rules like builds against existing packages derived from gnome-vfs2 will be no good; don't schedule uim until libpanel-applet2-dev, etc. have actually made it into unstable where buildds can get at them. Versioned build-dependencies. the 'dep-wait' state in wanna-build. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
On Tue, Mar 22, 2005 at 09:06:19AM -0300, Humberto Massa wrote: And I believe that the Vancouver proposal, if implemented as intended up to now, will not only affect what Debian really *is*, but in some ways will *destroy* what Debian is. Debian has already decided to destroy what it is by giving in to the crackpots who insist that everything is software. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new arch support proposal, hopefully consensual (?)
On Sun, Mar 20, 2005 at 08:48:45PM +0100, Julien BLACHE wrote: Raphael Hertzog [EMAIL PROTECTED] wrote: I believe everyone is supportive of the various ports, nobody has any interest in making a port fail... but it's clear that many maintainers are frustrated to be blocked because their package doesn't build on an arch they don't care about. They should care about every architecture we support. Because our architecture coverage is an important part of the spirit of this Project, and an important feature. I've been thinking about your post for a couple of days. I think that for some people, multi-platform support is important but everyone has different reasons for being involved and different opinions on what is important. Our users and developers might want a distribution which 1. Runs on every platform; OR 2. Is 100% free, but only needs to run on their mainstream desktop; OR 3. Is technically the best at any cost; OR 4. Suitable for production use on modern hardware; OR some combination of these etc. It's unfair to expect everyone to share your goals and in particular your desire to port to any particular platform. None of these goals is more correct than the others, though you might say that currently #1 is dominating #4 because it's slowing down the release of sarge. Debian wasn't originally multi-platform. The second platform was m68k, added in 2.0. The original Debian manifesto talks about building a technically excellent product and building a community to develop a distribution together. So please don't expect that everyone shares your interests. ( http://www.debian.org/doc/manuals/project-history/ap-manifesto.en.html ) In my reading, the proposal says that the release, ftp and post-release teams don't have the resources to concentrate on every platform, so if you want to see it maintained and released, you have to help. As has been noted already, having a 18-24 months release cycle isn't much of a problem; actually, enterprise users pretty much like that, although 12 months is a more generally acceptable timeframe. Right, but we're at 32 months now and counting. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: my thoughts on the Vancouver Prospectus
On Tue, Mar 22, 2005 at 12:55:16AM -0800, Steve Langasek wrote: On Mon, Mar 21, 2005 at 08:08:57PM +0100, Wouter Verhelst wrote: On Fri, Mar 18, 2005 at 06:44:46PM -0800, Steve Langasek wrote: - Architectures which need more than 2 buildds to keep up with package uploads on an ongoing basis are very slow indeed; while slower, low-powered chips are indeed useful in certain applications, they are a) unlikely to be able to usefully run much of the software we currently expect our ports to build, Please leave it to our users to define what is useful. Does this mean build it all and let the users decide for themselves what they want to use? That's our current approach, yes. Or does it mean ask the users before getting rid of packages that aren't used on the architectures? Of all the other alternatives that have been proposed, I would think this is the only valid one. It's hard to do that correctly, though, because you can't be sure that you've contacted even a majority of users. If the former, that doesn't seem to leave much room for ever improving the return porters to embedded/slow systems will ever get on their buildd investment, does it? I don't see why not. and b) definitely too slow in terms of single-package build times to avoid inevitably delaying high-priority package fixes for RC bugs. I would not have any problem with multi-staged security announcements, for example. Well, I guess just as I can't speak on behalf of all users and say they won't use KDE on m68k, you can't speak on behalf of them and say they're ok with having delayed security support for m68k. :) Good point. However, what I meant to say is that the multi-staged security announcements could be an option for the security team in case a build really takes an awful lot of time, such as in the KDE case, when this isn't wanted (if there is no embargo set, or the embargo time is about to pass). They'd be the exception; and in fact, this has happened before, f.e. with the kernel builds, or with some other huge package that was being delayed. For regular, short-timed builds, multi-staged security announcements wouldn't be required, and thus, they wouldn't be wanted. The security team seems historically unconvinced that staggered security announcements are worthwhile -- at least partly this is because staggered security announcements are more work, AIUI. In any case, you'd have to persuade them that this is a good idea before the release team could consider it. Okay, that makes sense. * Nobody has ever been offered to maintain a buildd host who was not at least in NM. I did train Matthias Ulrichs and Goswin von Brederlow when they were, but Goswin's machines were disconnected from w-b even before he was rejected. It was getting late when I wrote that, apparently. Goswin's machines weren't even ever connected to w-b; what happened is that I discontinued the manual support I had been putting in even before he was rejected. I'm also quite sure today I won't do that again, precisely because Goswin was rejected and I don't want to think of what might've happened had he been able to upload trojanized binaries (not that I think he would have done so). I'm interested in what your base for the above assertion is. Merely a misunderstanding about the current state of affairs with the m68k port, it seems. Certainly with all the fuss Ingo has made over this issue in the past, I had the impression that it was actually a current issue -- not a hypothetical. Yes, Ingo's deliberate confusion hasn't really helped us a lot either. Whether or not these particular individuals should be trusted, the truth is that when you have to have 10 buildds running to keep up with unstable, it's very difficult to get a big-picture view of the security of your binary uploads. Security is only as strong as the weakest link. True; but these concerns can be better addressed by spelling out some security requirements (and somehow ensuring they are being followed) rather than imposing some random, unrelated, limit to the number of hosts in use. FSVO better; having explicit security standards is good, but increasing the number of people (and machines) involved still increases the chances that somewhere, they will fail to be met. Well; this may be just me, but I have the feeling that using no more than X hosts as a security precaution is based on we don't have enough time, so let's do this the easy way. Having explicit security standards is a precondition to running a safe network. If you have a safe network, then the number of hosts shouldn't matter. Of course, the fact that Debian's network is widespread over the globe doesn't really help, but trying to remedy that by reducing the number of hosts smells like chickening out on what the real issues are, to me. In any case, it isn't really a good measure -- the end
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
I don't know why you're asking me; I've already said that I would consider this configuration acceptable for a release architecture, but that I wouldn't recommend it to the Sparc porters. What do you mean wouldn't recommend it to the sparc porters? And what does your recommendation count for anyway? -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
* Matthew Wilcox [EMAIL PROTECTED] [050322 16:51]: Debian has already decided to destroy what it is by giving in to the crackpots who insist that everything is software. You mean some people failed to destroy Debian though loudly and very often repeating the claim that some types of software do not count as software? Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
blog location changed (who can change it on planet.d.o?)
Hi all, As you can read[1] I changed my blog. But I don't remember who can change the RSS feed on planet.d.o. The new blog is here: http://www.edev.be.blog/ Thanks to Cc me, I'm not subscribed on [EMAIL PROTECTED] [1] http://www.edev.be/blog/index.php/archives/2005/02/07/new-blog-definitive-location/ -- .''`. : :' :rnaud `. `' `- Java Trap: http://www.gnu.org/philosophy/java-trap.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: blog location changed (who can change it on planet.d.o?)
On Tuesday, 22 de March de 2005 15:15, Arnaud Vandyck wrote: Hi all, As you can read[1] I changed my blog. But I don't remember who can change the RSS feed on planet.d.o. The new blog is here: http://www.edev.be.blog/ Hi Arnaud, you should be able to do it yourself, just read: [EMAIL PROTECTED]:/org/planet.debian.org$ less README Best regards -- Isaac Clerencia at Warp Networks, http://www.warp.es Work: [EMAIL PROTECTED] | Debian: [EMAIL PROTECTED] pgpx221WlVpZQ.pgp Description: PGP signature
Re: blog location changed (who can change it on planet.d.o?)
* Arnaud Vandyck ([EMAIL PROTECTED]) [050322 18:20]: As you can read[1] I changed my blog. But I don't remember who can change the RSS feed on planet.d.o. Any DD can. Log into gluck, and take a look at /org/planet.debian.org/README Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, 22 Mar 2005 12:14:17 +0100, Adrian Bunk [EMAIL PROTECTED] wrote: On Mon, Mar 21, 2005 at 06:50:22PM -0800, Steve Langasek wrote: ... The top three things I've spent release management time on that I shouldn't have had to are, in no discernable order: 1) processing new RC bug reports to set sarge/sid tags appropriately, so that the RC bug list for sarge bears some resemblance to reality To the extent that maintainers accept upstream's crack-of-the-day into sid, relying on a not-for-sarge mechanism instead of letting the bugs pile up upstream, the testing scripts do worsen the traffic late in the release cycle. Beats binge-purge, if you ask me, but YMMV. During a freeze-by-whatever-mechanism, becoming informed about whether allowing a given update would improve or worsen the situation takes effort; sarge/sid tags are part of that analysis. I think Steve is mostly saying that scrubbing the raw bug report data by disambiguating sarge and sid bugs shouldn't be the release manager's job. 2) prodding maintainers to get all packages associated with library soname transitions synchronized so that they can progress into testing together (seems to require an average of 2-3 iterations, and 3-4 weeks) Yep, this is a lot of work. The alternatives are unbuildable packages (left behind by a transition) or multiple versions of core libraries. The relevant packaging teams are getting the hang of it, though, and testing is a good tool for measuring progress towards an engineered release. Again, I think Steve wants this to be more of a maintainer/porter responsibility during more of the cycle. 3) chasing down, or just waiting on (which means, taking time to poll the package's status to find out why a bug tagged 'testing' is still open), missing builds or fixes for build failures on individual architectures that are blocking RC bugfixes from reaching testing Comments elsewhere; but I certainly don't think this is caused by testing. Don't shoot the messenger. Taken together, these probably account for more of my release management time than anything else, including actual work on release-critical bugs. Well, if it were efficient for the RM to be doing bug fixes himself, something would be broken. :-) Is it correct that none of these three points that account for most of your release management time would exist in a release process without testing? Doubtless the timing patterns would be different; but if you want sarge not to suck, it has to follow a meaningful bug metric down to (near) zero, contain a choreographed release of libraries and desktop integration, and the polish that comes from fixing bugs all the way instead of ignoring corner cases. None of these challenges is unique to a testing-mediated release process. Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 21, 2005 at 07:55:18AM +0100, Sven Luther wrote: snip very long and excellent explanation having a common kernel package will greatly simplify the parts of this process which involve the kernel-team, and let you just do the security fix, build and upload (either auto-built or hand-built), and then pass the baby to the debian-boot people to handle as usual. Hope this clarifies things a bit. Thanks Sven, it certaintly does. It's much appreciated. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: my thoughts on the Vancouver Prospectus
Wouter Verhelst [EMAIL PROTECTED] writes: [snip] A buildd host does not need much to work safely, so writing a security standard should be possible. How about a security standard like the following: * A buildd host must not have any port open, except for one SSH port (preferably port 22, but may be nonstandard). * It must run OpenSSH of at least version version without security issues in stable or version without security issues in unstable * It must run a kernel from the list of list of kernel packages in all distributions that are safe * It must not have PermitRootLogin enabled * It must not have PasswordAuthentication enabled * It must not have any tunneling enabled, except for scp * It must not have any enabled accounts except for root and the admin user(s) * ... possibly something more? Then DSA could set up a cronjob that would run every x days, check whether the requirements are being met, and would scream like hell if one of the hosts was insecure? Even better - use cfengine to automagically check that the config files were accurate. Plus, it would make a good example cfengine file for the documentation package. cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: How to show $arch releaseability
i386 doesn't get hit by it often because most people upload i386 binaries and the wanna-build queue is almost always empty. Race conditions are exposed by parallel architectures. Why can't we rebuild all packages even on i386 ? It would help the buildd system by adding manpower from i386 porters. And it would help to test compilation chain and packages itself. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new arch support proposal, hopefully consensual (?)
Hamish Moffatt [EMAIL PROTECTED] wrote: Our users and developers might want a distribution which 1. Runs on every platform; OR 2. Is 100% free, but only needs to run on their mainstream desktop; OR 3. Is technically the best at any cost; OR 4. Suitable for production use on modern hardware; OR some combination of these etc. So, because a part of the developers aren't interested in supporting multiple architectures, we should just throw away 2/3 of the architectures we support ? (I'm not counting the developers who do not care, as they do not care) Tell you what, there are millions of people using Windows; why do we bother developing Linux ? Same reasoning. In my reading, the proposal says that the release, ftp and post-release teams don't have the resources to concentrate on every platform, so if you want to see it maintained and released, you have to help. Which is what I'm doing, although I've been short on time these days (partly because I'm working on other projects involving Debian, should I add). As has been noted already, having a 18-24 months release cycle isn't much of a problem; actually, enterprise users pretty much like that, although 12 months is a more generally acceptable timeframe. Right, but we're at 32 months now and counting. Remember the compromise in november 2003, and don't forget to count the 6 months it took to implement testing-security, thanks. We have a clear problem with developing our infrastructure, and we should take care of it, instead of dropping architectures. But I'll soon post about that (on -project, the mail still needs to get written, might take a day or two). JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
HOWTO Help (was: Debian DPL Debate Comments)
cc-ing to -doc, since most part of the mail is more relevant there Hi! * Nico Golde [EMAIL PROTECTED] [050318 18:59]: [...] I've been thinking of contributing to Debian for a long time since I started using it. The problem is that I've not been able to find a good comprehensive documentation on Contributing to Debian yet. I think the descrition on: http://www.debian.org/support is ok. Nico, did you take a look at that page? It is more a Where to get support than a howto support us. AFAIK we don't have a good What you can do to help us documentation (please correct me, if I am wrong). However I was about to write a new document about that, based on the talk I did on the asian miniconf (which I btw, just uploaded to http://www.schmehl.info/publication/talks/200503_admc_howto_help/, not yet fixed the bugs or made a nice frontpage). If you have further Ideas for content, please drop me a mail. Yours sincerely, Alexander -- http://learn.to/quote/ http://www.catb.org/~esr/faqs/smart-questions.html signature.asc Description: Digital signature
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
Le mardi 22 mars 2005 à 17:46 +0100, Bernhard R. Link a écrit : * Matthew Wilcox [EMAIL PROTECTED] [050322 16:51]: Debian has already decided to destroy what it is by giving in to the crackpots who insist that everything is software. You mean some people failed to destroy Debian though loudly and very often repeating the claim that some types of software do not count as software? Why should people always be so counterproductive ? I'm also not satisfied with the non-productiveness of the removal of useful documentation. I'm also ashamed that some hardware doesn't work out of the box on Debian because we decided that firmware are software and thus should meet DFSG. However I don't plan to leave Debian because it's just not the right thing to do. I joined Debian because its goal was to satisfy its users... and sadly it turns that some developers forget about that when prefering freeness over the service to our users. We need to have a big political shift on that side, or we'll loose more valuable contributors in favor of other distributions... you may not care but I want Debian to stay the central distribution and I don't want that other distributions do a better service to users than us. Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com Earn money with free software: http://www.geniustrader.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Documentation is/is not software [was: NEW handling: About rejects, and kernels]
On Tue, Mar 22, 2005 at 12:32:30PM +, Matthew Wilcox wrote: On Tue, Mar 22, 2005 at 09:06:19AM -0300, Humberto Massa wrote: And I believe that the Vancouver proposal, if implemented as intended up to now, will not only affect what Debian really *is*, but in some ways will *destroy* what Debian is. Debian has already decided to destroy what it is by giving in to the crackpots who insist that everything is software. Way to set the tone for a productive debate. At any rate, the problem with trying to treat different types of bitstreams differently is to classify them, and identify a different set of freedoms which are appropriate -- and, more pretinently, why those different set of freedoms is important. The crackpots won more or less by default, because nobody was able to come up with either of these two pre-requisites. This suggests to me that either (a) it can't actually be done, in which case the crackpots are, after all, right; or (b) Debian is so filled with crackpots that there is nobody who actually wants to see documentation treated differently to executable programs. I used to sit in the documentation requires different freedoms camp, but eventually just couldn't support my feelings with logical argument. But there are significantly more powerful minds than mine out there; I look forward to hearing their arguments in favour of different freedoms for documentation. If someone can come up with a bright-line test for differentiating executable materials and documentation, or executable materials and say firmware, and can produce a DFDocumentationG or DFFirmwareG with effective reasoning, I will be most impressed, and will most likely support their position. Until then, however, I am firmly in the all things we ship are software, and the DFSG applies to all of that camp. - Matt crackpot and proud signature.asc Description: Digital signature
Re: HOWTO Help (was: Debian DPL Debate Comments)
On Tuesday 22 March 2005 22:08, Alexander Schmehl wrote: cc-ing to -doc, since most part of the mail is more relevant there Hi! * Nico Golde [EMAIL PROTECTED] [050318 18:59]: [...] I've been thinking of contributing to Debian for a long time since I started using it. The problem is that I've not been able to find a good comprehensive documentation on Contributing to Debian yet. I think the descrition on: http://www.debian.org/support is ok. Nico, did you take a look at that page? It is more a Where to get support than a howto support us. AFAIK we don't have a good What you can do to help us documentation (please correct me, if I am wrong). How about http://www.debian.org/devel/join/ ? Which is linked from the main debian.org page (bottom left: Help Debian) However I was about to write a new document about that, based on the talk I did on the asian miniconf (which I btw, just uploaded to http://www.schmehl.info/publication/talks/200503_admc_howto_help/, not yet fixed the bugs or made a nice frontpage). If you have further Ideas for content, please drop me a mail. Yours sincerely, Alexander pgpDOPfxiYzks.pgp Description: PGP signature
Quick attempt to fix it
tag 296917 +patch
thanks
Hi,
following the discussion about this bug on debian-devel, with some late,
I looked quickly in the code of the debhelper package, and I think I
could understand it very fast (proof that it is written in a very
maintainable way), so I tried to write this patch. I don't make much
Debian packaging yet, so I let others test it.
diff -ur debhelper-4.2.31/Debian/Debhelper/Dh_Getopt.pm
debhelper-4.2.31.new/Debian/Debhelper/Dh_Getopt.pm
--- debhelper-4.2.31/Debian/Debhelper/Dh_Getopt.pm 2004-06-29
01:59:57.0 +0200
+++ debhelper-4.2.31.new/Debian/Debhelper/Dh_Getopt.pm 2005-03-22
20:39:02.0 +0100
@@ -165,6 +165,10 @@
error-handler=s = \$options{ERROR_HANDLER},
= \NonOption,
+
+ move=s = \$options{MOVE},
+
+ hard-link=s = \$options{HARD_LINK},
);
if (!$ret) {
diff -ur debhelper-4.2.31/dh_install debhelper-4.2.31.new/dh_install
--- debhelper-4.2.31/dh_install 2004-01-16 04:47:14.0 +0100
+++ debhelper-4.2.31.new/dh_install 2005-03-22 23:01:22.200594648 +0100
@@ -12,7 +12,7 @@
=head1 SYNOPSIS
-Bdh_install [B-XIitem] [B--autodest] [B--sourcedir=Idir]
[SIdebhelper options] [SIfile [...] dest]
+Bdh_install [B-XIitem] [B--autodest] [B--sourcedir=Idir]
[B--move] [B--hard-link] [SIdebhelper options] [SIfile [...] dest]
=head1 DESCRIPTION
@@ -96,6 +96,17 @@
approximate dh_movefiles behaviour, except it will copy files instead
of moving them.
+=item B--move
+
+Moves the files instead of copying them. BCaution! It breaks idempotency!.
Ignored
+when B--hard-link is used
+
+=item B--hard-link
+
+Copies the files by creating hard links, to perform faster and save disk space.
+BCaution! Don't use it if you wan't to be able to modify the source files
+after having installed them.
+
=item Ifile [...] dest
Lists files (or directories) to install and where to install them to.
@@ -180,7 +191,15 @@
complex_doit(cd $src/.. find $dir_basename
$exclude \\( -type d -and -empty \\) -exec cp --parents -a {} $pwd/$tmp/$dest/
\\;);
}
else {
- doit(cp, -a, $src, $tmp/$dest/);
+ if ($dh{HARD_LINK}) {
+ doit(cp, -al, $src, $tmp/$dest/);
+ }
+ elsif ($dh{MOVE}) {
+ doit(mv, , $src, $tmp/$dest/);
+ }
+ else {
+ doit(cp, -a, $src, $tmp/$dest/);
+ }
}
if ($tmpdest) {
Quickly,
Nowhere man
--
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
On Tue, Mar 22, 2005 at 07:36:50PM +0100, Raphael Hertzog wrote: Le mardi 22 mars 2005 à 17:46 +0100, Bernhard R. Link a écrit : * Matthew Wilcox [EMAIL PROTECTED] [050322 16:51]: Debian has already decided to destroy what it is by giving in to the crackpots who insist that everything is software. You mean some people failed to destroy Debian though loudly and very often repeating the claim that some types of software do not count as software? Why should people always be so counterproductive ? I'm also not satisfied with the non-productiveness of the removal of useful documentation. I'm also ashamed that some hardware doesn't work out of the box on Debian because we decided that firmware are software and thus should meet DFSG. Notice that the plan is to have non-free drivers in non-free, as both .debs and .udebs, and thus users can just download them from there, and feed them to d-i through floppies or netbooting, and i guess some may even include them on custom cds with added non-free. Notice also, that technically such non-free modules can only be made once upstream has clarified the copyright on those files and clearly excluded the binary firmware blobs from the GPL coverage. Once that is done, it only constitutes mere aggregation and is thus distributable in non-free. This is why we voted to keep non-free back then, so let's make use of it for non-free stuff. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: blog location changed (who can change it on planet.d.o?)
Thanks ;-) Tue, 22 Mar 2005 18:31:18 +0100, Isaac Clerencia [EMAIL PROTECTED] wrote: On Tuesday, 22 de March de 2005 15:15, Arnaud Vandyck wrote: Hi all, As you can read[1] I changed my blog. But I don't remember who can change the RSS feed on planet.d.o. The new blog is here: http://www.edev.be.blog/ Hi Arnaud, you should be able to do it yourself, just read: [EMAIL PROTECTED]:/org/planet.debian.org$ less README Tue, 22 Mar 2005 18:33:06 +0100, Andreas Barth [EMAIL PROTECTED] wrote: * Arnaud Vandyck ([EMAIL PROTECTED]) [050322 18:20]: As you can read[1] I changed my blog. But I don't remember who can change the RSS feed on planet.d.o. Any DD can. Log into gluck, and take a look at /org/planet.debian.org/README -- .''`. : :' :rnaud `. `' `- Java Trap: http://www.gnu.org/philosophy/java-trap.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: *** SPAM *** Re: A new arch support proposal, hopefully consensual (?)
Sven Luther wrote: On Mon, Mar 21, 2005 at 04:31:44PM -0800, Mike Fedyk wrote: Sven Luther wrote: Ok, this is the easy part, and also what the vancouver-proposal included, the difference comes in how the minority-arches are handled, and my proposal is a 'including' proposal, while the vancouver-proposal was 'excluding'. 4) each non-tier1 arches will have its own testing infrastructure, which would take both unstable and testing in account. 5) packages are built out of unstable into an arch-specific unstable binary repository on a separate machine (altough many minority arches may share this infrastructure). This allows for source package version skew on a per arch level. In the worst case, each non-tier1 arch could have a different source package version when compared to tier1 and all of the other non-tier1 arches. To have the least possibility for source package version skew, the non-tier1 arches should branch off of tier1-testing instead of tier1-unstable. That was my first proposal, but i am not sure if it makes sense. The version skew may happen, but i feel it will be minimal. All these arches will build from unstable, the packages will go into arch-unstable instead of arch. Here we have our first chance of source skew : A) source skew due to the delay due to the build lag of the arches in question this will be limited to a couple of days in the best case, and to one version, and only for packages recently uploaded and not yet built. It is a function of the upload rate and time for build of the packages. The second version skew happens when there is a package in arch-unstable which has migrated to testing in the tier1 archive, but failed to do so in the arch-testing because of arch-specific breakage : B) source skew due to arch-specific RC bugs. This is also something transitory and easily quantifiable. Furthermore, since the waste majority of packages build correctly, it is also a rather small and Did you mean "vast"? something that is supposed to resorb itself, in particular since the fix will be uploaded to tier1-unstable too. On the contrary building from tier1-testing has the problem that an individual package or even arch fix may be withold from the tier2 arches for a longer period of time, as we have seen, and thus that the porting effort if needed may well start only later. So, after reflexion, i believe that the build-from-unstable, with per-arch-testing scripts slaved to the main testing for migration is a better solution than building-from-testing as i first proposed. I think I agree with you now. Also if the tier2 arches are branch off of testing, they will never be able to prove that they are able to keep up with sid. As long as tier2-testing does not migrate a package before tier1-testing does, then I have no arguments so far. Mike
Re: HOWTO Help (was: Debian DPL Debate Comments)
On Tue, Mar 22, 2005 at 10:25:51PM +0100, Frans Pop wrote: On Tuesday 22 March 2005 22:08, Alexander Schmehl wrote: (...) AFAIK we don't have a good What you can do to help us documentation (please correct me, if I am wrong). No, we don't have one. How about http://www.debian.org/devel/join/ ? Which is linked from the main debian.org page (bottom left: Help Debian) That is probably too terse. I think that Alexander is talking about an expanded document directed towards end users that would like a step-by-step guide of what can they do to help the Debian project. I would certainly find proper a good document on: - how to contribute help in fixing bugs - how to help in the different translation efforts - how to get involved with local Debian organisations in your country (listing those that do exist, like Debian UK or Debian Spain) etc.. However I was about to write a new document about that, based on the talk I did on the asian miniconf (which I btw, just uploaded to http://www.schmehl.info/publication/talks/200503_admc_howto_help/, not yet fixed the bugs or made a nice frontpage). If you have further Ideas for content, please drop me a mail. The document looks quite good. You should probably ask for help to the different teams (-www, -i18n, -l10n-XXX teams, -doc) on specific tasks that could be expanded on (contributing content to the web site, translating and writing documentation). Some information is already spelled out (both in the web pages and recurring posts to the mailing lists) but keeping them all together would be a Good Thing. Regards Javier signature.asc Description: Digital signature
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, Mar 22, 2005 at 02:55:17PM +, Michael K. Edwards wrote: On Tue, 22 Mar 2005 12:14:17 +0100, Adrian Bunk [EMAIL PROTECTED] wrote: On Mon, Mar 21, 2005 at 06:50:22PM -0800, Steve Langasek wrote: ... The top three things I've spent release management time on that I shouldn't have had to are, in no discernable order: 1) processing new RC bug reports to set sarge/sid tags appropriately, so that the RC bug list for sarge bears some resemblance to reality To the extent that maintainers accept upstream's crack-of-the-day into sid, relying on a not-for-sarge mechanism instead of letting the bugs pile up upstream, the testing scripts do worsen the traffic late in the release cycle. Beats binge-purge, if you ask me, but YMMV. During a freeze-by-whatever-mechanism, becoming informed about whether allowing a given update would improve or worsen the situation takes effort; sarge/sid tags are part of that analysis. I think Steve is mostly saying that scrubbing the raw bug report data by disambiguating sarge and sid bugs shouldn't be the release manager's job. Without testing, there was no need for anyone to do such a distinguishing before the freeze starts. And if you'd (in a relesase process without testing) freeze unstable for some time after the beginning of the freeze, you could get the point when frozen starts diverging from unstable even later. 2) prodding maintainers to get all packages associated with library soname transitions synchronized so that they can progress into testing together (seems to require an average of 2-3 iterations, and 3-4 weeks) Yep, this is a lot of work. The alternatives are unbuildable packages (left behind by a transition) or multiple versions of core libraries. The relevant packaging teams are getting the hang of it, though, and testing is a good tool for measuring progress towards an engineered release. Again, I think Steve wants this to be more of a maintainer/porter responsibility during more of the cycle. As I've already said in another email: Transitions of API-compatible libraries are a pain _only_ due to testing. In unstable, such a transition can easily be done within a few days. Remember the libtiff transition. Look at the various libexif transitions. ... The transition in unstable is trivial (changing the build dependencies in the packages). The complete transition into testing is a pain (in the libtiff case Steve cheated by introducing a second libtiff source package but it still took some time). 3) chasing down, or just waiting on (which means, taking time to poll the package's status to find out why a bug tagged 'testing' is still open), missing builds or fixes for build failures on individual architectures that are blocking RC bugfixes from reaching testing Comments elsewhere; but I certainly don't think this is caused by testing. Don't shoot the messenger. ... Steve's talking about bugs already fixed in unstable that might still be present in testing. Why do you think this wasn't caused by testing? Cheers, - Michael cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, Mar 22, 2005 at 12:14:17PM +0100, Adrian Bunk wrote: On Mon, Mar 21, 2005 at 06:50:22PM -0800, Steve Langasek wrote: ... The top three things I've spent release management time on that I shouldn't have had to are, in no discernable order: 1) processing new RC bug reports to set sarge/sid tags appropriately, so that the RC bug list for sarge bears some resemblance to reality 2) prodding maintainers to get all packages associated with library soname transitions synchronized so that they can progress into testing together (seems to require an average of 2-3 iterations, and 3-4 weeks) 3) chasing down, or just waiting on (which means, taking time to poll the package's status to find out why a bug tagged 'testing' is still open), missing builds or fixes for build failures on individual architectures that are blocking RC bugfixes from reaching testing Taken together, these probably account for more of my release management time than anything else, including actual work on release-critical bugs. ... Is it correct that none of these three points that account for most of your release management time would exist in a release process without testing? Misfiled bugs would be a problem in a freeze/unstable configuration, just as they are in a testing/unstable configuration. Getting binaries up-to-date across all architectures for RC bugfixes would be a problem in a frozen suite, just as it is in testing. Library soname transitions would be unlikely to happen in a freeze, but that just means any transitions that are in progress at the time all have to be dealt with *when* we freeze, even if they aren't necessary transitions. In any case, this overlooks one of the principal advantages of testing, which is that it avoids releasing software that's already 1 year out of date at the time of release. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Ubuntu Patches
Scripsit Matt Zimmerman [EMAIL PROTECTED] The problem is that you are both looking at the process in reverse. As I explained, Ubuntu imports a subset of bugs from the Debian bug tracking system, and those are the bugs which are relevant to the process I described. You make it sound like Unbutu's *only* source of knowledge about bugs is the Debian BTS. Do Unbutu's users never report bugs? Do their developers never find bugs themselves? Patches are always published regardless of how they came to be applied, or whether they correspond to a bug at all, via an automated process. This process does not open bugs in debbugs (for obvious reasons). I still don't see why it is obvious not to pass the fix upstream when one fixes a bug that upstream does not know about. -- Henning Makholm It's just as meaningful to say that our ancestors could easily have been very much like squirrels. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, Mar 22, 2005 at 03:20:04PM -0800, Steve Langasek wrote: On Tue, Mar 22, 2005 at 12:14:17PM +0100, Adrian Bunk wrote: On Mon, Mar 21, 2005 at 06:50:22PM -0800, Steve Langasek wrote: ... The top three things I've spent release management time on that I shouldn't have had to are, in no discernable order: 1) processing new RC bug reports to set sarge/sid tags appropriately, so that the RC bug list for sarge bears some resemblance to reality 2) prodding maintainers to get all packages associated with library soname transitions synchronized so that they can progress into testing together (seems to require an average of 2-3 iterations, and 3-4 weeks) 3) chasing down, or just waiting on (which means, taking time to poll the package's status to find out why a bug tagged 'testing' is still open), missing builds or fixes for build failures on individual architectures that are blocking RC bugfixes from reaching testing Taken together, these probably account for more of my release management time than anything else, including actual work on release-critical bugs. ... Is it correct that none of these three points that account for most of your release management time would exist in a release process without testing? Misfiled bugs would be a problem in a freeze/unstable configuration, just as they are in a testing/unstable configuration. In a freeze/unstable configuration, this starts after the freeze. (Or if you keep unstable frozen, even later.) And during a freeze, I wouldn't expect much activity in unstable, making the problem in the freeze/unstable configuration even smaller. In a testing/unstable configuration, this affects all bugs including bugs that were filed many months before the freeze. Getting binaries up-to-date across all architectures for RC bugfixes would be a problem in a frozen suite, just as it is in testing. But even if the autobuilders of an architecture have a problem with keeping up with unstable, they are much more likely being able to keep up with frozen since the amount of changes is much smaller. And it wasn't a problem if there was no autobuilder for an architecture for two weeks during a non-freeze time. Library soname transitions would be unlikely to happen in a freeze, but that just means any transitions that are in progress at the time all have to be dealt with *when* we freeze, even if they aren't necessary transitions. Transitions in unstable are easy. The problem is usually only getting a transition into testing. Assuming a freeze is announced early enough, it shouldn't be a big deal ensuring that all transitions are completed before the freeze in a freeze/unstable configuration. In any case, this overlooks one of the principal advantages of testing, which is that it avoids releasing software that's already 1 year out of date at the time of release. This was a goal of testing. The woody freeze took 7 months. Depending on how you count, the current freeze of sarge started more than one and a half years ago, or it started only seven and a half months ago - and sarge still isn't released. As things are today, sarge will release with an X11 being more than two years old. This is the second release with the testing release process, and the assumed advantages of testing still aren't visible through shorter release cycles. You yourself signed that statement that the testing release process is not capable of a release cycle on the order of 12-18 months with 11 architectures. And now two thirds of the Debian architectures should be removed from Debian releases because you still prefer a release process that has twice failed to show that it was superior to the former release process? Steve Langasek cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Vancouver meeting - clarifications
Scribit Bas Zoetekouw dies 15/03/2005 hora 10:37: I find it a bit hard to believe that Debian isn't able to support 11 architectures while for example FreeBSD and NetBSD seem to manage fine. - FreeBSD: 6 ports, 12646 packages - Debian: 11 ports, 9157 packages (sarge) [17593 in sid] - NetBSD: 55 ports, 5300 packages I think that Debian stands quite well the comparison... And maybe SCC will enable Debian to ``support'' many more architectures, and in a smooth way, instead of a somewhat all-or-nothing. Numerically, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
discrepancies between uploaded and source-built .deb
Hi, I'm doing something that involves building every Debian package, and I'm finding (usually minor) discrepancies between what I build from source packages, and the binary packages uploaded by maintainers. I'm building each package in its own chroot which contains only the minimum packages (bootstrap + build-essential + build-dependencies). Are such things considered bugs? Also, what is the policy on the relationship between source packages and binary packages. May two source package both produce the same binary package? -- Karl 2005-03-22 18:24 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300986: ITP: libfax-hylafax-client-perl -- Fax::Hylafax::Client from CPAN - Perl client for HylaFAX fax server
Package: wnpp Severity: wishlist Owner: Ivan Kohler [EMAIL PROTECTED] * Package name: libfax-hylafax-client-perl Version : 1.01 Upstream Author : Alex Rak [EMAIL PROTECTED] * URL : http://search.cpan.org/dist/Fax-Hylafax-Client/ * License : Perl Description : Fax::Hylafax::Client from CPAN - Perl client for HylaFAX fax server This is a simple Perl client for HylaFAX fax server (www.hylafax.org). It communicates with the server directly through FTP protocol and thus does not require any HylaFAX software components to be installed on the client machine. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.27-2-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discrepancies between uploaded and source-built .deb
On Tue, Mar 22, 2005 at 06:34:58PM -0800, Karl Chen wrote: Hi, I'm doing something that involves building every Debian package, and I'm finding (usually minor) discrepancies between what I build from source packages, and the binary packages uploaded by maintainers. I'm building each package in its own chroot which contains only the minimum packages (bootstrap + build-essential + build-dependencies). Are such things considered bugs? A bit of this is ineviteable because of slight differences in host system (builds to add hostname you compiled on to version strings, for example), or time of build (timestamps), but most importantly, different versions of build-dependencies. The environment changes, so does the build. Usually, this doesn't give a significant difference, and certainly not a regression. If there is a real regression, or a significant change, yeah, that might (might!) be a bug. A build of a package needs to be reasonably reproducieable after all. If there is no noticeable change though, it's certainly not a bug. Bottom line is that a difference is not a bug per se, but it may be an indication of a bug. Also, what is the policy on the relationship between source packages and binary packages. May two source package both produce the same binary package? In transitional situations this happens for a while, this should however not persist. The package producing the lower version cannot be updated easily, as the archive tools would reject an upload where still the package in question is of lower version number than the one built by the other source package. I think it'd be good to ship sarge without such situations, but again, this needs to be looked into on a case-by-case basis, and I certainly dare not say that every such case must be a bug (but I suspect so in general). Note that for this issue, one of the Debian FTP scripts (rene) actually checks for this situation, and I plan to file bugs based on that test real soon now. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emulated buildds (for SCC architectures)?
Hi Gunnar, On Fri, Mar 18, 2005 at 08:06:47PM -0600, Gunnar Wolf wrote: And I am sure we can find more examples like these - I have not really checked, but I would be surprised if architectures as popular as Sparc, Alpha or ARM wouldn't have an emulator (although probably not currently as reliable as those two). Now, if we face dropping one or more of our architectures (i.e. m68k) because new hardware can not be found anymore (the Vancouver proposal mentions that the release architecture must be publicly available to buy new in order to keep it as a fully supported architecture - I know, SCC != fully supported, but anyway, a buildd can die and create huge problems to a port), why shouldn't we start accepting buildds running under emulated machines? I quite agree with Anthony that if we have to emulate the machine, there's not much sense in supporting it. I do know, from first-hand experience trying to get ssh running on a Cobalt, that compilation speed is not always correlated with the usefulness of a system; so I'm not completely opposed to using distcc (in moderation!) for release architectures, but I would still first like to see some serious discussion about why it's useful to build all the software we do for all the architectures before agreeing that such a distcc network is warranted. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bug#299771: ITP: ttf-antp -- Antykwa Poltawskiego font family
Miros/law Baran [EMAIL PROTECTED] writes: The font is included in the tetex-base package, along with other Type1 GUST-sponsored fonts (Antykwa Toruska etc.) - I think such a package will be redundant. Somebody shouldn't have to install tetex (tetex-base alone is 81MB) to get a ttf font! Perhaps if there are actual duplicated files, there should be a common package or something, but the ability to install the font standalone seems quite valuable. -Miles -- Next to fried food, the South has suffered most from oratory. -- Walter Hines Page
Re: A new arch support proposal, hopefully consensual (?)
On Mon, Mar 21, 2005 at 12:26:13AM -0800, [EMAIL PROTECTED] wrote: It's not so fair to perpetrate a straw man attack against Sven's whole proposal just because he can't spell perfectly. Give the man credit where it's due for trying to better Debian. This is stupid. The very phrasing was lightly humerous, not an attack. (I don't know why I'm replying seriously to a nameless top-poster with an email address [EMAIL PROTECTED], though. My bad. :) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emulated buildds (for SCC architectures)?
On Tue, Mar 22, 2005 at 08:58:41PM -0800, Steve Langasek wrote: Now, if we face dropping one or more of our architectures (i.e. m68k) because new hardware can not be found anymore (the Vancouver proposal mentions that the release architecture must be publicly available to buy new in order to keep it as a fully supported architecture - I *cough* You can still buy new Amigas. See http://www.vesalia.de/ for example. Of course, one can start new discussing what's actually is new? Those Amigas are new and unused and include warranty. know, SCC != fully supported, but anyway, a buildd can die and create huge problems to a port), why shouldn't we start accepting buildds running under emulated machines? I quite agree with Anthony that if we have to emulate the machine, there's not much sense in supporting it. Especially when certain things are essential for those archs, like gcc for embedded systems. I do know, from first-hand experience trying to get ssh running on a Cobalt, that compilation speed is not always correlated with the usefulness of a system; so I'm not completely opposed to using distcc (in moderation!) for release architectures, but I would still first like to see some serious discussion about why it's useful to build all the software we do for all the architectures before agreeing that such a distcc network is warranted. I doubt that m68k would gain much profit from using distcc. The preposessing still needs to be done on the m68k. Usually, m68ks only have 10 Mbps ethernet, which is often limited to 300-600 kB/s in real life usage. I don't have a proof, but I think for some NICs there's no DMA supported or so. So, with using distcc (over network) you might buy that remote compiling by raising the CPU load. Basically I agree, that not all packages need to be compiled natively on m68k and that some packages don't need to be considered as RC, such as KDE or other long building ones. For those packages a distcc approach might be useful. I would prefer a reduced release set of packages over even considering the drop of archs. Release a set of packages for basic and server tasks and let all desktop related stuff (X, KDE, Gnome) do their own subreleases on the base of the main (reduced set) release. That way, servers still could run stable for a long time (2 years release cycle f.e.) whereas Desktop users could use newer software for KDE/Gnome with maybe a 6 month release cycle for those subreleases. -- Ciao... // Ingo \X/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Quick attempt to fix it
hoi :)
On Tue, Mar 22, 2005 at 11:11:01PM +0100, Pierre THIERRY wrote:
+ elsif ($dh{MOVE}) {
+ doit(mv, , $src, $tmp/$dest/);
+ }
this doesn't look right.
I think you should drop the empty argument.
--
Martin Waitz
signature.asc
Description: Digital signature
Re: NEW handling: About rejects, and kernels
Petter Reinholdtsen wrote: Perhaps this could be solved with some kind of ticket system handling email to the official roles in debian? I'm not sure if BTS is the best option to handle emails to ftpmaster, leader and others. Perhaps request-tracker is a better option? We use it at work, and it seem to do request handling quite well (at least when we added the email administration interface. :). What's the problem with using ftp.debian.org pseudo-package? Regards, ogi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300993: ITP: nvu -- Nvu is a complete Web Authoring System based on the Mozilla Composer engine
Package: wnpp Severity: wishlist Owner: Nick Price [EMAIL PROTECTED] * Package name: nvu Version : 0.90 Upstream Author : Linspire, Inc. [EMAIL PROTECTED] * URL : http://www.nvu.com/ * License : MPL/LGPL/GPL tri-license Description : Nvu is a complete Web Authoring System based on the Mozilla Composer engine Nvu (pronounced N-view, for a new view) is an Open Source project started by Linspire, Inc. Linspire is committed exclusively to bringing Desktop Linux to the masses, and realized that an easy-to-use web authoring system was needed for Linux to continue its expansion to the Desktop. Linspire contributes significant capital, expertise, servers, bandwidth, marketing, and other resources to guarantee the continuation and success of the Nvu project. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted evolution2.2 2.1.6-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Mar 2005 15:39:39 +0900 Source: evolution2.2 Binary: evolution2.2-dev evolution2.2 Architecture: source i386 Version: 2.1.6-1 Distribution: experimental Urgency: low Maintainer: Takuo KITAME [EMAIL PROTECTED] Changed-By: Takuo KITAME [EMAIL PROTECTED] Description: evolution2.2 - The groupware suite evolution2.2-dev - Development library files for Evolution (unstable) Changes: evolution2.2 (2.1.6-1) experimental; urgency=low . * New upstream release Files: e333b22dc1229bde3547dc537ac9cf0b 1064 gnome optional evolution2.2_2.1.6-1.dsc 7a9daaa95b80d4754474db67f568f9b6 18309323 gnome optional evolution2.2_2.1.6.orig.tar.gz e92e16c5a39193666c058269a7d732a3 439822 gnome optional evolution2.2_2.1.6-1.diff.gz 7e811eed7a18c903964b9712831c4db8 8672050 gnome optional evolution2.2_2.1.6-1_i386.deb d8d0fdb38b5135d51bb71ad662a7944f 104948 devel optional evolution2.2-dev_2.1.6-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCP9JDU+WZW1FVMwoRAn9xAJ4mTgCZisksTQR8REpIe87lfPjj1gCeI3DL jBaJsFXB43dGV139mimv2wQ= =674i -END PGP SIGNATURE- Accepted: evolution2.2-dev_2.1.6-1_i386.deb to pool/main/e/evolution2.2/evolution2.2-dev_2.1.6-1_i386.deb evolution2.2_2.1.6-1.diff.gz to pool/main/e/evolution2.2/evolution2.2_2.1.6-1.diff.gz evolution2.2_2.1.6-1.dsc to pool/main/e/evolution2.2/evolution2.2_2.1.6-1.dsc evolution2.2_2.1.6-1_i386.deb to pool/main/e/evolution2.2/evolution2.2_2.1.6-1_i386.deb evolution2.2_2.1.6.orig.tar.gz to pool/main/e/evolution2.2/evolution2.2_2.1.6.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted apt 0.5.28.6 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Mar 2005 23:03:19 -0800 Source: apt Binary: apt-utils libapt-pkg-doc libapt-pkg-dev apt-doc apt Architecture: source all i386 Version: 0.5.28.6 Distribution: unstable Urgency: low Maintainer: APT Development Team [EMAIL PROTECTED] Changed-By: Matt Zimmerman [EMAIL PROTECTED] Description: apt- Advanced front-end for dpkg apt-doc- Documentation for APT apt-utils - APT utility programs libapt-pkg-dev - Development files for APT's libapt-pkg and libapt-inst libapt-pkg-doc - Documentation for APT development Changes: apt (0.5.28.6) unstable; urgency=low . * Merge [EMAIL PROTECTED]/apt--sarge--0 again (patch-36) Files: e8b537772542c03611b7f6928dfdb8a1 758 admin important apt_0.5.28.6.dsc 26b37525371cdaaec552237e0667305d 1379541 admin important apt_0.5.28.6.tar.gz 7d7e6bf843f075d77a1c1c6c841c0563 68952 doc optional apt-doc_0.5.28.6_all.deb b0147723156d4544feda74b5307cf005 101598 doc optional libapt-pkg-doc_0.5.28.6_all.deb ce8563844ee16e8367dc2991fbbefcf5 1193966 base important apt_0.5.28.6_i386.deb dcb25a8b980e4f637a1c8434ba731090 69494 libdevel optional libapt-pkg-dev_0.5.28.6_i386.deb c2f6ec6c04fd057845337b2fa13760be 183682 admin optional apt-utils_0.5.28.6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCP888ArxCt0PiXR4RAoMsAJ44t4C045/7J8rQ8HjhXbn0kvZBEwCg38Vs 2keDHMyBGKfh9juqtgo1j+w= =r3Lw -END PGP SIGNATURE- Accepted: apt-doc_0.5.28.6_all.deb to pool/main/a/apt/apt-doc_0.5.28.6_all.deb apt-utils_0.5.28.6_i386.deb to pool/main/a/apt/apt-utils_0.5.28.6_i386.deb apt_0.5.28.6.dsc to pool/main/a/apt/apt_0.5.28.6.dsc apt_0.5.28.6.tar.gz to pool/main/a/apt/apt_0.5.28.6.tar.gz apt_0.5.28.6_i386.deb to pool/main/a/apt/apt_0.5.28.6_i386.deb libapt-pkg-dev_0.5.28.6_i386.deb to pool/main/a/apt/libapt-pkg-dev_0.5.28.6_i386.deb libapt-pkg-doc_0.5.28.6_all.deb to pool/main/a/apt/libapt-pkg-doc_0.5.28.6_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ocaml 3.08.3-2 (powerpc all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Mar 2005 08:06:01 +0100 Source: ocaml Binary: ocaml-compiler-libs ocaml-native-compilers ocaml-base-nox ocaml-base ocaml ocaml-nox ocaml-interp ocaml-source Architecture: source powerpc all Version: 3.08.3-2 Distribution: unstable Urgency: medium Maintainer: Sven Luther [EMAIL PROTECTED] Changed-By: Sven Luther [EMAIL PROTECTED] Description: ocaml - ML language implementation with a class-based object system ocaml-base - Runtime system for ocaml bytecode executables ocaml-base-nox - Runtime system for ocaml bytecode executables ocaml-compiler-libs - Ocaml interpreter and standard libraries ocaml-interp - Ocaml interpreter and standard libraries ocaml-native-compilers - Native code compilers of the ocaml suite (the .opt ones) ocaml-nox - ML language implementation with a class-based object system ocaml-source - Sources for Objective Caml Changes: ocaml (3.08.3-2) unstable; urgency=medium . * Missed some 3.08 - 3.08.3 migration for ld.conf files. Files: b83502cff8b3c33f7ba88dcbb4fe200d 736 devel optional ocaml_3.08.3-2.dsc a1da5ae4708ab18965ea78c81cbeba1e 42108 devel optional ocaml_3.08.3-2.diff.gz 2e8bc2b15c1191aa7e2e7fa830d0795c 6452266 devel optional ocaml-nox_3.08.3-2_powerpc.deb 6d255d986a8659b472560c3f08a551c0 3101300 devel optional ocaml-native-compilers_3.08.3-2_powerpc.deb ffc687b551f8281c1cd3cdbb632f91bd 1820446 devel optional ocaml_3.08.3-2_powerpc.deb 260f2f07399afb6cbec483862cf6ad7e 160630 devel optional ocaml-base-nox_3.08.3-2_powerpc.deb c99a1f909dda9bc95df642b2acad0048 67496 devel optional ocaml-base_3.08.3-2_powerpc.deb 7f76f61bf3c479211c6065cb6f7bea44 2062278 devel optional ocaml-source_3.08.3-2_all.deb f087154b952542a3968f0bdb57926d9f 934962 devel optional ocaml-interp_3.08.3-2_powerpc.deb 78998c83e82b3c59025ca36273e28e2d 840038 devel optional ocaml-compiler-libs_3.08.3-2_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCP9NS2WTeT3CRQaQRAjA4AJoDHYU3b4fTnMQITPQiiaOr3b8ZuwCfYsKO HsBIPrKxzduyPXGDv+VlKZI= =8iaf -END PGP SIGNATURE- Accepted: ocaml-base-nox_3.08.3-2_powerpc.deb to pool/main/o/ocaml/ocaml-base-nox_3.08.3-2_powerpc.deb ocaml-base_3.08.3-2_powerpc.deb to pool/main/o/ocaml/ocaml-base_3.08.3-2_powerpc.deb ocaml-compiler-libs_3.08.3-2_powerpc.deb to pool/main/o/ocaml/ocaml-compiler-libs_3.08.3-2_powerpc.deb ocaml-interp_3.08.3-2_powerpc.deb to pool/main/o/ocaml/ocaml-interp_3.08.3-2_powerpc.deb ocaml-native-compilers_3.08.3-2_powerpc.deb to pool/main/o/ocaml/ocaml-native-compilers_3.08.3-2_powerpc.deb ocaml-nox_3.08.3-2_powerpc.deb to pool/main/o/ocaml/ocaml-nox_3.08.3-2_powerpc.deb ocaml-source_3.08.3-2_all.deb to pool/main/o/ocaml/ocaml-source_3.08.3-2_all.deb ocaml_3.08.3-2.diff.gz to pool/main/o/ocaml/ocaml_3.08.3-2.diff.gz ocaml_3.08.3-2.dsc to pool/main/o/ocaml/ocaml_3.08.3-2.dsc ocaml_3.08.3-2_powerpc.deb to pool/main/o/ocaml/ocaml_3.08.3-2_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted spampd 2.20-9 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Mar 2005 21:28:52 +0100 Source: spampd Binary: spampd Architecture: source all Version: 2.20-9 Distribution: unstable Urgency: low Maintainer: Sven Mueller [EMAIL PROTECTED] Changed-By: Sven Mueller [EMAIL PROTECTED] Description: spampd - spamassassin based SMTP/LMTP proxy daemon Closes: 295590 300066 Changes: spampd (2.20-9) unstable; urgency=low . * Fix line duplication introduced by the add-envelope-from_to patch * Fix a typo in debian/patches/55-add-envelope-from_to.dpatch which prevented the patch from being applied. (closes: #295590) - The option to enable addition of envelope headers is -seh or --set-envelope-headers * Fix a typo in the package description (closes: #300066) * remove dh_testroot from build and clean targets. It's only needed in the install target Files: 93cf1cd25c483ee3c31684a342fe0922 625 mail optional spampd_2.20-9.dsc 1864e9c9af0f43db21065df84780a9a7 10016 mail optional spampd_2.20-9.diff.gz 18845626fa574dca344b5dff09d6658c 42184 mail optional spampd_2.20-9_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iEYEARECAAYFAkI/SOoACgkQIgvIgzMMSnUVIACgwRjDa875Okp4lC4R+5s7Xijf QmQAoOnANx8lxxUTJXybVWHPVH1p+3H6 =1Mhu -END PGP SIGNATURE- Accepted: spampd_2.20-9.diff.gz to pool/main/s/spampd/spampd_2.20-9.diff.gz spampd_2.20-9.dsc to pool/main/s/spampd/spampd_2.20-9.dsc spampd_2.20-9_all.deb to pool/main/s/spampd/spampd_2.20-9_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted plib 1.8.4-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 25 Jan 2005 16:34:05 +0100 Source: plib Binary: plib1.8.4 plib1.8.4-dev plib1.8.4-pic Architecture: source i386 Version: 1.8.4-1 Distribution: unstable Urgency: low Maintainer: Philipp Frauenfelder [EMAIL PROTECTED] Changed-By: Philipp Frauenfelder [EMAIL PROTECTED] Description: plib1.8.4 - Portability Libraries: Run-time package, stable release plib1.8.4-dev - Portability Libraries: Development package, stable release plib1.8.4-pic - Portability Libraries: Dev. package (with PIC code), stable rel. Changes: plib (1.8.4-1) unstable; urgency=low . * New upstream release: accumulated small bug fixes, minor enhancements. * Changed debian/watch file. Files: 5c8076a97c0db04d1dad1132ec241df0 694 devel extra plib_1.8.4-1.dsc 5e3f289a9d1c5de0b1cfdec76bf139e6 793758 devel extra plib_1.8.4.orig.tar.gz d024dc28055e3b6cbb840f0af30736bf 7827 devel extra plib_1.8.4-1.diff.gz 12f2844cac74d1db5d0cdb0d3633202a 621968 libs extra plib1.8.4_1.8.4-1_i386.deb 506c333734c8c1b90d1d0e9e3adf22bf 843356 libdevel extra plib1.8.4-dev_1.8.4-1_i386.deb c3c83c51bea48e60b84659e93f29f35e 844426 libdevel extra plib1.8.4-pic_1.8.4-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB9nPOWLF0MZ2lytgRArlvAKC2Yu1O9yZtWx58IguYScfbMsyXawCg5jfA xWkJT2ZDNB91BHPDT9TDRc8= =cvE8 -END PGP SIGNATURE- Accepted: plib1.8.4-dev_1.8.4-1_i386.deb to pool/main/p/plib/plib1.8.4-dev_1.8.4-1_i386.deb plib1.8.4-pic_1.8.4-1_i386.deb to pool/main/p/plib/plib1.8.4-pic_1.8.4-1_i386.deb plib1.8.4_1.8.4-1_i386.deb to pool/main/p/plib/plib1.8.4_1.8.4-1_i386.deb plib_1.8.4-1.diff.gz to pool/main/p/plib/plib_1.8.4-1.diff.gz plib_1.8.4-1.dsc to pool/main/p/plib/plib_1.8.4-1.dsc plib_1.8.4.orig.tar.gz to pool/main/p/plib/plib_1.8.4.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dresden-ocl 1.1-6 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Mar 2005 09:27:55 +0100 Source: dresden-ocl Binary: libocl-argo-java Architecture: source all Version: 1.1-6 Distribution: unstable Urgency: low Maintainer: Debian Java Maintainers [EMAIL PROTECTED] Changed-By: Arnaud Vandyck [EMAIL PROTECTED] Description: libocl-argo-java - Dresden OCL (Object Constraint Language) Java Toolkit Changes: dresden-ocl (1.1-6) unstable; urgency=low . * now build with libant1.6-java Files: 216b65cf57b806accc6bdef812054e4e 801 contrib/misc optional dresden-ocl_1.1-6.dsc 1d8b5fd37b4ca4fc68b9e869529dee60 6219 contrib/misc optional dresden-ocl_1.1-6.diff.gz 75880b84cc74dd31f61fbb5a2ffb595b 574212 contrib/libs optional libocl-argo-java_1.1-6_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCP9ov4vzFZu62tMIRAsQtAJwMMeZ5wZm857ZaxDh1Etdi62Qs1ACggw2Z NlKgHwrx+ARGvPxQ3aHM32c= =UfWs -END PGP SIGNATURE- Accepted: dresden-ocl_1.1-6.diff.gz to pool/contrib/d/dresden-ocl/dresden-ocl_1.1-6.diff.gz dresden-ocl_1.1-6.dsc to pool/contrib/d/dresden-ocl/dresden-ocl_1.1-6.dsc libocl-argo-java_1.1-6_all.deb to pool/contrib/d/dresden-ocl/libocl-argo-java_1.1-6_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gdb-m68hc1x 1:6.2+3.0-2 (mips source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 20 Mar 2005 08:08:22 +0100 Source: gdb-m68hc1x Binary: gdb-m68hc1x Architecture: source mips Version: 1:6.2+3.0-2 Distribution: unstable Urgency: low Maintainer: Aurelien Jarno [EMAIL PROTECTED] Changed-By: Aurelien Jarno [EMAIL PROTECTED] Description: gdb-m68hc1x - GNU Debugger for the Motorola 68HC11/12 processors Changes: gdb-m68hc1x (1:6.2+3.0-2) unstable; urgency=low . * Build-Depends on lkvm-dev on kfreebsd-gnu. Files: dcb4b4bf996f7b130e94f715a9162fe8 745 devel extra gdb-m68hc1x_6.2+3.0-2.dsc 8e83a5fd712513470f406a29c94050b7 10137 devel extra gdb-m68hc1x_6.2+3.0-2.diff.gz f3570ef189010d136a7146254e4d0067 2612720 devel extra gdb-m68hc1x_6.2+3.0-2_mips.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCPVzuw3ao2vG823MRAvWFAJ9hIZ0K51lzYqt5fI9m419aBOf/CACcCcuA 3QOVuR/Lc5MOaG1gUWimsy4= =ni8m -END PGP SIGNATURE- Accepted: gdb-m68hc1x_6.2+3.0-2.diff.gz to pool/main/g/gdb-m68hc1x/gdb-m68hc1x_6.2+3.0-2.diff.gz gdb-m68hc1x_6.2+3.0-2.dsc to pool/main/g/gdb-m68hc1x/gdb-m68hc1x_6.2+3.0-2.dsc gdb-m68hc1x_6.2+3.0-2_mips.deb to pool/main/g/gdb-m68hc1x/gdb-m68hc1x_6.2+3.0-2_mips.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pound 1.8.2-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Mar 2005 09:45:58 +0100 Source: pound Binary: pound Architecture: source i386 Version: 1.8.2-1 Distribution: unstable Urgency: low Maintainer: Sam Johnston [EMAIL PROTECTED] Changed-By: Michael Piefel [EMAIL PROTECTED] Description: pound - reverse proxy, load balancer and https front-end for web-servers Closes: 285357 293915 Changes: pound (1.8.2-1) unstable; urgency=low . * New upstream version, closes: #285357 - This supposedly also fixes some SSL issues and closes 263578 * Added myself to uploaders, I will try to look after the package as long as Sam is too busy. * Increased MAXBUF, closes: #293915 Files: 31530665a5a0302366d778e853d6425d 631 net extra pound_1.8.2-1.dsc c9b0793bb4d57be2270093d79b13c019 140455 net extra pound_1.8.2.orig.tar.gz 05571b6d5af304574a9faf0aba531ffb 12261 net extra pound_1.8.2-1.diff.gz f0dbf9a4cd88c49c85a5b276ab61a054 68496 net extra pound_1.8.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCP+lN5GwONXmN2VwRAkaEAJwMK8sMmMRFKsfHUitQKc59Lx+FeACffjGV xWdxqycmqsku7oIUn/huSGI= =JhxR -END PGP SIGNATURE- Accepted: pound_1.8.2-1.diff.gz to pool/main/p/pound/pound_1.8.2-1.diff.gz pound_1.8.2-1.dsc to pool/main/p/pound/pound_1.8.2-1.dsc pound_1.8.2-1_i386.deb to pool/main/p/pound/pound_1.8.2-1_i386.deb pound_1.8.2.orig.tar.gz to pool/main/p/pound/pound_1.8.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted wvstreams 4.0.1-1.4 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Mar 2005 21:40:51 -0800 Source: wvstreams Binary: libwvstreams4.0-qt libwvstreams4.0-fft libwvstreams4.0-base libuniconf4.0 libwvstreams4.0-doc uniconfd libwvstreams-dev libwvstreams4.0-speex uniconf-tools libwvstreams4.0-extras libwvstreams4.0-vorbis Architecture: source i386 all Version: 4.0.1-1.4 Distribution: unstable Urgency: low Maintainer: Simon Law [EMAIL PROTECTED] Changed-By: Steve Langasek [EMAIL PROTECTED] Description: libuniconf4.0 - C++ network libraries for rapid application development libwvstreams-dev - Development libraries and header files for libwvstreams4.0 libwvstreams4.0-base - C++ network libraries for rapid application development libwvstreams4.0-doc - Documentation for WvStreams libwvstreams4.0-extras - C++ network libraries for rapid application development libwvstreams4.0-fft - WvStreams wrapper for libfftw libwvstreams4.0-qt - WvStreams and Qt Event Integration Library libwvstreams4.0-speex - WvStreams Speex Encoder/Decoder Library libwvstreams4.0-vorbis - WvStreams OggVorbis Encoder/Decoder Library uniconf-tools - Tools to interface with UniConf uniconfd - Server that manages UniConf elements Closes: 297554 297694 Changes: wvstreams (4.0.1-1.4) unstable; urgency=low . * Non-maintainer upload. * Further setup_modem fixes: don't depend on TIOCSSERIAL or TIOCGSERIAL working at all, since they apparently don't with USB modems and some WinModems. (Closes: #297694, #297554) Files: 48d3e53c3f7502279c3fdb0b57d9fed3 1047 libs optional wvstreams_4.0.1-1.4.dsc 4737d223fa219f511e9c6e8584e60ca1 5309 libs optional wvstreams_4.0.1-1.4.diff.gz ce6342b534b79a1084f56b193171349e 341146 libs optional libwvstreams4.0-base_4.0.1-1.4_i386.deb dc05df5ca7c1d6aeb9af2076749a39ce 418692 libs optional libwvstreams4.0-extras_4.0.1-1.4_i386.deb bdea5a9840b45da614216e08c399b61a 290268 libs optional libuniconf4.0_4.0.1-1.4_i386.deb 1fce792f63b1f8dd3f1965ab582780e0 232234 libs optional libwvstreams4.0-fft_4.0.1-1.4_i386.deb aa4421123ad6855aefe7df50bd5c2131 256356 libs optional libwvstreams4.0-qt_4.0.1-1.4_i386.deb 115fe74b4ed8d3d00793220f1e55e320 237570 libs optional libwvstreams4.0-vorbis_4.0.1-1.4_i386.deb 3fee39be4e26861bfd53ccf4e665f814 227248 libs optional libwvstreams4.0-speex_4.0.1-1.4_i386.deb 1260b9c7aa9e57a618884d72c150541a 936038 libdevel optional libwvstreams-dev_4.0.1-1.4_i386.deb ef7c4e55169b6d4c92d0ab48065dad0d 239906 utils optional uniconfd_4.0.1-1.4_i386.deb 57c621c7e6a453a1e2a82015752facc5 237212 utils optional uniconf-tools_4.0.1-1.4_i386.deb e508ecd0bb937ac24b75b1110779178e 2521704 doc optional libwvstreams4.0-doc_4.0.1-1.4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCP961KN6ufymYLloRAuQiAJ0bp4z/B/QKjyBmKS4sZ80v8nbudACeMjJj BzXjgs5AEyBtHSNYDqzbTMU= =aLpd -END PGP SIGNATURE- Accepted: libuniconf4.0_4.0.1-1.4_i386.deb to pool/main/w/wvstreams/libuniconf4.0_4.0.1-1.4_i386.deb libwvstreams-dev_4.0.1-1.4_i386.deb to pool/main/w/wvstreams/libwvstreams-dev_4.0.1-1.4_i386.deb libwvstreams4.0-base_4.0.1-1.4_i386.deb to pool/main/w/wvstreams/libwvstreams4.0-base_4.0.1-1.4_i386.deb libwvstreams4.0-doc_4.0.1-1.4_all.deb to pool/main/w/wvstreams/libwvstreams4.0-doc_4.0.1-1.4_all.deb libwvstreams4.0-extras_4.0.1-1.4_i386.deb to pool/main/w/wvstreams/libwvstreams4.0-extras_4.0.1-1.4_i386.deb libwvstreams4.0-fft_4.0.1-1.4_i386.deb to pool/main/w/wvstreams/libwvstreams4.0-fft_4.0.1-1.4_i386.deb libwvstreams4.0-qt_4.0.1-1.4_i386.deb to pool/main/w/wvstreams/libwvstreams4.0-qt_4.0.1-1.4_i386.deb libwvstreams4.0-speex_4.0.1-1.4_i386.deb to pool/main/w/wvstreams/libwvstreams4.0-speex_4.0.1-1.4_i386.deb libwvstreams4.0-vorbis_4.0.1-1.4_i386.deb to pool/main/w/wvstreams/libwvstreams4.0-vorbis_4.0.1-1.4_i386.deb uniconf-tools_4.0.1-1.4_i386.deb to pool/main/w/wvstreams/uniconf-tools_4.0.1-1.4_i386.deb uniconfd_4.0.1-1.4_i386.deb to pool/main/w/wvstreams/uniconfd_4.0.1-1.4_i386.deb wvstreams_4.0.1-1.4.diff.gz to pool/main/w/wvstreams/wvstreams_4.0.1-1.4.diff.gz wvstreams_4.0.1-1.4.dsc to pool/main/w/wvstreams/wvstreams_4.0.1-1.4.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted drupal 4.5.2-3 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Mar 2005 11:34:58 +0100 Source: drupal Binary: drupal Architecture: source all Version: 4.5.2-3 Distribution: unstable Urgency: high Maintainer: Hilko Bengen [EMAIL PROTECTED] Changed-By: Hilko Bengen [EMAIL PROTECTED] Description: drupal - fully-featured content management/discussion engine Changes: drupal (4.5.2-3) unstable; urgency=high . * Fixes Bypass access via comments problem mentioned in http://drupal.org/node/19009. I consider this a critical bug, hence urgency=high. * [Sergio Talens-Oliag [EMAIL PROTECTED]] Updated Spanish and Catalan Debconf translations and converted them to UTF-8. Files: c3d69ac5d1da6e157b9615421caedf65 609 web extra drupal_4.5.2-3.dsc c096e3e444746b59579da370fd41ca88 33221 web extra drupal_4.5.2-3.diff.gz d89a706d3a65854ea1fb21db050cd528 481388 web extra drupal_4.5.2-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCP/rZUCgnLz/SlGgRAnoPAJ4ikcGEHJwg4a3X8Jn/aNsTj3RBFACdEKI6 5APILO4++Tk8Ku3AUEoa7qE= =K6K1 -END PGP SIGNATURE- Accepted: drupal_4.5.2-3.diff.gz to pool/main/d/drupal/drupal_4.5.2-3.diff.gz drupal_4.5.2-3.dsc to pool/main/d/drupal/drupal_4.5.2-3.dsc drupal_4.5.2-3_all.deb to pool/main/d/drupal/drupal_4.5.2-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted e2fsprogs 1.37-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 21 Mar 2005 22:31:08 -0500 Source: e2fsprogs Binary: e2fslibs-dev libblkid1-udeb libblkid1 comerr-dev libuuid1 ss-dev uuid-dev e2fslibs e2fsck-static e2fsprogs-udeb libuuid1-udeb e2fsprogs libblkid-dev libcomerr2 libss2 Architecture: source i386 Version: 1.37-1 Distribution: unstable Urgency: low Maintainer: Theodore Y. Ts'o [EMAIL PROTECTED] Changed-By: Theodore Y. Ts'o [EMAIL PROTECTED] Description: comerr-dev - common error description library - headers and static libraries e2fsck-static - statically-linked version of the ext2 filesystem checker e2fslibs - ext2 filesystem libraries e2fslibs-dev - ext2 filesystem libraries - headers and static libraries e2fsprogs - ext2 file system utilities and libraries e2fsprogs-udeb - stripped-down versions of e2fsprogs, for debian-installer (udeb) libblkid-dev - block device id library - headers and static libraries libblkid1 - block device id library libblkid1-udeb - block device id library (udeb) libcomerr2 - common error description library libss2 - command-line interface parsing library libuuid1 - universally unique id library libuuid1-udeb - universally unique id library (udeb) ss-dev - command-line interface parsing library - headers and static libra uuid-dev - universally unique id library - headers and static libraries Closes: 296769 296769 299341 Changes: e2fsprogs (1.37-1) unstable; urgency=low . * New upstream release. * Fixed a bug in e2fsck so it would notice if a file with an extended attribute block was exactly 2**32 blocks, such that i_blocks wrapped to zero. * Fixed a bug in filefrag which caused it to falsely report a discontinuity when there are one or more unallocated blocks at the beginning of a file. * Fix the missing translations (caused by a bug in the gen-tarball script). (Closes: #296769) * Add support in e2fsck and debugfs for extended attributes in inodes. * Fix the missing translations (caused by a bug in the gen-tarball script). (Closes: #296769) * Force compile_et and mk_cmds to use /usr/bin/awk so that we will work on any Debian system regardless of which version of awk is installed. (Closes: #299341) Files: 74bd0943fb2b7017d1c6a15902f8a840 764 base required e2fsprogs_1.37-1.dsc 084b49e919121fc0bf53c8dae23a71f8 3507693 base required e2fsprogs_1.37.orig.tar.gz fc8e9af2d78156a016dbae97fc82dbc2 20 base required e2fsprogs_1.37-1.diff.gz 9c2f54af4faec0d0d0a1cecd1005c6ee 289902 admin optional e2fsck-static_1.37-1_i386.deb 8f68c313251a4961475839ceedf11139 26286 libs required libcomerr2_1.37-1_i386.deb 0d2373ef36cc5c83a3f5465c83005ecc 31914 libs required libss2_1.37-1_i386.deb b12aabc2f14daca8633496d6acf9a776 31716 libs required libuuid1_1.37-1_i386.deb 8ef2134651f71cd748edff3c677480d3 41206 libs required libblkid1_1.37-1_i386.deb ca29119074dcce76252f75059ceee049 48382 libdevel extra libblkid-dev_1.37-1_i386.deb 02c6adfb9218f3a7b2d27bc6e7e5a382 76954 libs required e2fslibs_1.37-1_i386.deb f231d8ed8884ce4b7113174e79c8e974 354298 libdevel extra e2fslibs-dev_1.37-1_i386.deb f60c80a2ca6bebcf83fc137181e8f36f 509436 base required e2fsprogs_1.37-1_i386.deb 11bca6e1614845455a3be21484c438e2 44974 libdevel extra comerr-dev_2.1-1.37-1_i386.deb faf95a0e34c468214f88307101640166 38614 libdevel extra ss-dev_2.0-1.37-1_i386.deb 828abf3b40b118b4cb861c0f8ae5d3aa 45964 libdevel extra uuid-dev_1.2-1.37-1_i386.deb d849209c5108b099905f9c9432242a12 121562 debian-installer standard e2fsprogs-udeb_1.37-1_i386.udeb e3d65288bd85cd8a37525f7ce51a04ed 12266 debian-installer required libblkid1-udeb_1.37-1_i386.udeb 388e36544a6e8dead5c0f3b3d29d2466 5290 debian-installer required libuuid1-udeb_1.37-1_i386.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCP5W17To545NnTEARAuRqAKDHtKFeIeyppx1eF0ve4IPDneZdFQCgpn0c 1wXP4d91OH6db9HR0zgONoI= =/SAI -END PGP SIGNATURE- Accepted: comerr-dev_2.1-1.37-1_i386.deb to pool/main/e/e2fsprogs/comerr-dev_2.1-1.37-1_i386.deb e2fsck-static_1.37-1_i386.deb to pool/main/e/e2fsprogs/e2fsck-static_1.37-1_i386.deb e2fslibs-dev_1.37-1_i386.deb to pool/main/e/e2fsprogs/e2fslibs-dev_1.37-1_i386.deb e2fslibs_1.37-1_i386.deb to pool/main/e/e2fsprogs/e2fslibs_1.37-1_i386.deb e2fsprogs-udeb_1.37-1_i386.udeb to pool/main/e/e2fsprogs/e2fsprogs-udeb_1.37-1_i386.udeb e2fsprogs_1.37-1.diff.gz to pool/main/e/e2fsprogs/e2fsprogs_1.37-1.diff.gz e2fsprogs_1.37-1.dsc to pool/main/e/e2fsprogs/e2fsprogs_1.37-1.dsc e2fsprogs_1.37-1_i386.deb to pool/main/e/e2fsprogs/e2fsprogs_1.37-1_i386.deb e2fsprogs_1.37.orig.tar.gz to pool/main/e/e2fsprogs/e2fsprogs_1.37.orig.tar.gz libblkid-dev_1.37-1_i386.deb to pool/main/e/e2fsprogs/libblkid-dev_1.37-1_i386.deb libblkid1-udeb_1.37-1_i386.udeb to pool/main/e/e2fsprogs/libblkid1-udeb_1.37-1_i386.udeb libblkid1_1.37-1_i386.deb to pool/main/e/e2fsprogs/libblkid1_1.37-1_i386.deb
Accepted osdsh 0.7.0-6 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Mar 2005 12:29:50 +0100 Source: osdsh Binary: osdsh Architecture: source i386 Version: 0.7.0-6 Distribution: unstable Urgency: low Maintainer: Joachim Breitner [EMAIL PROTECTED] Changed-By: Joachim Breitner [EMAIL PROTECTED] Description: osdsh - Overlays your screen with various system information Closes: 299442 Changes: osdsh (0.7.0-6) unstable; urgency=low . * Closes: #299442: does not start on powerpc (thanks to Wolfram Quester [EMAIL PROTECTED] for the fix) Files: a5a5f24746a841cf595753c2cf86be2f 599 x11 optional osdsh_0.7.0-6.dsc 8f0cade830b96958519264fcae9720a4 7213 x11 optional osdsh_0.7.0-6.diff.gz bd5bb992170c7a0fa3fff75ae0669357 34754 x11 optional osdsh_0.7.0-6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCQAPV9ijrk0dDIGwRAsSUAJ4945pSS/YFIrZs44COHnAZX0k35gCfWRMu +T8Zl80pKy9ZoKqAmxn1DaE= =QhSn -END PGP SIGNATURE- Accepted: osdsh_0.7.0-6.diff.gz to pool/main/o/osdsh/osdsh_0.7.0-6.diff.gz osdsh_0.7.0-6.dsc to pool/main/o/osdsh/osdsh_0.7.0-6.dsc osdsh_0.7.0-6_i386.deb to pool/main/o/osdsh/osdsh_0.7.0-6_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libjazzy-java 0.5-3 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Mar 2005 11:53:26 +0100 Source: libjazzy-java Binary: libjazzy-java Architecture: source all Version: 0.5-3 Distribution: unstable Urgency: low Maintainer: Debian Java Maintainers [EMAIL PROTECTED] Changed-By: Arnaud Vandyck [EMAIL PROTECTED] Description: libjazzy-java - spell checker java library Changes: libjazzy-java (0.5-3) unstable; urgency=low . * build with ant1.6 Files: 48e731f9f1106b1548c369a6fabbc548 744 contrib/libs optional libjazzy-java_0.5-3.dsc 6fbdd68d750f1083049cd8694aaa48cf 2231 contrib/libs optional libjazzy-java_0.5-3.diff.gz d2a08736e8ad68d83bc9970685bca660 243618 contrib/libs optional libjazzy-java_0.5-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCQApb4vzFZu62tMIRAlaBAKCkHsKpSOHsnrtP54eBPKX2HLBonQCgmoIz NOyr7RlY8TDvrw6wG7SEjA0= =R1rU -END PGP SIGNATURE- Accepted: libjazzy-java_0.5-3.diff.gz to pool/contrib/libj/libjazzy-java/libjazzy-java_0.5-3.diff.gz libjazzy-java_0.5-3.dsc to pool/contrib/libj/libjazzy-java/libjazzy-java_0.5-3.dsc libjazzy-java_0.5-3_all.deb to pool/contrib/libj/libjazzy-java/libjazzy-java_0.5-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
