Results of my Survey on Debian Usage
Hello, After quite some time passed cleaning up the replies, writing the processing scripts and learning CSS, I'm proud to announce the results[1] of the Survey on Debian Usage I posted in April 2004[2]. http://people.debian.org/~enrico/survey/survey.php The presentation pages provide some views on the results, which I consider quite successful in giving various insights on our community, as well as some interesting ideas to direct further development[3]. Due to the massive amount of replies that I received and the qualitative nature of the survey, it took me a long time to process the results. For the same reasons, and because I have limited knowledge of qualitative metodologies, I have problems providing too much interpretation of the data. Nevertheless, I'm very happy to see this data coming together, I've learnt a lot while processing them, and I'm sure that people spending some time wandering around the results will learn something as well. A personal, big thank you to all the people who replied to the survey and all the people who gave me suggestions along the way. Ciao, Enrico [1] http://people.debian.org/~enrico/survey/survey.php [2] http://lists.debian.org/debian-devel/2004/04/msg01508.html [3] For example, I started writing buffy[4] pushed by noticing that many people perceive Debian as used mainly for servers and development, but use it mainly for e-mail :) [4] http://packages.debian.org/unstable/misc/buffy -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 09:37:11PM +, Brian M. Carlson wrote: On Sun, 2005-03-13 at 20:45 -0800, Steve Langasek wrote: Architectures that are no longer being considered for stable releases are not going to be left out in the cold. I disagree. I feel that maintainers are going to ignore the SCC architectures for the purposes of portability bugs and security fixes. So NMU? - binary packages must be built from the unmodified Debian source (required, among other reasons, for license compliance) This is a problem. No one will fix the portability bugs that plague, for example, sparc (memory alignment SIGBUS) without them being severity serious. Sparc is no longer the only architecture that has problems with unaligned memory access, so these are likely to be caught whether or not sparc is a release arch. Therefore, I would support this plan *iff* it were stated that portability bugs were still severity serious (I would not object to an etch-ignore tag for the purpose of stating that they are irrelevant to the release), that security bugs were still severity grave and critical (again etch-ignore would be okay), and that maintainers actually have to fix such bugs, or their packages could be pulled from the archive as too buggy to support. Well, by definition if the bugs were tagged etch-ignore or equivalent, they shouldn't be grounds for removing the package from testing or unstable; and I don't think there's any reason that bugs on non-release archs should mark a package as too buggy to support. But that doesn't mean porter NMUs would be disallowed. For the record, I own more sparc machines than any other single architecture, and I am not pleased about this plan. Then please, get involved in the sparc port to help ensure that it remains viable for etch. There is clearly no problem with sparc hardware that would justify dropping the port, and in spite of being down to only one buildd right now, we've generally not had problems with it failing to keep up; and yet, sparc's only packaged bootloader (silo) seems to be in terrible shape with unreproducible boot failures (which will be downgraded for sarge), and was one of the last architectures to have the necessary kernel updates done for d-i RC3. The signs certainly point to bit rot, but if someone takes responsibility for it, I see no reason for sparc to not be in shape for the etch release. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Friday 18 March 2005 07:27, Karsten Merker wrote: On Fri, Mar 18, 2005 at 12:06:08PM +1000, Anthony Towns wrote: m68k, mips, mipsel, hppa: I've got one in the basement, and I like to brag that I run Debian on it; also I occassionally get some work out of it, but it'd be trivial to replace with i386. sparc, alpha: We've bought some of these a while ago, they're useful running Debian, we'd really rather not have to stress with switching to i386, but whatever. why not just replace this with i386/amd64 hardware [...] If you argue in this style, let's remove all architectures (including *i386*) except for amd64 from Debian - after all, that is our most modern architecture and nobody hinders you of throwing out all your existing i386 hardware and buy a bunch of new shiny amd64 systems instead. Except that i386 support is almost gratis as most developers and most upstream and everyone else uses it. To answer Anthonys question: My main customer uses two old sparc boxes as nameserver and backup-host. Since they cannot execute i386 shell-code they are already hardend against many automated script-kiddy attacks and the hardware is rock solid. Security support obviously is obviously essential. If sparc is not able to reach REGULAR status we will have to replace them with REGULAR hardware. I talked with the CTO two days ago about the Vancouver plan and he said that implementing it (or something similar) would demonstrate Debians ability to cope with its internal problems, assuring him that he won't need to switch. Regards, David -- - 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: Bits (Nybbles?) from the Vancouver release team meeting
On Wed, Mar 16, 2005 at 05:36:33AM +0100, Adeodato Simó wrote: All the stuff is on scc; how do we transfer it back? Will it be easy, or a major obstacle? There is no transfer needed at all, IOW the capability to do releases from ports.debian.org exists (and is a very good thing, as Colin Watson points out in [EMAIL PROTECTED]). Still, the Release Managers should comment on their willingness to make a certain scc arch a release architecture at an advanced stage in the preparation of a release. In my view, this is one of the few scenarios that I can think of them exercising their veto power: Yes, you meet all the requirements, but as we're 2 months away from releasing we veto its inclusion _right now_. We put it first on our list of goals for the next release. If a port meets all of the requirements for being a release candidate architecture, and promoting it to release candidate status doesn't introduce too many arch-specific RC bugs that were previously being ignored, then I have no problem with promoting such an architecture to release-candidate status late in the cycle. It would almost certainly have to be done pre-freeze, for sanity's sake, but that's about it, AFAICT. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Thu, Mar 17, 2005 at 08:00:45PM +0100, Thiemo Seufer wrote: Both of these are plausible; the difference is whether you autobuild from unstable or testing. I would prefer the former, which means your former case. Autobuilding from testing won't work well AFAICS, as it introduces another delay until rc-arch bugs are found. Building packages with generic RC bugs and ignore them for subtesting seems to be the lesser evil. I disagree here, since building from testing means not duplicating all the job done in tier-1 testing. My project called for a per-arch override, uploading directly to arch-unstable, in case of stals and such. Also, building from testing makes synchronizing with tier-1 testing for an arch stable release easier. 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 Fri, Mar 18, 2005 at 12:06:08PM +1000, Anthony Towns wrote: Daniel Jacobowitz wrote: I would really like to see some real use cases for architectures that want this; I'd like to spend my time on things that're actually useful, not random whims people have on lists -- and at the moment, I'm not in a good position to tell the difference for most of the non-release architectures. Sure. The idea is still half-baked. If it has merit, someone needs to finish cooking it... So, I'd just like to re-emphasise this, because I still haven't seen anything that counts as useful. I'm thinking something like We use s390 to host 6231 scientific users on Debian in a manner compatible to the workstations they use; the software we use is ; we rely on having security support from Debian because we need to be on the interweb 2; At the moment, the only use cases I'm confident exist are: m68k, mips, mipsel, hppa: I've got one in the basement, and I like to brag that I run Debian on it; also I occassionally get some work out of it, but it'd be trivial to replace with i386. sparc, alpha: We've bought some of these a while ago, they're useful running Debian, we'd really rather not have to stress with switching to i386, but whatever. arm: We're developing some embedded boxes, that won't run Debian proper, but it's really convenient to have Debian there to bootstrap them trivially. s390: Hey, it's got spare cycles, why not? None of those are enough to justify effort maintaining a separate testing-esque suite for them; but surely someone has some better examples they can post... I think the main reply is for developers using said archs. they need to have a solid base to work on, and unstable is not it, with large chunks of it being uninstallable for a longer period of time (and this happens even on powerpc, which is a faster arch), so killing testing gives the developer (or whoever uses this arch) no real way of doing a clean install or maintaining a working setup on these arches, so removing testing is a self-fullfilling prophecy that they will die soon. The questions that need to be answered by the use case are what useful things are being done with the arch and why not just replace this with i386/amd64 hardware when support for sarge is dropped, which won't be for at least 12-18 months (minimum planned etch release cycle) plus 12 months (expected support for sarge as oldstable). Knowing why you're using Debian and not another distribution or OS would be interesting too. But that would not be debian anymore, at that time i wonder if a fork would be the only solution, and if this x86-centric distribution that will emerge from it will be fit to keep the debian name. What percentage of our developers come from alternative arches, and what amount of work and good quality maintainers will we loose if we kill these arches ? And can we afford that ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes:
On 17-Mar-05, 01:01 (CST), Joel Aelwyn [EMAIL PROTECTED] wrote:
* The ability for an interface to receive, by default, only traffic that
is destined for that interface. (Non-promiscuous mode; promiscuous mode
availability is a big plus, but not required from the OS point of view)
Linux fails this. Even with forwarding disabled, it will accept packets
for an address on interface A via interface B.
Enable rp_filter and it does reject such packets.
echo 1 /proc/sys/net/ipv4/conf/${dev}/rp_filter
--
Blars Blarson [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option. It is a standard feature.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Relaxing testing requirements (was: summarising answers to Vancouver critique)
also sprach Andreas Barth [EMAIL PROTECTED] [2005.03.17.1827 +0100]: * martin f krafft ([EMAIL PROTECTED]) [050317 17:10]: Why can't we have separate sid-testing propagation for each arch, then freeze testing as before, get rid of RC bugs, and release? Because than the security team may need to fix 11 different source packages (or how many architectures we actually release) instead of 1. This is a good point, but I wonder whether it should remain a show-stopper. Wouldn't the logical solution be to stock up the security team? That said, the chance of a package going out of sync on more than a few architectures is minimal, so even though your speculation is correct, it's likely not going to be in effect ever. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Relaxing testing requirements (was: summarising answers to Vancouver critique)
also sprach martin f krafft [EMAIL PROTECTED] [2005.03.18.1021 +0100]: That said, the chance of a package going out of sync on more than a few architectures is minimal, so even though your speculation is correct, it's likely not going to be in effect ever. and if we have different versions for different arches, the differences are most likely minimal, so that security patches should apply with minimal additional effort. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Do not make gratuitous source uploads just to provoke the buildds!
Except the possibility to profit from the release team's efforts, and to create an actually supported release. It is not reasonable to believe a small porter team can do security updates for a unstable snapshot when a task of similiar size already overloads the stable security team. No. As neither the release team, not the security team will take non-release archs into account. Cheers, Peter (p2). signature.asc Description: Digital signature
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Fri, Mar 18, 2005 at 12:18:44AM -0800, Steve Langasek wrote: On Wed, Mar 16, 2005 at 05:36:33AM +0100, Adeodato Simó wrote: There is no transfer needed at all, IOW the capability to do releases from ports.debian.org exists (and is a very good thing, as Colin Watson points out in [EMAIL PROTECTED]). Still, the Release Managers should comment on their willingness to make a certain scc arch a release architecture at an advanced stage in the preparation of a release. In my view, this is one of the few scenarios that I can think of them exercising their veto power: Yes, you meet all the requirements, but as we're 2 months away from releasing we veto its inclusion _right now_. We put it first on our list of goals for the next release. If a port meets all of the requirements for being a release candidate architecture, and promoting it to release candidate status doesn't introduce too many arch-specific RC bugs that were previously being ignored, then I have no problem with promoting such an architecture to release-candidate status late in the cycle. It would almost certainly have to be done pre-freeze, for sanity's sake, but that's about it, AFAICT. Right. I wouldn't like to suddenly make an architecture a release candidate when it hadn't been in the archive at all due to lack of testing, but if it had been on ports.d.o for a while then adding it shortly pre-freeze ought to be fine. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Relaxing testing requirements (was: summarising answers to Vancouver critique)
On Fri, 18 Mar 2005 10:22:31 +0100, martin f krafft [EMAIL PROTECTED] wrote: also sprach martin f krafft [EMAIL PROTECTED] [2005.03.18.1021 +0100]: That said, the chance of a package going out of sync on more than a few architectures is minimal, so even though your speculation is correct, it's likely not going to be in effect ever. and if we have different versions for different arches, the differences are most likely minimal, so that security patches should apply with minimal additional effort. It is, however, widely considered a feature that a package has the same version on all released arches. I'd vouch for keeping that requirement. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Do not make gratuitous source uploads just to provoke the buildds!
Porters who have worked on getting an arch to REGUALR status are in a much better position (demonstrated commitment, technical aptness and experiencewise) to solve those problems than random-joe-developer. I have no idea what you're trying to say here. Always remember that the main reason that it is easier for a porters team to release within the (current) Debian framework than outside is that _others_ do work for them. That has been the case up to now, but won't be the case after sarge. Cheers, Peter (p2). signature.asc Description: Digital signature
Re: Relaxing testing requirements (was: summarising answers to Vancouver critique)
also sprach Marc Haber [EMAIL PROTECTED] [2005.03.18.1053 +0100]: It is, however, widely considered a feature that a package has the same version on all released arches. I'd vouch for keeping that requirement. Are we really to expect a lot of disparities if we loosen the requirement? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! our destiny exercises its influence over us even when, as yet, we have not learned its nature; it is our future that lays down the law of our today. - friedrich nietzsche signature.asc Description: Digital signature
Re: Relaxing testing requirements (was: summarising answers to Vancouver critique)
On Fri, Mar 18, 2005 at 10:21:17AM +0100, martin f krafft wrote: also sprach Andreas Barth [EMAIL PROTECTED] [2005.03.17.1827 +0100]: * martin f krafft ([EMAIL PROTECTED]) [050317 17:10]: Why can't we have separate sid-testing propagation for each arch, then freeze testing as before, get rid of RC bugs, and release? Because than the security team may need to fix 11 different source packages (or how many architectures we actually release) instead of 1. This is a good point, but I wonder whether it should remain a show-stopper. Wouldn't the logical solution be to stock up the security team? The security team is under-staffed *now*, AFAICT; and you want to increase their workload for etch on the assumption that nothing bad will come of it? Far better for us to take the hit on release predictability, and continue wrestling 12 architectures in sync for testing. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Do not make gratuitous source uploads just to provoke the buildds!
Peter 'p2' De Schrijver [EMAIL PROTECTED] writes: Except the possibility to profit from the release team's efforts, and to create an actually supported release. It is not reasonable to believe a small porter team can do security updates for a unstable snapshot when a task of similiar size already overloads the stable security team. No. As neither the release team, not the security team will take non-release archs into account. Cheers, Peter (p2). You can still benefit from their work. The stable sources are hopefully in sync with each other, the software is known to work. Most importantly there are source CD/DVD sets out there for it. That saves a lot of working and server space. I don't think Debian should support having a complete fork, every port can do that on their own. As for security stuff probably all fixes can be reused as is by the porters if they have the sources in sync with stable. They just have to setup a wanna-build and buildd and they get the fixes quickly after Debian releases them. The more sources are out of sync the more likely it is a vulnerable package has a different version which means extra work. But I would hope there could be some working together like one porter joining the security team and including non release archs in the DSAs _if_ they compile their packages on time. MfG Goswin -- 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 wrote: I think the main reply is for developers using said archs. Developers *developing* on those architectures need to use unstable anyway. If there aren't any users, then there's no much point doing any development. Are there any users? If so, what are they doing? Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
AJ's categorization has some traction, but I think it's a somewhat short-term perspective. Just because a full Debian doesn't usually fit today's embedded footprint doesn't mean it won't fit tomorrow's, and in the meantime Debian's toolchain, kernel, and initrd-tools are probably the best embedded Linux development and packaging environment going. Doubly so if you respect the spirit of open source development and feel obliged to enable end users to reproduce firmware after a source-level change. I think Sarge on ARM has the potential to greatly reduce the learning curve for some kinds of embedded development, especially if Iyonix succeeds in its niche (long live the Acorn!). In particular I look forward to being able to woo certain mobile computing colleagues, currently doomed to PocketPC, with a proper native development environment. The same goes for some apparent doorstop arches: mipsel in networking and storage (e. g., SoC from Broadcom in set-tops, wireless gateways, and micro-NAS) and m68k in device control (68332 peripheral support, anyone?). On the other hand, enterprise sparc boxes with niceties like hot-swap PCI make lovely debian targets, and sparc64 may prove as practical on the high end as p(ower)?pc64 or even amd64. And these big girls haven't lost touch with their little sisters. In the etch time frame, sparc32 looks to me mostly like an embedded architecture (sparc-based CompactPCI boards remain in use in industrial automation) and powerpc (ppc32) isn't far behind. On present trends, i386 (amd32 :) ) will be a doorstop/embedded arch for etch+1 at the latest. That leaves mips (big-endian), hppa, alpha, and s390. Not so much doorstops as space heaters; some people might put ia64 in this category too. To my mind, they remain interesting because they cover more parameter space in terms of instruction set design, cache architecture, and relative speeds and sizes of CPU/memory/interconnect. When something close to a common kernel source base works adequately on all of them, it starts to look production-ready. Likewise, minority-architecture autobuilders are one reason why Debian is really the only organization I trust to QA a toolchain any more. For instance, compiling KDE for all of them expands the C++ stress test in a really useful way. Even better if at least a couple of people actually run big globs of GUI on their kotatsu and catch run-time problems like #292673 (grave glibc bug, spotted with evolution on ia64). Although sarge's long cycle has been frustrating for many people, if you ask me it's just as well that Debian never put the label stable on kernel 2.6.7 (i. e., pre-objrmap), gcc 3.2.3+ (not just C++, but nagging C and optimizer problems, often exposed by non-i386 kernels, in all previous 3.x), or glibc 2.3.(before next week or so, given #292673). By comparison, the next year's core changes are likely to be much more incremental in nature, with a few exceptions we can already see coming (UTF-8 everywhere, the rest of FLOSS Java in main, Perl 6 :-) ) and one big asterisk (biarch, aka dpkg 2 (c: ). None of that says that the world has a right to put the burden of sysadmining the broadest single software QA effort in history on the Debian release team's shoulders. But if specific technical problems can be identified and addressed to where the infrastructure equipment and teams can stand it, keeping Debian Universal for at least one more cycle would be Herculean but not impossible. I think this is one of those cases where the last 20% of the effort invested (coaxing along minority architectures) provides 80% of the value (stable actually means something). Or look at it this way: supporting minority architectures has revealed all sorts of scalability problems in Debian. Some of those problems will be really nasty if we wait until the major architectures are in crisis to face them. The doorstops are the canaries in the coal mine that start to suffocate before the big guys notice air quality problems. Don't like performing CPR on canaries? Don't put 'em down in coal mines! Wait, there's something wrong with that logic ... 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
AJ's categorization has some traction, but I think it's a somewhat short-term perspective. Just because a full Debian doesn't usually fit today's embedded footprint doesn't mean it won't fit tomorrow's, and in the meantime Debian's toolchain, kernel, and initrd-tools are probably the best embedded Linux development and packaging environment going. Doubly so if you respect the spirit of open source development and feel obliged to enable end users to reproduce firmware after a source-level change. I think Sarge on ARM has the potential to greatly reduce the learning curve for some kinds of embedded development, especially if Iyonix succeeds in its niche (long live the Acorn!). In particular I look forward to being able to woo certain mobile computing colleagues, currently doomed to PocketPC, with a proper native development environment. The same goes for some apparent doorstop arches: mipsel in networking and storage (e. g., SoC from Broadcom in set-tops, wireless gateways, and micro-NAS) and m68k in device control (68332 peripheral support, anyone?). On the other hand, enterprise sparc boxes with niceties like hot-swap PCI make lovely debian targets, and sparc64 may prove as practical on the high end as p(ower)?pc64 or even amd64. And these big girls haven't lost touch with their little sisters. In the etch time frame, sparc32 looks to me mostly like an embedded architecture (sparc-based CompactPCI boards remain in use in industrial automation) and powerpc (ppc32) isn't far behind. On present trends, i386 (amd32 :) ) will be a doorstop/embedded arch for etch+1 at the latest. That leaves mips (big-endian), hppa, alpha, and s390. Not so much doorstops as space heaters; some people might put ia64 in this category too. To my mind, they remain interesting because they cover more parameter space in terms of instruction set design, cache architecture, and relative speeds and sizes of CPU/memory/interconnect. When something close to a common kernel source base works adequately on all of them, it starts to look production-ready. Likewise, minority-architecture autobuilders are one reason why Debian is really the only organization I trust to QA a toolchain any more. For instance, compiling KDE for all of them expands the C++ stress test in a really useful way. Even better if at least a couple of people actually run big globs of GUI on their kotatsu and catch run-time problems like #292673 (grave glibc bug, spotted with evolution on ia64). Although sarge's long cycle has been frustrating for many people, if you ask me it's just as well that Debian never put the label stable on kernel 2.6.7 (i. e., pre-objrmap), gcc 3.2.3+ (not just C++, but nagging C and optimizer problems, often exposed by non-i386 kernels, in all previous 3.x), or glibc 2.3.(before next week or so, given #292673). By comparison, the next year's core changes are likely to be much more incremental in nature, with a few exceptions we can already see coming (UTF-8 everywhere, the rest of FLOSS Java in main, Perl 6 :-) ) and one big asterisk (biarch, aka dpkg 2 (c: ). None of that says that the world has a right to put the burden of sysadmining the broadest single software QA effort in history on the Debian release team's shoulders. But if specific technical problems can be identified and addressed to where the infrastructure equipment and teams can stand it, keeping Debian Universal for at least one more cycle would be Herculean but not impossible. I think this is one of those cases where the last 20% of the effort invested (coaxing along minority architectures) provides 80% of the value (stable actually means something). Or look at it this way: supporting minority architectures has revealed all sorts of scalability problems in Debian. Some of those problems will be really nasty if we wait until the major architectures are in crisis to face them. The doorstops are the canaries in the coal mine that start to suffocate before the big guys notice air quality problems. Don't like performing CPR on canaries? Don't put 'em down in coal mines! Wait, there's something wrong with that logic ... Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Relaxing testing requirements (was: summarising answers to Vancouver critique)
also sprach Steve Langasek [EMAIL PROTECTED] [2005.03.18.1145 +0100]: This is a good point, but I wonder whether it should remain a show-stopper. Wouldn't the logical solution be to stock up the security team? The security team is under-staffed *now*, AFAICT; and you want to increase their workload for etch on the assumption that nothing bad will come of it? No, I said we should stock the security team, which I meant to read as: add more man-power. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! all women become like their mothers. that is their tragedy. no man does. that's his. -- oscar wilde signature.asc Description: Digital signature
Re: NEW handling ...
On Thu, Mar 17, 2005 at 11:37:50PM +0100, Matthias Urlichs wrote: Hi, Matthew Palmer wrote: I wonder if we could change Debian's attitude to NEW rejection like has happened with NMUs -- that having your package rejected isn't the end of the world, it's just something that happens. So ftpmasters could reject with less fear of being taken to the cleaners by random pissed-off maintainers on d-devel. My off-the-wall guess is that most DDs have problems with getting rejected because NEW takes a comparatively long time. Thus, after your package is stuck in NEW for two weeks, you get told that it's rejected because of a minor problem you could fix with a reupload just as easily -- instead, it's going to be stuck in NEW for *another* two weeks. Well, if it was just two weeks, that would be ok, the problem is that the package will sit in NEW for an undetermined amount of time, possibly forever even. That's (some) developer's view of the situation. The ftpmaster's view seems to be (I imagine not without some justification) that, unless the package is rejected, the average DD will never bother to fix it. :-/ So the packages just sits in NEW for a couple month/years or whatever. And yes, i volunteer to help out NEW handling, if that help is wanted. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling ...
On Fri, Mar 18, 2005 at 08:31:51AM +1100, Matthew Palmer wrote: Bollocks. It's the clever people who usually end up overworked, because they can do more critical things with their time. Apparently you don't know what smileys are for. Perhaps you could demonstrate your cleverness by providing ftpmasters with a script to automatically check that the debian/copyright file on a package is reasonably correct. Shouldn't be too hard for a clever fellow such as yourself. Like do a diff of it with the GPL, and reject it if it is not ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling ...
On Fri, Mar 18, 2005 at 09:06:10AM +1100, Matthew Palmer wrote: On Thu, Mar 17, 2005 at 10:15:50PM +0100, Sven Luther wrote: To know in how many packages to split or not to split the packages ? That would be one of the things that maintainers have gotten wrong in the past, yes. So ? Mistakes happen, and people learn from them. The current lesson on gets from this whole mess is to not upload packages which requiere NEW processing. There's also been (to my personal knowledge, since I perpetrated examples of these crimes) problems with debian/copyright where neither a copy of the licence (nor a reference to /usr/share/common-licenses/) under which a package was under weren't listed, and also an issue of section. In each case an ftpmaster (known as Cap'n Satan to some people, apparently) politely explained the problem to me an helped me to rectify the problem. Ok, but not-really-new packages are package who where already in the past in the archive, so this kind of argument is invalid. I mean why reject a package for such bases just because the documentation was split out, or the library got a new soname and thus following policy the source package name needs renaming. They may deserve an RC bug, but not NEW. The ftpmasters have also had to deal with blatantly non-free stuff trying to be put into main, dangerously patent-encumbered stuff going into main, and all forms of bloated and unimpressive stuff floating by. so what, this is hardly relevant to what we are discussing here. For an indication of the sorts of cruft that gets uploaded, take a walk through merkel.debian.org:/org/ftp.debian.org/queue/reject/*.reason. These are the ones that got caught automatically -- but if maintainers can have these sorts of accidents, I see no reason to believe they'll be any more successful stopping other sorts of accidents. so what, define clear rules on what is or not acceptable for package split library/kernel renaming due to new version, and automate it. Automated NEW is IMO a thing we should never do. Semi-automated was the proposal, with a delayed acceptance (a week or so) where the ftp-masters can take positive action to prevent the automated NEW handling. No risk, if a packages is exageratedly splitted, they get the email about it, notice it is exageratedly splitted, and veto it, and normal NEW behavior follows. Would you be happy if the ftpmasters put everything on auto-veto if there was nobody available to monitor the auto-new queue for a few days? If the NEW queue handling people can't get the job done, then they should recruit more people to help out on this instead of making the whole project suffer from their lack of disponibility. We could even imagine an automated analysis, which would differentiate unproblematic modifications (a few new packages of moderate size for example), or policy-mandated NEW (same packages with just a different ABI version number, or a new kernel package), and provide them to ftp-masters via email and a keyword in the subject allowing this classification and easy filtering of problematic packages. I can imagine it, but the heuristics would be tricky at best. But I'm sure you'll have a nicely working demo shortly. we can start with : 1) packages whose source name did not change. these should be basically ok. we check that the amount of binary packages did not grow beyond a given threshold = 20-50 % maybe. 2) packages whose sole modification is the addition or modification of their version or soname-number are autoaccepted, and maybe older versions are marked as candidates for removal. This would probably catch most of those 70 packages waiting currently in NEW and which right now require manual processing and scarcely available ftp-master time. Mmm, i will try to find time to flesh out this proposal and propose code for it. Now if the existing code was written in a reasonable language :) I prefer other people's python to other people's perl. well, if i adapt code or provide patches, it is preferably in a language i know. Perl and python are not among those, so ... This is no critic to the languages chosen, just a maybe inadequacy of myself proposing patches. 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 Thu, Mar 17, 2005 at 09:47:42PM -0800, Steve Langasek wrote: Well, the release team are not the only Debian developers with credibility, surely? Not everything needs to go through us; if the project has the will to do stable releases of these architectures, in spite of the release team being unwilling to delay other architectures while waiting for them, then it should be very possible to provide full stable releases for these architectures. If releases can be made without going through the Release team, then it is not the Release team anymore. Debian is a volunteer project. You are not the Release team by fiat, but because you are doing the work. If you stop working on doing what is generally understood as a Debian release and want to work on a crippled 4-archs releases, it is certainly your right, but you will not be the Release team then. The people working on the real Debian release will be. Debian will not work-around you to release for the other architecture, because you will be irrelevant. And it is not a personnal attack, it is just the way things work. And still Steve and Colin, I think that you have made a wonderful job so far. The Vancouver plan looks like you feel yourself a failure because your initial sarge release plan was stretched unreasonnably, but it is completly unwarranted, and you have shown us all how to handle testing transition in a faster and more controled way several[1] times already, and I am sure we will benefit from this experience in the future. But don't despair! Etch will start on a much more solid ground than Sarge. It is much too soon to give up, Debian has enormous resource that has yet to come into play. Cheers, -- Bill. [EMAIL PROTECTED] [1]several: Hi JoeyH! Imagine a large red swirl here. -- 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!
On Friday 18 March 2005 11:35, Peter 'p2' De Schrijver wrote: Porters who have worked on getting an arch to REGUALR status are in a much better position (demonstrated commitment, technical aptness and experiencewise) to solve those problems than random-joe-developer. I have no idea what you're trying to say here. Always remember that the main reason that it is easier for a porters team to release within the (current) Debian framework than outside is that _others_ do work for them. That has been the case up to now, but won't be the case after sarge. Indeed that is quite the point I wanted to make with the first sentence. Please excuse my inability to express that clearly. I will try again: Up until and including the sarge release, central figures in release management did most of the work that was needed between a arch-fixed upload to unstable and a stable release. Reading the Vancouver-proposal, I come to the conclusion that they recognise that they are not able to make a timely release (sarge demonstrated that quite clearly). Therefore they propose certain criteria a arch should fulfil that they are willing to support a release for the arch. If you try to visualise the effects of that I hope that this will happen: 1) people realize that $arch won't be REGULAR for etch because the people working on a release don't want to handhold it through testing and autobuilding is too slow to properly keep up. 2) people realize that whining and bitching on debian-devel won't convince the people working on a release that $arch is worth the work 3a) people create $arch-specific-release-mechanism on ports.d.o and learn much about the pain of keeping $arch in sync with REGULAR development. 3b) people create security-$arch and take care of packages which are affected by DSAs but are not yet fixed in $arch 4) by going through 3a and 3b people demonstrate commitment and technical aptness as well as gather experience regarding the release cycle. This makes them perfect release and security assistants for $arch. As far as I can tell, Debian on the whole is shortly before ending phase 2 and I have already seen people work on 3a. And if anyone dares to object to point 4 that the current release team should get their act together, because they could just improve $releae-mechanism and release etch with all 15+ arches within the next two years really hasn't understood how Debian works[1]. If this pace keeps up I am convinced that etch will have more than four REGULAR arches. Regards, David [1] ... and should send in some of the stuff he smokes. -- - 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: Do not make gratuitous source uploads just to provoke the bui ldds!
David Schmitt wrote: 1) people realize that $arch won't be REGULAR for etch because the people working on a release don't want to handhold it through testing and autobuilding is too slow to properly keep up. Even not considering the problem I see with the Vancouver proposal regarding Debian identity and quality, I think *this* is one of the greatest problems: how much is this a problem with autobuilding being slow? Autobuilding being slow is a problem that has a number of interesting, _techinical_ solutions as, eg, incremental building, ccache, distcc, etc. And I had not a good answer on why such an important item (KDE taking 12 days to compile on m68k???) was not addressed. A non-clean ccache, keeping .o files between successive would give a lot of boost on this. HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling ...
On 10232 March 1977, Sven Luther wrote: Would you be happy if the ftpmasters put everything on auto-veto if there was nobody available to monitor the auto-new queue for a few days? If the NEW queue handling people can't get the job done, then they should recruit more people to help out on this instead of making the whole project suffer from their lack of disponibility. Read -project and stop whining. -- bye Joerg A.D. 1492: Christopher Columbus arrives in what he believes to be India, but which RMS informs him is actually GNU/India. pgpZvTgznMB3P.pgp Description: PGP signature
Re: NEW handling ...
On Friday 18 March 2005 13:26, Sven Luther wrote: And yes, i volunteer to help out NEW handling, if that help is wanted. Vapourware. I believe that for most packages it is quite easy to see why they are not allowed into unstable. Compile this list+reasons so that everyone who is interested in these packages can quickly see where the problems are. If there is any interest in contents of NEW this list would be very handy to get a quick overview of the problems plaguing NEW packages. Having a website separating the hard cases from the easy ones is the first step needed to get a discussion about the rest going. And discussion in this case doesn't mean posting long rants from the uploaders on d-devel how unfairly the cabal has ignored his package since he uploaded it five years ago to NEW and never cared afterwards. Regards, David -- - 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: Bits (Nybbles?) from the Vancouver release team meeting
Scripsit Anthony Towns aj@azure.humbug.org.au None of those are enough to justify effort maintaining a separate testing-esque suite for them; but surely someone has some better examples they can post... The question is whether the *porters* think they have a sufficiently good reason to do the work of maintaining a separate testing-esque suite. If the porters want to do the work they should be allowed to do it. -- Henning Makholm We will discuss your youth another time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFA: dpatch -- patch maintenance system for Debian source packages
Hello Marc, * Marc Haber [EMAIL PROTECTED] [2005-03-18 13:42]: On Thu, 17 Mar 2005 21:51:45 +0100, Nico Golde [EMAIL PROTECTED] wrote: * Marc Haber [EMAIL PROTECTED] [2005-03-17 21:45]: On Thu, 17 Mar 2005 16:02:16 +0100, Nico Golde [EMAIL PROTECTED] wrote: * Marc Haber [EMAIL PROTECTED] [2005-03-16 15:43]: On Wed, 16 Mar 2005 22:40:33 +0900, Junichi Uekawa [EMAIL PROTECTED] wrote: Since I do care about dpatch, and I do use it a lot in my packages, I will be willing to help out / adopt this package. After organizing on IRC, Junichi and I will take over the package. Gergely has agreed, and an upload will be done in the next seven days. Why do I reply if you don't care about it? Excuse me? Would you care to explain what you mean? I just asked too to be a part of the maintainer team for dpatch. I see. Let me summarize: You post your offer to adopt the package 60 seconds before another team which has already collaborated announces taking over the package, and then bitch about it publicly because the new team didn't reply in time? Sorry maybe it is a misunderstanding. I don't wanted to bitch arount and when did I say something about time? Then you propose doing something which has been done months ago, demonstrating that you didn't look at the package very closely before announcing your intent to adopt. That's a very good way to introduce yourself to your possible future colleague. ? What do you mean. That being said, [EMAIL PROTECTED] exists now. Please subscribe if you want to take part. It will be decided in due time whether more people need what kind of access to the repository and be in Uploaders. Ok. thanks. Regards Nico -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred pgpVOmoyJjmex.pgp Description: PGP signature
Re: RFA: dpatch -- patch maintenance system for Debian source packages
* Marc Haber wrote: Nico Golde [EMAIL PROTECTED] wrote: I just asked too to be a part of the maintainer team for dpatch. I see. Let me summarize: You post your offer to adopt the package 60 seconds before another team which has already collaborated announces taking over the package He posted his offer helping with dpatch _before_ Junichi offered his help on the mailinglist. So, it's a legitimate question why his offer was totally ignored. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Steve Langasek wrote: [snip] How is the layout of scc.debian.org planned to look like? Separate arch.scc.debian.org (or scc.debian.org/arch/...) archives or a single one which needs partial mirroring tricks? Will arch:all be duplicated there or will it need to be fetched from some other mirror? I don't know the details of what's currently planned for the mirror layout. I know that per-arch partial mirroring was a goal at one time, but AIUI the current thought is that a two-way mirroring split should be enough to start with. I don't know the reason for the change, although I suspect that a per-arch mirroring solution, accessible to mirror operators with limited toolkits while not causing needless data duplication, is a difficult set of requirements to code for. Hm, splitting the pool in source/all/arch1/arch2/... has no drawbacks I see immediately. For mirror operators it would mean just a few more rsync lines. The obvious problem is to adapt the archive scripts, I hope it would be a smaller task than the introduction of package pools was. Such a layout would also help for the mainstream architectures, especially when taking the multiarch future into account. A mirror admin only interested in Apple hardware could easily mirror powerpc, ppc64, and i386 (for emulations), without much rsync fighting to get rid of all the pieces for amd64/ia64/whatever. Currently, the attempt to exclude arch-specific stuff in dist turns the mirror script into a mess. The master archive would then be ports.debian.org, with an layout of ports.debian.org `-- debian |-- all | |-- dists | `-- pool |-- arch1 | |-- dists | `-- pool |-- arch2 | |-- dists | `-- pool ... |-- archN | |-- dists | `-- pool `-- source |-- dists `-- pool Keeping the same layout as today below dists and pool might be aesthetically unpleasing, but it makes the transition surely easier, and it allows to re-create a combined pool easily. This can be important to avoid changes in the sources.list for many deployed systems. (That is, ftp.debian.org would be created from a selection of architectures of ports.debian.org, but with the same layout as today.) [snip] The increased number of source packages could be alleviated by purging binary packages automatically (with an advance warning) from testing if the best effort turns out to be not timely enough. I'm thinking of something like: - Source wasn't referenced for 2 weeks by any release candidate distribution - warning - After 4 weeks - removal of the corresponding binaries This means weeding out obsolete source packages needs at least a 4 week freeze, which seems to be the minimum anyways. If an SCC testing repository gets badly out of shape (== lots of uninstallable packages), dropping it means simply stopping the testing migration and/or clearing the Packages.gz, depending on the future prospects to get the work done. If a port is going to try to keep up with the release, then I think it should go all the way; if we're going to constrain the new versions of the package that are allowed into testing based on what the core RC archs are doing, then I think you also have to consider just kicking the arch out of testing completely when it starts lagging behind this badly. Is a port that lags 4 weeks behind a package on any kind of regular basis actually going to be useful once it's tagged stable? 4 weeks is barely as long as we're allowing for the sarge freeze, and *every* upload during that period is likely to be an RC bugfix that architectures would want to keep up with. If such a problem occurs regularily, then we need some better way to restrict the port to a subset of packages than what's currently done via P-a-s, true. Daniel Jacobowitz' idea of subtesting looks like a solution. Thiemo signature.asc Description: Digital signature
Re: NEW handling ...
And yes, i volunteer to help out NEW handling, if that help is wanted. Just for the record, not to anyone directly, it just fits here: This is not how it works. Offering something randomly and then sitting back waiting, later maybe complaining offer wasnt accepted. The way I got into the ftpteam was simple to do the work. ssh to merkel, looking at the changes files if I find a reason for the package to go out of new, compiling a list of stuff, feeding it to one of the guys who could run lisa on it. Done that a few times with some long lists, got some packages out of NEW. Now I do it myself... So, If you want anything to be done: Dont write mails about it how it could be done, just do it, anything else is just to be treated as the stuff our politicians say... -- bye Joerg It's not that I'm afraid to die, I just don't want to be there when it happens. -- Woody Allen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Michael K. Edwards wrote: [snip] That leaves mips (big-endian), hppa, alpha, and s390. Not so much doorstops as space heaters; some people might put ia64 in this category too. FWIW, the distinction between mips and mipsel isn't that clear-cut. All MIPS CPUs (except the R8000) can run in big and little endian mode, this is decided by the firmware the system runs. Modern MIPS devices supposed to run WinCE ff. are little endian, other stuff which fits the label consumer electronics tends to be little endian as well. For network devices, big endian seems to be more popular. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFA: dpatch -- patch maintenance system for Debian source packages
* Norbert Tretkowski wrote: * Marc Haber wrote: Nico Golde [EMAIL PROTECTED] wrote: I just asked too to be a part of the maintainer team for dpatch. I see. Let me summarize: You post your offer to adopt the package 60 seconds before another team which has already collaborated announces taking over the package He posted his offer helping with dpatch _before_ Junichi offered his help on the mailinglist. But his mail arrived on this list indeed after Junichis mail. My fault, sorry. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Debian DPL Debate Comments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello People, It was really a good time going through the logs of the Debian DPL Debate. I was quite happy that the organizers brought up the issue of Under-represented Groups In Debian. 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. Things which are complete and too much to scare me. Eg. Debian New Maintainer Guidelines. I do know that there are other ways also, besides being a DD, to contribute to Debian. But there isn't a formal written way. There, maybe, should be an official responsibility for DD's to work closely with people who are willing to contribute to Debian. As for example, it's been now around 7 years for me now using Linux and I do have a fair amount of knowledge now. It would be great if DD's here could harness the skills in wannabe contributors like us and prepare us help this marvelous community. In particular to me, I'm willing to contribute to Debian as maybe a DD, Package Maintainer, SysAdmin or any other work you people find as an undiscovered skill in me. Look forward for guidelines from all of you. Note: Please CC me. I'm not on the list now. Regards, Ritesh - -- Ritesh Raj Sarraf RESEARCHUT -- http://www.researchut.com Gnupg Key ID: 04F130BC Stealing logic from one person is plagiarism, stealing from many is research. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCOwBR4Rhi6gTxMLwRAvMwAJoDqazX6UPvp/nYWqF66dLCE4xcXACcCt/L NDSGPcv+v6xT8G5NHBe0bkU= =s8eQ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: status of buildds?
On Thu, Mar 17, 2005 at 12:21:15AM -0800, Thomas Bushnell BSG wrote: ... Catchup has started to make some progress; the current disaster buildd seems to be arm, now that mipsel has mostly caught up and s390 has turned around. So long as at least a single buildd arch is having trouble, we are all penalized. Are there any reasons why you are all penalized that are not only imposed by testing? 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 Thu, Mar 17, 2005 at 09:47:42PM -0800, Steve Langasek wrote: On Mon, Mar 14, 2005 at 07:59:43PM +, Alastair McKinstry wrote: AFAI can tell, anybody can host an archive of packages built from stable sources for a scc or unofficial port. And - if I read the conditions on becoming a fully supported Debian arch right - then having security support for an external pool of this arch is a good indicator that it should be a fully supported stable release (amongst other things). The plan as proposed is that the Debian scc ports are purely builds of unstable. Hence this build out of the last release (e.g. etch) becomes a subproject of a second-class project of Debian. It effectively has little credibility. Well, the release team are not the only Debian developers with credibility, surely? Not everything needs to go through us; if the project has the will to do stable releases of these architectures, in spite of the release team being unwilling to delay other architectures while waiting for them, then it should be very possible to provide full stable releases for these architectures. ... Which delays are expected for etch, that are not only imposed by the usage of testing for release purposes? [1] I do still doubt that testing actually is an improvement compared to the former method of freezing unstable, and even more do I doubt it's worth sacrificing 8 architectures. Steve Langasek cu Adrian [1] The installer might be a point, but since all sarge architectures will have a working installer and I hope there's not another installer rewrite planned for etch this shouldn't be a big issue. -- 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 Fri, Mar 18, 2005 at 05:43:26PM +0100, Adrian Bunk wrote: [1] The installer might be a point, but since all sarge architectures will have a working installer and I hope there's not another installer rewrite planned for etch this shouldn't be a big issue. This is still an issue. Joey Hess's mails have indicated very clearly that it's difficult to get an installer release out even when all arches are already supported. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Anthony Towns schrieb: Sven Luther wrote: I think the main reply is for developers using said archs. Developers *developing* on those architectures need to use unstable anyway. If there aren't any users, then there's no much point doing any development. Are there any users? If so, what are they doing? Keep in mind that some of us are not allowed to talk in public about what we're running on our boxes. Cheers, aj grets Uwe -- Jetzt will man das Internet nicht einfach ein paar Leuten wie der IETF überlassen, die wissen, was sie tun. Es ist zu wichtig geworden. - Scott Bradner http://www.highspeed-firewall.de/adamantix/ http://www.x-tec.de
Re: Debian DPL Debate Comments
Hello Ritesh, * Ritesh Raj Sarraf [EMAIL PROTECTED] [2005-03-18 17:55]: [...] 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. Things which are complete and too much to scare me. Eg. Debian New Maintainer Guidelines. It is very much work to get involved in maintainership but that should be a guarantee of good quality. I do know that there are other ways also, besides being a DD, to contribute to Debian. But there isn't a formal written way. Yes. Just subscribe to the mailing list of projects in which you are interrested and just talk to other people. Maybe ask them if they need help. There, maybe, should be an official responsibility for DD's to work closely with people who are willing to contribute to Debian. Its not exactly someone but e.g. for maintainer stuff there is the debian-mentors list. [...] regards nico -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred pgpMoaq2Wbkdo.pgp Description: PGP signature
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Fri, Mar 18, 2005 at 12:06:15PM -0500, David Nusinow wrote: On Fri, Mar 18, 2005 at 05:43:26PM +0100, Adrian Bunk wrote: [1] The installer might be a point, but since all sarge architectures will have a working installer and I hope there's not another installer rewrite planned for etch this shouldn't be a big issue. This is still an issue. Joey Hess's mails have indicated very clearly that it's difficult to get an installer release out even when all arches are already supported. You are referring to his email regarding problems with getting updates kernel images for all architectures? I agree that's a point. But this problem is already being attacked by the kernel team. There are also other areas where work on the installer might be easier if fewer architectures were supported, but are they heavy enough for dropping two thirds of the Debian architectures - or are they issues where improvements were possible? - David Nusinow 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 18-Mar-05, 05:22 (CST), Anthony Towns aj@azure.humbug.org.au wrote: Sven Luther wrote: I think the main reply is for developers using said archs. Developers *developing* on those architectures need to use unstable anyway. I think he's talking about people developing products for those archs, not Debian Developers. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On 18-Mar-05, 03:28 (CST), Blars Blarson [EMAIL PROTECTED] wrote:
Linux fails this. Even with forwarding disabled, it will accept packets
for an address on interface A via interface B.
Enable rp_filter and it does reject such packets.
echo 1 /proc/sys/net/ipv4/conf/${dev}/rp_filter
See, that's a nice theory, but it doesn't actually work.
Maybe it's not clear what I'm talking about. Consider a machine with two
interfaces eth0, eth1. Define eth0 as 192.168.0.1 and eth1 as 10.0.0.1.
Disable forwarding, set rp_filter on all interfaces. From another
machine on 192.168.0/24, set your route for 10/8 to 192.168.0.1. Now
ping 10.0.0.1. For bonus points, do 'ifconfig eth1 down', and then ping
from the other machine again. Surprise!
(All with 2.4.18, maybe it's fixed in 2.6.)
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: arch-specific packages and the new SCC requirements
On Mar 16, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: The Debian Hurd project has another category that should be excluded because they are kernel-specific. (The current list on the web page is update, makedev, ld.so, modconf, modutils, netbase, pcmcia-cs, procps, ppp, pppconfig, setserial. There are surely more.) I suppose that Hurd will have its own packages which implement these functions, so the number should even out among different architectures. -- ciao, Marco signature.asc Description: Digital signature
Re: Bits (Nybbles?) from the Vancouver release team meeting
I demand that Anthony Towns may or may not have written... [snip] At the moment, the only use cases I'm confident exist are: [snip] arm: We're developing some embedded boxes, that won't run Debian proper, but it's really convenient to have Debian there to bootstrap them trivially. Desktop ARM-based machines: URL:http://www.iyonix.com/ Will run Debian: URL:http://www.iyonix.com/linux.html [snip] I'm speaking only for myself; please, cure my naivety. The above links should help :-) [snip] -- | Darren Salt | nr. Ashington, | linux (or ds) at | woody, sarge, | Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk | Oh, sarge too... Look, sir! 'Droids! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: announcing first release of common database infrastructure package
Hello On Mon, Mar 07, 2005 at 08:28:39AM -0500, sean finney wrote: hi martin, On Mon, Mar 07, 2005 at 01:23:51PM +1300, Martin Langhoff wrote: sounds really good. How do your scripts relate to the db management scripts provided by wwwconfig-common, maintained by Ola Lundqvist [EMAIL PROTECTED]? my code is a superset of what's done in wwwconfig-common. providing the scripts/code to manage databases is only half of the idea behind this project. the other half is providing a normalized method for doing so (that is, not just the scripts, but debconf questions, translations, and a pre-arranged set of code for each maintainer script). This sounds really great (as I'm the wwwconfig-common maintainer) ! I assume that this means that my plans to get rid of the wwwconfig-common package is in plan. I suspect your package should be either supercede wwwconfig-common or be rolled into it. this supercedes what's in wwwconfig-common. in fact, much of the underlying internal code is taken from or at least originally based on code from that package. Nice. There are two major parts of wwwconfig-common: 1) Database management, which now (finally) seem to be superseeded by another package. 2) Apache configuration, which is already superseeded as the apache configuration have support for config.d (etc) structure that make this part of wwwconfig-common unnecessary. I actually recommend people not to use it anymore. I think I have removed it from all my web packages, but I'm not sure. There are some other minor things like exim config but that has been superseeded a long time ago, as exim3 is not a default MTA. I greatly appriciate your work! For you who do not know. I wrote wwwconfig-common for one single purpose. To be a common part for the configuration of the imp and horde packages, so that I did not duplicate too much code there. And now quite a lot of packages use it. :) I have actually thought of splitting off the two parts of the configuration types to separate packages and creating a common configuration framework. I think I have mentioned this on mailinglists a couple of times. The problem is that I have not really done anything, so it has been just an idea for years. Best reagards, // Ola sean -- -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another load of typos
Steve Langasek [EMAIL PROTECTED] writes: On Thu, Mar 17, 2005 at 09:04:14AM -0800, Thomas Bushnell BSG wrote: Hamish Moffatt [EMAIL PROTECTED] writes: (This might be a topic without a possible conclusion!) Funny, but although I'd say an HTML file or an HTTPS url or similar, I'd say a history achievement. Ah, in a history achievement, you accent the first syllable of history, which provokes you to pronounce the H. In an historic achievement, the first syllable of historic is weak, and so most Americans (at least) do not pronounce the H, and so we use an. The only people I can recall ever hearing say an historic in en_US were idiot politicians, and they *did* pronounce the initial h. For that matter, I can't recall ever hearing anyone drop an initial h just because the syllable was unstressed. On what do you base this claim of most? The ones you speak of, who say an historic where they *are* aspirating the H are not only idiot politicians, but they're in the set. Yes, that's a silly usage for Americans, though it was correct for some dialects in England not to long ago. I can't speak about now. But an historic with no aspirated H, hrm, I hear it all the time. But it's not easy to hear if you start thinking carefully now how do I pronounce this, because people generally have two ways to pronounce words and phrases; one in rapid speech, and one when they are speaking carefully and distinctly. The way to tell is to start listening to people, or better, give them a paragraph of text to read aloud. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
[EMAIL PROTECTED] (Marco d'Itri) writes: On Mar 17, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: However, we are not expecting the DSA people to keep the system secure; SCC non-released arches don't need to provide developer machines. I do not believe that this is limited to debian hosts. If an OS lacks the basic security features needed to safely stay on the internet then I think it's obvious that it's not mature and useful enough to be worth keeping it in the archive. Once more, we are lacking the actual information here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: arch-specific packages and the new SCC requirements
[EMAIL PROTECTED] (Marco d'Itri) writes: On Mar 16, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: The Debian Hurd project has another category that should be excluded because they are kernel-specific. (The current list on the web page is update, makedev, ld.so, modconf, modutils, netbase, pcmcia-cs, procps, ppp, pppconfig, setserial. There are surely more.) I suppose that Hurd will have its own packages which implement these functions, so the number should even out among different architectures. Well, sort of. Of that list: update, makedev, procps, ppp [and hence pppconfig], and setserial are unneeded, because features therein are provided in different ways, in already existing packages. For example, Hurd filesystems sync themselves, not needing a separate program the way Unix does, so update is unnecessary. Likewise, the Hurd doesn't use a /proc filesystem, and so it doesn't need special utilies for it. modconf and modutils are kernel-specific; Mach doesn't have loadable kernel modules (though it would be nice if it did), but this doesn't mean there is some bug. On the other hand, the Hurd has some packages that Linux is incapable of running too. It might be that *that* would balance out. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
iyonix [was Re: Bits (Nybbles?) from the Vancouver release team meeting]
On Fri, Mar 18, 2005 at 08:19:14PM +, Darren Salt wrote: I demand that Anthony Towns may or may not have written... [snip] At the moment, the only use cases I'm confident exist are: [snip] arm: We're developing some embedded boxes, that won't run Debian proper, but it's really convenient to have Debian there to bootstrap them trivially. Desktop ARM-based machines: URL:http://www.iyonix.com/ Will run Debian: URL:http://www.iyonix.com/linux.html Is it possible to get one or two to run as buildd and/or developer machine ? Being stuck with netwinder when XScale are available is a bit like trying to build Debian on a 586. Maybe we should contact them ? They are certainly interested in Debian supporting their hardware. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dropping testing (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Thu, Mar 17, 2005 at 09:39:10PM +0100, David Schmitt wrote: On Thursday 17 March 2005 00:21, Adrian Bunk wrote: On Wed, Mar 16, 2005 at 07:51:16PM +0100, David Schmitt wrote: libraries transitioned is a big point against testing: 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. Which leaves one with the problem that the new library might break any or all of the depending packages, which testing would catch, while transitioning unstable might not. But I have to admit that I didn't follow debian development as closely as I do now in the times before testing and thus might be arguing against the wind. This is possible (but see your own comment below). The bigger problems from the point of view of users aren't transitions (which usually go smooth - you simply have two versions of a library installed) but breakages like accidential ABI changes without an so-name change. These aren't necessarily caught be testing (except through the RC bug count), and libtiff is a good example where such a usere-visible problem made it into testing. Perhaps the best would be to prepare the transition beforehand in experimental and push the packages together into unstable, like GNOME and KDE did their respective last big updates? This also would be a step towards reducing dependency on work from the central teams. That's a good idea and already done. But this is independent of the question whether testing is present or not. Regards, David 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: Do not make gratuitous source uploads just to provoke the bui ldds!
On Fri, Mar 18, 2005 at 10:31:19AM -0300, Humberto Massa wrote: David Schmitt wrote: 1) people realize that $arch won't be REGULAR for etch because the people working on a release don't want to handhold it through testing and autobuilding is too slow to properly keep up. Even not considering the problem I see with the Vancouver proposal regarding Debian identity and quality, I think *this* is one of the greatest problems: how much is this a problem with autobuilding being slow? Autobuilding being slow is a problem that has a number of interesting, _techinical_ solutions as, eg, incremental building, ccache, distcc, etc. And I had not a good answer on why such an important item (KDE taking 12 days to compile on m68k???) was not addressed. A non-clean ccache, keeping .o files between successive would give a lot of boost on this. Clearly, you have no concept of how much source passes through unstable each day, and how big a ccache would have to be to be useful on a buildd... -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
[Proposal] $arch release assistants
Hello Debian-developer, I have a modest proposal to reduce the burden of the multiple architectures on the Release team. This is based on the following assumptions: I) The main problem is missing builds that slow down propagation to testing. II) Such problems are linked to buildd breakages that can happen at random time. The idea is to have or each architecture $arch a '$arch release assistant' which is in charge of helping the release team with issue specific to a port. As I see it: 1) The $arch release assistant is not a buildd admin. 2) The $arch release assistant is trusted by the buildd admin and ftp-masters for the purpose of making binary upload (See [1] why it is important). 3) The $arch release assistant monitor debian-release to detect when missing $arch builds are needed to propagate fix for RC bug to testing. When this happen (normally because of buildd outage) they fast-track the package (e.g. by building the package on their box) to make the transition faster. 4) Preferably, they can manage a buildd when the buildd admin is in holiday, but this is not needed from the start. 5) The $arch release assistant helps the release team dealing with architecture specific issues in upgrades (e.g kernel upgrade needed before a woody-to-sarge upgrade on some platform). The issues to address for this scheme to work: A) The point (2) needs a protocol for building binary outside official buildds that is approved by the ftp-masters. B) There is a trust to establish between buildd admin/ftp-masters/release team and the $arch release assistant. C) Volunteers are needed. I thing A) and B) can be solved with a bit of good-will from all part. C) should not be a problem unless the port is dead. The difficulty is to have C) and B) at the same time. I hope we are reasonable people. Cheers, -- Bill. [EMAIL PROTECTED] [1] http://lists.debian.org/debian-ctte/2004/12/msg1.html (Apologies to Blars). Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Accepted valknut 0.3.7-1 (i386 source)
Hi Pasi, On Friday, 18 Mar 2005, you wrote: Changes: valknut (0.3.7-1) unstable; urgency=high . * New upstream release (Closes: #289643, #269952, #265284, #270096, #286234) is there any reason for not giving some more explanation, when closing bugs with urgency=high and only listing New upstream release as only changelog entry. I would like to have some more explanation for this in the changelog. Also Debian Developers reference 6.3.1 gives some good advice on Writing useful changelog entries. Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: iyonix [was Re: Bits (Nybbles?) from the Vancouver release team meeting]
Bill Allombert wrote: On Fri, Mar 18, 2005 at 08:19:14PM +, Darren Salt wrote: I demand that Anthony Towns may or may not have written... [snip] At the moment, the only use cases I'm confident exist are: [snip] arm: We're developing some embedded boxes, that won't run Debian proper, but it's really convenient to have Debian there to bootstrap them trivially. Desktop ARM-based machines: URL:http://www.iyonix.com/ Will run Debian: URL:http://www.iyonix.com/linux.html Is it possible to get one or two to run as buildd and/or developer machine ? Being stuck with netwinder when XScale are available is a bit like trying to build Debian on a 586. Maybe we should contact them ? They are certainly interested in Debian supporting their hardware. It'd be more useful getting the existing offered hardware up and running before asking for more. We have several arm boxes waiting to be used... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] This dress doesn't reverse. -- Alden Spiess -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Alternative: Source-Centric Approach [w/code]
Matthias Urlichs dijo [Tue, Mar 15, 2005 at 11:14:50PM +0100]: It won't work that well for slower architectures, for the very simple reason that compiling everything would take a long time. m68k (as the admittedly extreme example) doesn't have ten buildd boxes just because we feel like it. :-) Being m68k among the prime candidates for SCC, why shouldn't we ponder using emulated autobuilders? We have some quite decent and reliable emulators in our archive for some architectures (i.e., basilisk2 for m68k [in contrib because of the needed Mac ROMs], hercules for s390), and they do work reliably. (BTW: I have had for a couple of months a Mac Quadra 950 sitting in my house... It seems to work, but I have had no time to set it up :-/ ) Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Emulated buildds (for SCC architectures)?
Hi, I haven't followed as thoroughly as I would have liked the recent verborrhea in the list regarding the Vancouver proposal. Anyway, I'd like to raise a point that I brought up during Debconf3, in the light of the changes that we are now facing. Most (although not all) of the architectures facing being downgraded are older, slower hardware, and cannot be readily found. Their build speed is my main argument against John Goerzen's proposal [1]. Now, I understand that up to now we have had the requirement of the builds running in the real hardware. Nowadays, an i386 system emulating a m68k (using either UAE or Basilisk2) is at least comparable to the fastest m68k system ever produced. I have worked with both emulators, and both seem completely safe - Yes, I know we cannot run Debian on a regular UAE because of the lack of a MMU in the official package, but we _can_ run it inside Basilisk2. A completely different problem with the same results arises when using s390 machines: As someone noted recently, most of us cannot afford having a s390 running in the basement. But AFAICT, Hercules is a quite usable s390 emulator. 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? Greetings, [1] http://lists.debian.org/debian-devel/2005/03/msg01387.html -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emulated buildds (for SCC architectures)?
Gunnar Wolf wrote: SNIP Nowadays, an i386 system emulating a m68k (using either UAE or Basilisk2) is at least comparable to the fastest m68k system ever produced. I have worked with both emulators, and both seem completely safe - Yes, I know we cannot run Debian on a regular UAE because of the lack of a MMU in the official package, but we _can_ run it inside Basilisk2. SNIP AIUI, qemu is pretty good with arches that it does support. That is another possibility. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
Re: Emulated buildds (for SCC architectures)?
On Fri, Mar 18, 2005 at 08:06:47PM -0600, Gunnar Wolf wrote: Hi, I haven't followed as thoroughly as I would have liked the recent verborrhea in the list regarding the Vancouver proposal. Anyway, I'd like to raise a point that I brought up during Debconf3, in the light of the changes that we are now facing. Most (although not all) of the architectures facing being downgraded are older, slower hardware, and cannot be readily found. Their build speed is my main argument against John Goerzen's proposal [1]. Now, I understand that up to now we have had the requirement of the builds running in the real hardware. Nowadays, an i386 system emulating a m68k (using either UAE or Basilisk2) is at least comparable to the fastest m68k system ever produced. I have worked with both emulators, and both seem completely safe - Yes, I know we cannot run Debian on a regular UAE because of the lack of a MMU in the official package, but we _can_ run it inside Basilisk2. A much faster solution would be to use distcc or scratchbox for crosscompiling. A completely different problem with the same results arises when using s390 machines: As someone noted recently, most of us cannot afford having a s390 running in the basement. But AFAICT, Hercules is a quite usable s390 emulator. 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). ARM is supported by both qemu and scratchbox, so you could do a cross compiling buildd without needing actual ARM hardware (scratchbox normally uses a target board to run generated binaries during the buildprocess, but it can also use qemu). OTOH Intel's IOP Xscale series is quite fast and there are faster ARMs coming, so it's probably not necessary to use crosscompiling to keep up. Alpha and Sparc should be fast enough to keep up. 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? If you don't tell people, how would they know ? :) Cheers, Peter (p2). signature.asc Description: Digital signature
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mar 18, Steve Langasek [EMAIL PROTECTED] wrote: There would definitely be duplication of arch:all between ftp.debian.org and ports.debian.org (let's call it ports), as well as duplication of the source. As a mirror operator, I think that this sucks. Badly. -- ciao, Marco signature.asc Description: Digital signature
Re: Bits (Nybbles?) from the Vancouver release team meeting
Michael K. Edwards wrote: AJ's categorization has some traction, but I think it's a somewhat short-term perspective. I was kind-of hoping it wasn't even that: we've been supporting all these architectures for over two years now; are they really completely useless? I think Sarge on ARM has the potential to greatly reduce the learning curve for some kinds of embedded development, especially if Iyonix succeeds in its niche (long live the Acorn!). So, I looked at the website, but all I can see are expensive PCs that happen to have an arm chip. 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 -- and if an arch is just going to be used for development, does it really need all the support we give stable in order to make it useful for servers and such? If so, why? If not, what level of support does it need, that goes beyond unstable + snapshotting facility, and why? Debian developers manage to develop on unstable fairly well, eg, why isn't that enough? Is this just a PR issue, in that unstable and snapshot aren't something you can put on a brochure or brag about on slashdot? Seriously, I'm not really looking for comparisons to i386 (least of all in the but i386 will be dead soon too! sense), just Yeah, we use these machines for this purpose; we're serious about it for these reasons; we need this level of support from our OS vendor because of these considerations (and, eg, FooBar provides it thus...). I guess this is really the wrong place to ask for we use these machines answers instead of we develop for these machines, but hey. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Henning Makholm wrote: The question is whether the *porters* think they have a sufficiently good reason to do the work of maintaining a separate testing-esque suite. If the porters want to do the work they should be allowed to do it. If they don't need any support from anyone else, they're welcome to do whatever they like. If they want other people to help them, I don't think it's unreasonable to expect an answer to a What's the point? question. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emulated buildds (for SCC architectures)?
Peter 'p2' De Schrijver dijo [Sat, Mar 19, 2005 at 03:41:46AM +0100]: Nowadays, an i386 system emulating a m68k (using either UAE or Basilisk2) is at least comparable to the fastest m68k system ever produced. I have worked with both emulators, and both seem completely safe - Yes, I know we cannot run Debian on a regular UAE because of the lack of a MMU in the official package, but we _can_ run it inside Basilisk2. A much faster solution would be to use distcc or scratchbox for crosscompiling. Yes, but the argument against cross-compiling has always been stronger - If you are compiling under an emulator, you can at least test the produced binaries under that same emulator, and you have a high degree of confidence that they work reliably (this is, if an emulator bug leads to gcc miscompiling, it'd be surprising if it allowed for running under the emulator). Using cross-compilers you can't really test it. And, also an important point, you can potentially come up with a resulting package you could not generate in the target architecture. But, yes, I'd accept a cross-compiler as a solution as well in case we could not run an emulator for a given slow platform. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emulated buildds (for SCC architectures)?
Peter 'p2' De Schrijver [EMAIL PROTECTED] writes: A much faster solution would be to use distcc or scratchbox for crosscompiling. Debian packages cannot be reliably built with a cross-compiler, because they very frequently need to execute the compiled binaries as well as just compile them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: my thoughts on the Vancouver Prospectus
[cc:ed back to -devel, since these are technical questions being raised and answered] 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, and b) definitely too slow in terms of single-package build times to avoid inevitably delaying high-priority package fixes for RC bugs. - 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. 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. - While neither of the above concerns is overriding on its own (the ftpmasters have obviously allowed these ports to persist on ftp-master.debian.org, and they will be released with sarge), there is a general feeling that twelve architectures is too many to try to keep in sync for a release without resulting in severe schedule slippage. Pre-sarge, I don't think it's possible to quantify slippage that's preventible by having more active porter teams vs. slippage that's due to unavoidable overhead; but if we do need to reduce our count of release archs, and I believe we do, then all other things being equal, we should take issues like the above into consideration. * Three bodies (Security, System Administration, Release) are given independent veto power over the inclusion of an architecture. A) Does the entire team have to exercise this veto for it to be effective, or can one member of any team exercise this power effectively? It's expected that each team would exercise that veto as a *team*, by reaching a consensus internally. B) Is the availability of an able and willing Debian Developer to join one of these teams for the express purpose of caring for a given architecture expected to mitigate concerns that would otherwise lead to a veto? Without knowing beforehand what the reason for the veto would be (and if we knew, we would list them explicitly as requirements), this isn't possible to answer. C) How often can/should these bodies be petitioned for a reconsideration of their veto in light of underlying changes in circumstance? In general, I think we would want to see some evidence that the porter team is able to address the objections over the long term, so probably showing that the concerns have been resolved for a month prior to requesting a review would be reasonable. D) How will the exercise of a veto be communicated to the Project? An announcement mail with Subject: Vancouvered: $arch, of course. * The guidelines for eligibility as a released architecture, and for inclusion in SCC, could be initially met, but later fail. For example, an architecture could fall below the 98% up-to-date mark. Does this spell automatic expulsion from the slate of releasable architectures? Similarly, for how long are the petitions for inclusion in SCC (5 developers and 50 users) assumed to remain valid? I could only imagine enforcing either of these rules against a previously RC arch when it starts adding to the release team's workload by falling behind. I think it would be quite worthwhile for a FAQ to be maintained on the Debian Wiki, so that answers to these and other questions can be collected. As a matter of fact, I just started one[3]. Feel free to incorporate the above answers into that page; as noted before, I don't think a wiki is a very effective tool for ongoing discussions. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Required firewall support
Joel Aelwyn dijo [Wed, Mar 16, 2005 at 08:39:48PM -0700]: Consider: * SCC systems have buildds. * Buildds must be network accessible. * The first rule of securing a machine exposed to the wilds is Deny by default, allow by need. Therefore, a box which does not provide basic firewalling capabilities (whether that's achieved by configurable ACLs, mind-reading the human traffic trigger, or pixies inspecting every packet) is thus not suitable for running a buildd on, and thus can never achieve SCC status. Sorry, but being able to cope with a hostile environment *is* a requirement in today's network, and there isn't any real way around that fact. I have no clue where Hurd network filtering stands at the moment, so I can't comment on how far it is from having this feature. I wouldn't be willing to admin any such box that was plugged into a network using a ten foot pole, and I don't see why the DSA folks should be expected to either. I would admin such a machine precisely by using a ten foot pole - That ten foot pole can be materialized into a firewall-able machine sitting between it and the network. I agree that any Debian architecture needs to provide basic networking facilities, but I don't think firewalling is a real requirement. Yes, of course, we expect users to actually _run_ this architecture, and they will probably be connected to the network, and thus they can be at risk - But right now Debian installs are done with no firewalling rules on anyway. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
Gunnar Wolf [EMAIL PROTECTED] writes: I agree that any Debian architecture needs to provide basic networking facilities, but I don't think firewalling is a real requirement. Yes, of course, we expect users to actually _run_ this architecture, and they will probably be connected to the network, and thus they can be at risk - But right now Debian installs are done with no firewalling rules on anyway. Moreover, the question here is not what are good features to have, but what are the features necessary for SCC (or ports, or whatever it's called). Non-released ports don't need buildds run by the Debian system administrators, and don't need lots of them; the point is that porting teams need to be making real progress to be in SCC, but not done. So I'm mostly fine with the requirements as written, but the question still remains: What features, exactly, are meant by firewalling support in the requirement? (I know what firewalling is as a general thing, but not which specific features are desired.) And, why is firewalling support essential for SCC? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
[EMAIL PROTECTED] (Marco d'Itri) writes: On Mar 18, Steve Langasek [EMAIL PROTECTED] wrote: There would definitely be duplication of arch:all between ftp.debian.org and ports.debian.org (let's call it ports), as well as duplication of the source. As a mirror operator, I think that this sucks. Badly. So don't duplicate ports. That's the whole point. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Anthony Towns aj@azure.humbug.org.au wrote: So, I looked at the website, but all I can see are expensive PCs that happen to have an arm chip. 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 -- and if an arch is just going to be used for development, does it really need all the support we give stable in order to make it useful for servers and such? If so, why? If not, what level of support does it need, that goes beyond unstable + snapshotting facility, and why? Debian developers manage to develop on unstable fairly well, eg, why isn't that enough? Is this just a PR issue, in that unstable and snapshot aren't something you can put on a brochure or brag about on slashdot? This is very much a What should Debian be question, and I don't think trying to answer it along purely practical lines is reasonable. A moderately large number of our developers have become involved *because* we support these niche architectures - how do we reasonably quantify that and compare it to the effort required to keep them up to date? I do very much sympathise with the idea that expecting the release team to carry the burden of looking after under-maintained architectures is entirely unreasonable, but that doesn't mean that the only two choices are to drop architectures or to give up on releasing. We have more choices than that, we're just not sure how practical they are yet. I'm not going to agree with any Oh, it's hard to release this many architectures argument - I /will/ agree with This architecture is holding us back, so we should drop it. Debian is a community project. Many people are involved because they want to be, not because they need to be. Implying that their work isn't massively useful isn't helpful, and may well have the effect of discouraging people who /aren't/ working on the potentially affected ports. If we're going to fail to release architectures, then let's base this on technical grounds rather than I don't see any real reason why you need to release this architecture. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: iyonix [was Re: Bits (Nybbles?) from the Vancouver release team meeting]
Bill Allombert [EMAIL PROTECTED] wrote: Is it possible to get one or two to run as buildd and/or developer machine ? Being stuck with netwinder when XScale are available is a bit like trying to build Debian on a 586. There's no shortage of ARM hardware available to Debian, but so far it hasn't been added to the buildd setup. I'm not clear on the reasons for this. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The 98% and N=2 criteria (was: Vancouver meeting - clarifications)
Frank Küster dijo [Tue, Mar 15, 2005 at 02:15:15PM +0100]: This whole argument is bogus. Up to before Vancouver, we always said: A package should be Architecture: any if it can in principle be compiled on every arch; the fact that it might not be useful there does not justify excluding it from that arch. And AFAIK the rationale for this was overall quality of the distribution. Now with the requirement for 98% compiled (and N=2 buildd's being able to take the workload) the focus has shifted: From overall quality to timely release and quality of individual architectures. (...) Ummm... What do you think about this: 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 ;-) ) Would such a measure be enough for you? Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: my thoughts on the Vancouver Prospectus
On Fri, 2005-03-18 at 18:44 -0800, Steve Langasek wrote: D) How will the exercise of a veto be communicated to the Project? An announcement mail with Subject: Vancouvered: $arch, of course. Snort Damn, I love this list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: my thoughts on the Vancouver Prospectus
Steve Langasek [EMAIL PROTECTED] wrote: - While neither of the above concerns is overriding on its own (the ftpmasters have obviously allowed these ports to persist on ftp-master.debian.org, and they will be released with sarge), there is a general feeling that twelve architectures is too many to try to keep in sync for a release without resulting in severe schedule slippage. Pre-sarge, I don't think it's possible to quantify slippage that's preventible by having more active porter teams vs. slippage that's due to unavoidable overhead; but if we do need to reduce our count of release archs, and I believe we do, then all other things being equal, we should take issues like the above into consideration. This, uh, sounds very much like We need to drop architectures, and so we have come up with these criteria that will result in us dropping architectures. Which is a reasonable standpoint to take, but which also seems to imply that if 12 architectures manage to fulfil all the criteria, we'll need to come up with some new criteria to ensure that the number drops below 12 again. If this is the case, I think that needs to be made clearer to avoid situations where people work to meet the criteria but are vetoed by the release team because there are already too many architectures. I'm not massively keen on this - it ends up sounding a bit too much like dead man's shoes. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300341: ITP: 855resolution -- resolution modify tool for Intel graphic chipset
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: wnpp Severity: wishlist * Package name: 855resolution Version : 0.3-1 Upstream Author : Alain Poirier alain.poirier1 at wanadoo.fr * URL or Web page : http://perso.wanadoo.fr/apoirier/ * License : public domain (see below) Description : resolution modify tool for Intel graphic chipset license detail: /* = * This source code is into the public domain. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR THE CONTRIBUTORS BE * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE * OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN * IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * = */ This software changes the resolution of an available vbios mode. It will work with Intel 845G/855GM/865G. You can get and test from http://www.debian.or.jp/~kmuto/855resolution/ Thanks, - -- Kenshi Muto [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iEYEARECAAYFAkI7vVgACgkQQKW+7XLQPLEDgACfccyM+k1Rp7r+0/6eGnkG5l5o dhoAnAoMx2MGA3+MxR7pL5vGx3vcYcTe =EOc3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OASIS -- Our Membership and their IP Policy?
Mark Johnson [EMAIL PROTECTED] writes:
[...]
I'm asking because of Lawrence Rosen's ``A Call to Action in
OASIS'', which I saw in today's LWN [1]. Apparently OASIS is
adopting a new intellectual-property policy that would allow
standards based on patent-encumbered technology, which would be a
bad thing for the open-source community in general, and Debian in
particular.
Yes, I'd been working from within OASIS to address the issues with the new
IPR policy, but never got any traction.
I also requested legal review by posting to debian-legal last November,
http://lists.debian.org/debian-legal/2004/11/msg00142.html
but didn't receive any feedback.
There are a lot of big names [2] at the end of the post, not
including our DPL.
I've asked that my name be added to the list{1} as well, but nothing has
happened.
I honestly have no idea when or how the solicitation for signatures went
out.
I know Bruce Perens is addressing this issue now, but I'n not sure what the
status is.
No doubt we will discuss this in full when it comes time to renew Debian's
OASIS membership. We may decide to bow out, or we could stay in work to
directly effect change. For example, I'd be willing to run for a position
on the OASIS Board of Directors the next time there is an election.
[...]
Speaking as an outsider (I'm just a Debian user, not a Debian developer)
but as someone who was, until very recently, an individual OASIS member,
here are some opinions, for what they're worth.
If Debian as an organization is opposed to the OASIS IPR policy, then
I'd like to respectfully suggest that maybe the best way to make a clear
statement about that is to publicly resign its OASIS membership.
That would send out a statement similar to the statement that Debian
made when it publicly stated it would not impelement any standard
approved by the IETF MARID group as long at it was encumbered by patents.
And as far as standards that closely relate to free software and uses
and concerns of the free-sofware community, I personally would like to
see Debian and other free-software organizations pushing to have
standards developed outside of industry consortia such as OASIS.
I am writing that as someone who was a member of the DocBook TC at OASIS
for several years, and who joined OASIS for the sole purpose of
participating in development of DocBook as a voting member of the TC.
I say was because, this year, when my deadline for paying my annual
individual membership dues (US$250) came up, I simply neglected to pay
them. Not just because of the IPR policy, but also because I had spent
some time trying to think of what value I thought that involvement with
OASIS was bringing to DocBook, and had come to the conclusion that it
was bringing no value at all, at least as far as I could see.
In fact, there are some ways in which association with OASIS has been a
liability for DocBook. For example, deficiencies in the system
(some propietary application called Kavi) that OASIS chose for
managing their website actually made it impossible, for a period of
several months, for the DocBook TC to publish a new committee-approved
version of DocBook via the OASIS website. They did nothing at all about
it for many months.
Actually, OASIS did do one thing: They unilaterally issued a new policy
stating that all TCs were now *required* to host all their content on
the OASIS web server. Despite the problems that had been reported, and
despite the fact that they had done nothing to correct them.
Anyway, I don't personally like to reward imcompetence. Considering it
as a client-vendor relationship, I couldn't imagine paying $250 a year
to a vendor who -- along with not being able to provide me with anything
valueable -- had completely ignored repeated requests to make changes to
a part of its system that, despite the fact that they had been told were
unusable, they were *requiring* me to use.
And then came their unilateral decision about the IPR policy...
By the way, about that -- despite the fact that OASIS has a mechanism
for giving its entire membership an opportunity to vote on anything it
wants its membership to vote on, it never gave its membership an
opportunity to vote on the new IPR policy.
But even if OASIS were perfect and didn't have an IPR policy that was as
odds with the Debian Social Contract, it seems to me that maybe it
doesn't make much sense for Debian or any other free-software group to
be involved in OASIS or in any other organization that requires
financial contributions in order to participate in development of an
open standard.
Compare OASIS to the IETF, for example. The IETF, for the last
(relatively) gazillion years, has somehow managed to produce standards
(RFCs) without requiring any membership dues -- in fact without having
any permanent membership -- or without much infrastructure at all.
Interested people just get together, come up with draft standards, and
send them out for review an
Re: Do not make gratuitous source uploads just to provoke the buildds!
On Mon, Mar 14, 2005 at 12:19:15PM +0100, Wouter Verhelst wrote: Op ma, 14-03-2005 te 00:10 -0800, schreef Steve Langasek: Well, my objection is basically the same as Thomas's here -- all package builds are *not* equally urgent, Of course not, that is exactly my point. But from the POV of a package's maintainer, all fixes are more or less urgent. If some fixes weren't necessary, the upload wouldn't have been there in the first place. I find this line of reasoning fairly incomprehensible; the more or less aspect of the urgency is relevant here. We obviously have a system for classifying the severity of bugs in packages, and it's possible to relate these bug severities to the urgency field in uploads; even assuming it does get abused by maintainers, how would considering urgency for package build ordering be worse than what we have now given that it should only be an issue in either case when the buildds are not working the way they should? and in fact, we have an urgency field in uploads that expresses this fact quite clearly. Certainly there's some danger of abuse by uploaders, but there are dozens of other things that maintainers *could* abuse right now and are only stopped from doing because they *shouldn't* do them. I wouldn't be bothered by porters choosing how to order builds, if the ordering they chose more closely corresponded to what the release team (and britney) want it to be. :) I from my side wouldn't mind if someone from the release team would ask me to prioritize a build[1] if necessary; but I feel irky at the thought of allowing other people to prioritize their packages' builds over others, because that *will* make sure that eventually, those people that do what is actually the right thing will have to wait for all eternity for their packages to be built. [1] this is technically possible, but only in a kindof hackish way, by manually adding the package to a buildd's REDO file and (also manually) setting it to 'building' by that host. Yes, I don't think it scales very well to either have the release team asking for this, or for the buildd maintainers to be fielding such manual requests. If anything, the current workaround options (ignoring select out-of-date binaries for an arch) seem more efficient. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: The 98% and N=2 criteria (was: Vancouver meeting - clarifications)
On Fri, Mar 18, 2005 at 09:35:04PM -0600, Gunnar Wolf wrote: Frank Küster dijo [Tue, Mar 15, 2005 at 02:15:15PM +0100]: This whole argument is bogus. Up to before Vancouver, we always said: A package should be Architecture: any if it can in principle be compiled on every arch; the fact that it might not be useful there does not justify excluding it from that arch. And AFAIK the rationale for this was overall quality of the distribution. Now with the requirement for 98% compiled (and N=2 buildd's being able to take the workload) the focus has shifted: From overall quality to timely release and quality of individual architectures. (...) Ummm... What do you think about this: 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? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Accepted smbc 1.2.0-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 18 Mar 2005 08:39:58 +0100 Source: smbc Binary: smbc Architecture: source i386 Version: 1.2.0-1 Distribution: unstable Urgency: low Maintainer: Noèl Köthe [EMAIL PROTECTED] Changed-By: Noèl Köthe [EMAIL PROTECTED] Description: smbc - samba-commander - curses based samba network browser Changes: smbc (1.2.0-1) unstable; urgency=low . * new upstream from 2005-03-17 Files: f3e8e2807eb99c5adbc54a123c99c8fd 619 net optional smbc_1.2.0-1.dsc 9b080541425a2b869a14667d3bbd122a 838352 net optional smbc_1.2.0.orig.tar.gz 2feed9ba25168567af6bce5c48a8a06d 5447 net optional smbc_1.2.0-1.diff.gz c16fd1064dd508b03174da9e264743af 118588 net optional smbc_1.2.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCOoYa9/DnDzB9Vu0RAsmGAKCOT9L2UbTJNgLpkCIPGPQ1UxbA7ACcCVFo whftCElqOOZ4hjT5XockygQ= =+CM1 -END PGP SIGNATURE- Accepted: smbc_1.2.0-1.diff.gz to pool/main/s/smbc/smbc_1.2.0-1.diff.gz smbc_1.2.0-1.dsc to pool/main/s/smbc/smbc_1.2.0-1.dsc smbc_1.2.0-1_i386.deb to pool/main/s/smbc/smbc_1.2.0-1_i386.deb smbc_1.2.0.orig.tar.gz to pool/main/s/smbc/smbc_1.2.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnus 5.10.6-0.CVS.20050317-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 18 Mar 2005 01:10:01 -0600 Source: gnus Binary: gnus Architecture: source all Version: 5.10.6-0.CVS.20050317-1 Distribution: unstable Urgency: low Maintainer: Manoj Srivastava [EMAIL PROTECTED] Changed-By: Manoj Srivastava [EMAIL PROTECTED] Description: gnus - A versatile News and mailing list reader for Emacsen. Changes: gnus (5.10.6-0.CVS.20050317-1) unstable; urgency=low . * Sync'd to new CVS (stable branch). Files: baace2039905a1b32f9e21a172a5de66 623 news optional gnus_5.10.6-0.CVS.20050317-1.dsc 6e3420c3621e8d3b30de4f8a8a8447ad 2361315 news optional gnus_5.10.6-0.CVS.20050317.orig.tar.gz 4715c07903c872096cb9cb930726b6a0 181632 news optional gnus_5.10.6-0.CVS.20050317-1.diff.gz 1829375ac9e47ae1e3a4f22fb6ca1e0f 2037594 news optional gnus_5.10.6-0.CVS.20050317-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCOoY9Ibrau78kQkwRAhjCAKC5jq/N0QZu3wyEwzWoYV5XP43K7gCg3rov g2hUWQvBbkuimuj40YTqMRo= =u+Ua -END PGP SIGNATURE- Accepted: gnus_5.10.6-0.CVS.20050317-1.diff.gz to pool/main/g/gnus/gnus_5.10.6-0.CVS.20050317-1.diff.gz gnus_5.10.6-0.CVS.20050317-1.dsc to pool/main/g/gnus/gnus_5.10.6-0.CVS.20050317-1.dsc gnus_5.10.6-0.CVS.20050317-1_all.deb to pool/main/g/gnus/gnus_5.10.6-0.CVS.20050317-1_all.deb gnus_5.10.6-0.CVS.20050317.orig.tar.gz to pool/main/g/gnus/gnus_5.10.6-0.CVS.20050317.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted txt2man 1.4.8-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 18 Mar 2005 08:50:28 +0100 Source: txt2man Binary: txt2man Architecture: source all Version: 1.4.8-2 Distribution: unstable Urgency: low Maintainer: Fredrik Steen [EMAIL PROTECTED] Changed-By: Fredrik Steen [EMAIL PROTECTED] Description: txt2man- Converts flat ASCII text to man page format Closes: 300152 300154 Changes: txt2man (1.4.8-2) unstable; urgency=low . * Fixed watch file. (Closes:#300154) * Fixed escaping of hyphens (Closes:#300152) - patch from Wesley J. Landaker. Thank you. Files: c7cd570b76ca28af2a9c9a2f01628342 565 text optional txt2man_1.4.8-2.dsc 2c7f5b529553810ae8869d40c2f5bdb9 2252 text optional txt2man_1.4.8-2.diff.gz 0111eb4c48f6d5d51414e0138f7f1615 9332 text optional txt2man_1.4.8-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCOoyl2pHue6WOFk8RAo7DAJ4pk/9XQnpHzDdjNNYx+fVguQFK8wCePidl lVdRMoA0zO0YsxtuS3L5YNg= =4xR4 -END PGP SIGNATURE- Accepted: txt2man_1.4.8-2.diff.gz to pool/main/t/txt2man/txt2man_1.4.8-2.diff.gz txt2man_1.4.8-2.dsc to pool/main/t/txt2man/txt2man_1.4.8-2.dsc txt2man_1.4.8-2_all.deb to pool/main/t/txt2man/txt2man_1.4.8-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pyzor 1:0.4.0+cvs20030201-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 16 Mar 2005 12:54:45 -0500 Source: pyzor Binary: pyzor Architecture: source all Version: 1:0.4.0+cvs20030201-1 Distribution: unstable Urgency: low Maintainer: Christopher Sacca [EMAIL PROTECTED] Changed-By: Christopher Sacca [EMAIL PROTECTED] Description: pyzor - spam-catcher using a collaborative filtering network Closes: 263900 295852 297922 Changes: pyzor (1:0.4.0+cvs20030201-1) unstable; urgency=low . * New maintainer (Closes: #297922) * Updated man pages to current documentation * Documentation (pyzord.1) now clearly states that pyzord does not daemonize itself (Closes: #263900) * Caught IOErrors and propmts user to use correct syntax for stdin (Closes: #295852) Files: a430d318aaf2c444df7796ebc60f1533 691 mail optional pyzor_0.4.0+cvs20030201-1.dsc 21d192ae4827e1d8a218c19c1ea25b83 41827 mail optional pyzor_0.4.0+cvs20030201.orig.tar.gz d732587780c30746d368540569c7a667 13930 mail optional pyzor_0.4.0+cvs20030201-1.diff.gz fc13a8f230ba35ea32ef7b410d90fa84 35174 mail optional pyzor_0.4.0+cvs20030201-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCOUI2eBwlBDLsbz4RAqJqAJ4nAa4D2Rc7/nMjEuYZnLG1mC9UVACdGtM8 VUhItJplZjQGIgD0efrQGuc= =3qN7 -END PGP SIGNATURE- Accepted: pyzor_0.4.0+cvs20030201-1.diff.gz to pool/main/p/pyzor/pyzor_0.4.0+cvs20030201-1.diff.gz pyzor_0.4.0+cvs20030201-1.dsc to pool/main/p/pyzor/pyzor_0.4.0+cvs20030201-1.dsc pyzor_0.4.0+cvs20030201-1_all.deb to pool/main/p/pyzor/pyzor_0.4.0+cvs20030201-1_all.deb pyzor_0.4.0+cvs20030201.orig.tar.gz to pool/main/p/pyzor/pyzor_0.4.0+cvs20030201.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted firestarter 1.0.3-1.1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 17 Mar 2005 17:54:40 -0800 Source: firestarter Binary: firestarter Architecture: source i386 Version: 1.0.3-1.1 Distribution: unstable Urgency: high Maintainer: Yann Verley [EMAIL PROTECTED] Changed-By: Steve Langasek [EMAIL PROTECTED] Description: firestarter - gtk program for managing and observing your firewall Closes: 298809 Changes: firestarter (1.0.3-1.1) unstable; urgency=high . * Non-maintainer upload. * High-urgency upload for sarge-targetted RC bugfix * Simple rebuild (on all architectures) to drop dependency on libhowl0 which is going away (closes: #298809). Files: efc476a4103539e1d5a14a1cbd800d08 728 admin optional firestarter_1.0.3-1.1.dsc 2fb26431b4fed9b9b97118970be42a33 20729 admin optional firestarter_1.0.3-1.1.diff.gz 7355c87a9e2f777b9a7734fdebf04c2b 568712 admin optional firestarter_1.0.3-1.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCOlJ1KN6ufymYLloRAgTCAJ9KjDWzctzSSAosTgK80rvMUXheMQCeK04L Ns4A6YRlK7BnonxtKlc+/68= =3GfU -END PGP SIGNATURE- Accepted: firestarter_1.0.3-1.1.diff.gz to pool/main/f/firestarter/firestarter_1.0.3-1.1.diff.gz firestarter_1.0.3-1.1.dsc to pool/main/f/firestarter/firestarter_1.0.3-1.1.dsc firestarter_1.0.3-1.1_i386.deb to pool/main/f/firestarter/firestarter_1.0.3-1.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libcache-cache-perl 1.04-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 18 Mar 2005 08:22:25 + Source: libcache-cache-perl Binary: libcache-cache-perl Architecture: source all Version: 1.04-1 Distribution: unstable Urgency: medium Maintainer: Stephen Quinney [EMAIL PROTECTED] Changed-By: Stephen Quinney [EMAIL PROTECTED] Description: libcache-cache-perl - Managed caches of persistent information Changes: libcache-cache-perl (1.04-1) unstable; urgency=medium . * New upstream release - fixes permissions on temp cache files Files: 7e0ea898a7fb86c4f66ec8b7f3736cbc 725 perl optional libcache-cache-perl_1.04-1.dsc 60f79f31e74830dba1e0acda4d232d31 33448 perl optional libcache-cache-perl_1.04.orig.tar.gz 7ddc00d5e8dc4fcd0284d5dc520dec6e 2672 perl optional libcache-cache-perl_1.04-1.diff.gz 911b474caa793c35c24c92b6a443ba7c 81864 perl optional libcache-cache-perl_1.04-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCOpPRITGblEwaW+URAgTYAJ4j40/tygbUGZ+ooiRPq6Yn6VaHcwCfcYyv EtV7/IMf5LVJbodbxRzUiDo= =Fihi -END PGP SIGNATURE- Accepted: libcache-cache-perl_1.04-1.diff.gz to pool/main/libc/libcache-cache-perl/libcache-cache-perl_1.04-1.diff.gz libcache-cache-perl_1.04-1.dsc to pool/main/libc/libcache-cache-perl/libcache-cache-perl_1.04-1.dsc libcache-cache-perl_1.04-1_all.deb to pool/main/libc/libcache-cache-perl/libcache-cache-perl_1.04-1_all.deb libcache-cache-perl_1.04.orig.tar.gz to pool/main/libc/libcache-cache-perl/libcache-cache-perl_1.04.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libppd 2:0.10-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 18 Mar 2005 09:52:03 +0100 Source: libppd Binary: libppd-dev ppdfilt libppd0 Architecture: source i386 Version: 2:0.10-3 Distribution: unstable Urgency: medium Maintainer: A Mennucc1 [EMAIL PROTECTED] Changed-By: A Mennucc1 [EMAIL PROTECTED] Description: libppd-dev - postscript PPD file library, development kit libppd0- postscript PPD file library ppdfilt- filter that inserts printer specific commands into print jobs Closes: 300161 Changes: libppd (2:0.10-3) unstable; urgency=medium . * wrong configure : this version should be compiled with glib 1 (there is no point in using glib2, as long as 'gpr' uses gtk1.2 ) (Closes: #300161) Files: 6f86cde91fe1509178e12a7dccd4e3fc 602 libs optional libppd_0.10-3.dsc 18bd598178d964e36c69577075736822 550323 libs optional libppd_0.10-3.diff.gz e0a531949caebbe8e365cbfde974036d 30464 devel optional libppd-dev_0.10-3_i386.deb ed1821aae4b735d9a084ac7ec825e616 13734 utils optional ppdfilt_0.10-3_i386.deb 249d06014131994671c0ac1b75dd 19654 libs optional libppd0_0.10-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCOpfi9B/tjjP8QKQRAoCSAJ9bu5gaZbKgEQI+tvDsImKMPhY+MwCgg7Zm acbUDUZwJ27O2wEzu+9boxo= =TkIb -END PGP SIGNATURE- Accepted: libppd-dev_0.10-3_i386.deb to pool/main/libp/libppd/libppd-dev_0.10-3_i386.deb libppd0_0.10-3_i386.deb to pool/main/libp/libppd/libppd0_0.10-3_i386.deb libppd_0.10-3.diff.gz to pool/main/libp/libppd/libppd_0.10-3.diff.gz libppd_0.10-3.dsc to pool/main/libp/libppd/libppd_0.10-3.dsc ppdfilt_0.10-3_i386.deb to pool/main/libp/libppd/ppdfilt_0.10-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libjcode-pm-perl 0.88-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 18 Mar 2005 17:34:27 +0900 Source: libjcode-pm-perl Binary: libjcode-pm-perl Architecture: source i386 Version: 0.88-1 Distribution: unstable Urgency: low Maintainer: Atsushi KAMOSHIDA [EMAIL PROTECTED] Changed-By: Atsushi KAMOSHIDA [EMAIL PROTECTED] Description: libjcode-pm-perl - Perl extension interface to convert Japanese text Closes: 258536 Changes: libjcode-pm-perl (0.88-1) unstable; urgency=low . * New upstream Release.(Closes: #258536) Files: 3e32140956f66b015b089c8265267be4 597 interpreters optional libjcode-pm-perl_0.88-1.dsc 7cfd860e99e1f4c1ca65f0009695454d 233661 interpreters optional libjcode-pm-perl_0.88.orig.tar.gz c3b631cc6fffd7693fcd29aae117d7c3 2100 interpreters optional libjcode-pm-perl_0.88-1.diff.gz c7763f45dc815a5c5993cb8b7ba11b98 172908 interpreters optional libjcode-pm-perl_0.88-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCOpRcYxU8kEKVVoIRAvzQAJ9FhL3hq66NnasWMx57/iVEUuZQeACeIQ89 pPYbq4hlJ65HPWhOPrD73IM= =U6dE -END PGP SIGNATURE- Accepted: libjcode-pm-perl_0.88-1.diff.gz to pool/main/libj/libjcode-pm-perl/libjcode-pm-perl_0.88-1.diff.gz libjcode-pm-perl_0.88-1.dsc to pool/main/libj/libjcode-pm-perl/libjcode-pm-perl_0.88-1.dsc libjcode-pm-perl_0.88-1_i386.deb to pool/main/libj/libjcode-pm-perl/libjcode-pm-perl_0.88-1_i386.deb libjcode-pm-perl_0.88.orig.tar.gz to pool/main/libj/libjcode-pm-perl/libjcode-pm-perl_0.88.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libclass-prototyped-perl 1.10-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 18 Mar 2005 08:44:08 + Source: libclass-prototyped-perl Binary: libclass-prototyped-perl Architecture: source all Version: 1.10-1 Distribution: unstable Urgency: low Maintainer: Stephen Quinney [EMAIL PROTECTED] Changed-By: Stephen Quinney [EMAIL PROTECTED] Description: libclass-prototyped-perl - Fast prototype-based OO programming in Perl Changes: libclass-prototyped-perl (1.10-1) unstable; urgency=low . * New upstream release - backwards incompatible alterations - read the upstream Changes file Files: 8e2f43fbe3d9c1ff6a3ddd3f36f9f449 679 perl optional libclass-prototyped-perl_1.10-1.dsc 82d22ef4628e276b2eb7d4debabdf31d 59450 perl optional libclass-prototyped-perl_1.10.orig.tar.gz c85b51b962d3790d9a12dc0e3f535db4 2226 perl optional libclass-prototyped-perl_1.10-1.diff.gz 832b504b90a5823e3f3e2a309971dffd 70888 perl optional libclass-prototyped-perl_1.10-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCOpeHITGblEwaW+URAnJQAJ92XFkFMdKtPcFXqrVI0bU/4eTYRgCeLMAW AbswjKF68MzxaZZ0gbK0YeM= =/S2H -END PGP SIGNATURE- Accepted: libclass-prototyped-perl_1.10-1.diff.gz to pool/main/libc/libclass-prototyped-perl/libclass-prototyped-perl_1.10-1.diff.gz libclass-prototyped-perl_1.10-1.dsc to pool/main/libc/libclass-prototyped-perl/libclass-prototyped-perl_1.10-1.dsc libclass-prototyped-perl_1.10-1_all.deb to pool/main/libc/libclass-prototyped-perl/libclass-prototyped-perl_1.10-1_all.deb libclass-prototyped-perl_1.10.orig.tar.gz to pool/main/libc/libclass-prototyped-perl/libclass-prototyped-perl_1.10.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libregexp-common-perl 2.120-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 18 Mar 2005 09:01:48 + Source: libregexp-common-perl Binary: libregexp-common-perl Architecture: source all Version: 2.120-1 Distribution: unstable Urgency: low Maintainer: Stephen Quinney [EMAIL PROTECTED] Changed-By: Stephen Quinney [EMAIL PROTECTED] Description: libregexp-common-perl - Provide commonly requested regular expressions Changes: libregexp-common-perl (2.120-1) unstable; urgency=low . * New upstream release Files: 7281fc338491f7e5e12876934235f648 653 perl optional libregexp-common-perl_2.120-1.dsc a14f2a3c3f2718a567ec26f57a2bae13 115174 perl optional libregexp-common-perl_2.120.orig.tar.gz c12bd65f8bd3941ee2c84cb1649cbac5 1903 perl optional libregexp-common-perl_2.120-1.diff.gz d79b349a32d03814c806cf6a47112cb5 177046 perl optional libregexp-common-perl_2.120-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCOpoYITGblEwaW+URAonvAJ9Ux5RI76kBbM/8L7UMMFWdt/E2XwCaAzyK OgjK3QZhnbWrR79VhWvz2S0= =8PsN -END PGP SIGNATURE- Accepted: libregexp-common-perl_2.120-1.diff.gz to pool/main/libr/libregexp-common-perl/libregexp-common-perl_2.120-1.diff.gz libregexp-common-perl_2.120-1.dsc to pool/main/libr/libregexp-common-perl/libregexp-common-perl_2.120-1.dsc libregexp-common-perl_2.120-1_all.deb to pool/main/libr/libregexp-common-perl/libregexp-common-perl_2.120-1_all.deb libregexp-common-perl_2.120.orig.tar.gz to pool/main/libr/libregexp-common-perl/libregexp-common-perl_2.120.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted lsof 4.74.dfsg.3-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 18 Mar 2005 10:13:25 +0100 Source: lsof Binary: lsof-2.2 lsof Architecture: source i386 all Version: 4.74.dfsg.3-1 Distribution: unstable Urgency: high Maintainer: Jim Mintha [EMAIL PROTECTED] Changed-By: Norbert Tretkowski [EMAIL PROTECTED] Description: lsof - List open files. lsof-2.2 - Transitional package Closes: 276117 300171 Changes: lsof (4.74.dfsg.3-1) unstable; urgency=high . * Removed line in package description about supported kernels. (closes: #276117) * Re-added support for non-Linux ports. (closes: #300171) Files: 91a04d231765c7d0f99c6dde92a623de 627 utils standard lsof_4.74.dfsg.3-1.dsc dbc0072ce0f7977643f2ceacbf9c5f4f 638433 utils standard lsof_4.74.dfsg.3.orig.tar.gz 1dd91cb8a8a5de58da43c9ff14f40db1 4355 utils standard lsof_4.74.dfsg.3-1.diff.gz 7e21cf8ea02329dd1dbc6d4226ea08de 335502 utils standard lsof_4.74.dfsg.3-1_i386.deb 630d9c957c6fe132622b2d3ea23c0a51 4078 utils extra lsof-2.2_4.74.dfsg.3-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCOp14r/RnCw96jQERAqHoAJ9Z5yTn2LPOdZaZHKNuj2Det+X95QCgima5 lVJWeAxLWVjc4aDIBxSHNqE= =AVTz -END PGP SIGNATURE- Accepted: lsof-2.2_4.74.dfsg.3-1_all.deb to pool/main/l/lsof/lsof-2.2_4.74.dfsg.3-1_all.deb lsof_4.74.dfsg.3-1.diff.gz to pool/main/l/lsof/lsof_4.74.dfsg.3-1.diff.gz lsof_4.74.dfsg.3-1.dsc to pool/main/l/lsof/lsof_4.74.dfsg.3-1.dsc lsof_4.74.dfsg.3-1_i386.deb to pool/main/l/lsof/lsof_4.74.dfsg.3-1_i386.deb lsof_4.74.dfsg.3.orig.tar.gz to pool/main/l/lsof/lsof_4.74.dfsg.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libapache-mod-mp3 0.39-3.2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 18 Mar 2005 00:38:25 -0800 Source: libapache-mod-mp3 Binary: libapache-mod-mp3 Architecture: source i386 Version: 0.39-3.2 Distribution: unstable Urgency: high Maintainer: Pawel Wiecek [EMAIL PROTECTED] Changed-By: Steve Langasek [EMAIL PROTECTED] Description: libapache-mod-mp3 - turns Apache into a streaming audio server Closes: 299162 Changes: libapache-mod-mp3 (0.39-3.2) unstable; urgency=high . * Non-maintainer upload. * High-urgency upload for sarge-targetted RC bugfix. * Rebuild against libmysqlclient12-dev instead of libmysqlclient10-dev, for compatibility with newer servers and to avoid segfaults when other mysql-using apache modules are loaded (closes: #299162). Files: e6919d97412009ef79a283567be80965 659 web optional libapache-mod-mp3_0.39-3.2.dsc 4417eaf2e2a0f9c00d87741df3abcbb0 6784 web optional libapache-mod-mp3_0.39-3.2.diff.gz 6d10228bf1048e2186a9a2e7e8373e10 43196 web optional libapache-mod-mp3_0.39-3.2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCOpZKKN6ufymYLloRAlIZAJ4yDqN4HyWu8HmRusV++HQlSiRqDACfetKn i3s3H4F4Wjt6WM1uzP253Bg= =iE+p -END PGP SIGNATURE- Accepted: libapache-mod-mp3_0.39-3.2.diff.gz to pool/main/liba/libapache-mod-mp3/libapache-mod-mp3_0.39-3.2.diff.gz libapache-mod-mp3_0.39-3.2.dsc to pool/main/liba/libapache-mod-mp3/libapache-mod-mp3_0.39-3.2.dsc libapache-mod-mp3_0.39-3.2_i386.deb to pool/main/liba/libapache-mod-mp3/libapache-mod-mp3_0.39-3.2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted liblocale-maketext-lexicon-perl 0.48-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 18 Mar 2005 09:12:37 + Source: liblocale-maketext-lexicon-perl Binary: liblocale-maketext-lexicon-perl Architecture: source all Version: 0.48-1 Distribution: unstable Urgency: low Maintainer: Stephen Quinney [EMAIL PROTECTED] Changed-By: Stephen Quinney [EMAIL PROTECTED] Description: liblocale-maketext-lexicon-perl - Lexicon-handling backends for Locale::Maketext Changes: liblocale-maketext-lexicon-perl (0.48-1) unstable; urgency=low . * New upstream release Files: 89dc37888f0bb6a6b9fc8a311ccd4589 749 perl optional liblocale-maketext-lexicon-perl_0.48-1.dsc 3968b2e8a59d22a6d92a69aed979b78d 31645 perl optional liblocale-maketext-lexicon-perl_0.48.orig.tar.gz 7b096fad5822f0bba0afa6c303c01ea6 2544 perl optional liblocale-maketext-lexicon-perl_0.48-1.diff.gz 002b7f2496ca27bb5ede9fc348435441 40402 perl optional liblocale-maketext-lexicon-perl_0.48-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCOpwdITGblEwaW+URAi7MAJ9IKqC5LsfFD1a/u82akneKproBvACfRzXe EJoCN7ODfv2abqCHJpxs2CI= =rLqy -END PGP SIGNATURE- Accepted: liblocale-maketext-lexicon-perl_0.48-1.diff.gz to pool/main/libl/liblocale-maketext-lexicon-perl/liblocale-maketext-lexicon-perl_0.48-1.diff.gz liblocale-maketext-lexicon-perl_0.48-1.dsc to pool/main/libl/liblocale-maketext-lexicon-perl/liblocale-maketext-lexicon-perl_0.48-1.dsc liblocale-maketext-lexicon-perl_0.48-1_all.deb to pool/main/libl/liblocale-maketext-lexicon-perl/liblocale-maketext-lexicon-perl_0.48-1_all.deb liblocale-maketext-lexicon-perl_0.48.orig.tar.gz to pool/main/libl/liblocale-maketext-lexicon-perl/liblocale-maketext-lexicon-perl_0.48.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted bzflag 2.0.2.20050318 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 18 Mar 2005 08:40:38 + Source: bzflag Binary: bzflag-server bzflag Architecture: source i386 Version: 2.0.2.20050318 Distribution: unstable Urgency: medium Maintainer: Tim Riker [EMAIL PROTECTED] Changed-By: Tim Riker [EMAIL PROTECTED] Description: bzflag - a 3D first person tank battle game bzflag-server - bzfs - BZFlag game server Closes: 285306 292723 298600 Changes: bzflag (2.0.2.20050318) unstable; urgency=medium . * upstream release - many big fixes - see ChangeLog * Release Manager: sarge/unstable upload * license fix - Closes: #298600 * Closes: #292723, #285306 Files: 5813396ba5a58f3d2d69d611b6aaf6fb 698 games optional bzflag_2.0.2.20050318.dsc c90e22a392580a89b2225fb90f20a278 8886545 games optional bzflag_2.0.2.20050318.tar.gz b3bdf749f644192f71fa80f050f44481 7958754 games optional bzflag_2.0.2.20050318_i386.deb f32e82283eefbaed76b644c5ab36e59d 515170 games optional bzflag-server_2.0.2.20050318_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCOp+LWDyoFs2YsgoRAhQwAJ0eBHms7TAMJs9PG8GHNEkkfliEAACeMC6r S8WqMutmLm3lWbsZJVhWUjM= =YBUu -END PGP SIGNATURE- Accepted: bzflag-server_2.0.2.20050318_i386.deb to pool/main/b/bzflag/bzflag-server_2.0.2.20050318_i386.deb bzflag_2.0.2.20050318.dsc to pool/main/b/bzflag/bzflag_2.0.2.20050318.dsc bzflag_2.0.2.20050318.tar.gz to pool/main/b/bzflag/bzflag_2.0.2.20050318.tar.gz bzflag_2.0.2.20050318_i386.deb to pool/main/b/bzflag/bzflag_2.0.2.20050318_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted slrn 0.9.8.1-6 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 18 Mar 2005 10:29:33 +0100 Source: slrn Binary: slrn slrnpull Architecture: source i386 Version: 0.9.8.1-6 Distribution: unstable Urgency: low Maintainer: Norbert Tretkowski [EMAIL PROTECTED] Changed-By: Norbert Tretkowski [EMAIL PROTECTED] Description: slrn - threaded news reader (fast for slow links) slrnpull - pulls a small newsfeed from an NNTP server Closes: 300078 Changes: slrn (0.9.8.1-6) unstable; urgency=low . * Fixed typo in package description of slrnpull. (closes: #300078) * Removed jm_AC_TYPE_UNSIGNED_LONG_LONG from autoconf requirements. Files: c6cf0863bd68b62c5b49f2ad82105af8 756 news optional slrn_0.9.8.1-6.dsc b2f114cdc1cab03786fe1fc0cfe95413 43055 news optional slrn_0.9.8.1-6.diff.gz fa5174626ac9a4d2ad4cb27fbedc3cf0 820592 news optional slrn_0.9.8.1-6_i386.deb 301f5b9e153c5ef8b3e74b33b48c6679 118866 news optional slrnpull_0.9.8.1-6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCOqRKr/RnCw96jQERAor1AJ498N4rU4BBHqDHw/8pR6v8E1kt4QCfVLd/ wE+9+74H5tbN0jQp5WlKy2E= =l42f -END PGP SIGNATURE- Accepted: slrn_0.9.8.1-6.diff.gz to pool/main/s/slrn/slrn_0.9.8.1-6.diff.gz slrn_0.9.8.1-6.dsc to pool/main/s/slrn/slrn_0.9.8.1-6.dsc slrn_0.9.8.1-6_i386.deb to pool/main/s/slrn/slrn_0.9.8.1-6_i386.deb slrnpull_0.9.8.1-6_i386.deb to pool/main/s/slrn/slrnpull_0.9.8.1-6_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted slrn 0.9.8.1pl1-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 18 Mar 2005 10:43:51 +0100 Source: slrn Binary: slrn slrnpull Architecture: source i386 Version: 0.9.8.1pl1-3 Distribution: experimental Urgency: low Maintainer: Norbert Tretkowski [EMAIL PROTECTED] Changed-By: Norbert Tretkowski [EMAIL PROTECTED] Description: slrn - threaded news reader (fast for slow links) slrnpull - pulls a small newsfeed from an NNTP server Changes: slrn (0.9.8.1pl1-3) experimental; urgency=low . * Merged changed from 0.9.8.1-6. Files: 6d8528913068e6491acbbda0732c1197 765 news optional slrn_0.9.8.1pl1-3.dsc b10e7271e1b7469d0fb2b3f7ebc2e748 41282 news optional slrn_0.9.8.1pl1-3.diff.gz 0ca586085a8ce85202ba9a9168c5997e 822540 news optional slrn_0.9.8.1pl1-3_i386.deb 9c5a09c119550b9ff9b33addf8d76a88 119358 news optional slrnpull_0.9.8.1pl1-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCOqRWr/RnCw96jQERAlARAJ0QIq4ofVXPfsYcEW+OjWd1TVczXQCgkCSt WzHwSJQoAor6yhYPj1CgFAM= =b5RY -END PGP SIGNATURE- Accepted: slrn_0.9.8.1pl1-3.diff.gz to pool/main/s/slrn/slrn_0.9.8.1pl1-3.diff.gz slrn_0.9.8.1pl1-3.dsc to pool/main/s/slrn/slrn_0.9.8.1pl1-3.dsc slrn_0.9.8.1pl1-3_i386.deb to pool/main/s/slrn/slrn_0.9.8.1pl1-3_i386.deb slrnpull_0.9.8.1pl1-3_i386.deb to pool/main/s/slrn/slrnpull_0.9.8.1pl1-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted asterisk-spandsp-plugins 0.0.20050203-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 9 Feb 2005 18:45:53 +0100 Source: asterisk-spandsp-plugins Binary: asterisk-app-fax asterisk-app-dtmftotext Architecture: source i386 Version: 0.0.20050203-1 Distribution: unstable Urgency: low Maintainer: Debian VoIP Team [EMAIL PROTECTED] Changed-By: Kilian Krause [EMAIL PROTECTED] Description: asterisk-app-dtmftotext - Text entry application for Asterisk asterisk-app-fax - Softfax application for Asterisk Changes: asterisk-spandsp-plugins (0.0.20050203-1) unstable; urgency=low . * Debian VoIP upload. Taken over from Simon. Thanks! * New upstream release as is shipping with spandsp 0.0.2pre10. * The package is not a Debian native one, versioning consequently. Files: 3007b674061a7c4cef8b0ec6033f503c 889 comm optional asterisk-spandsp-plugins_0.0.20050203-1.dsc e1d9c6b3fc4773318b5a0bf7072cacab 14788 comm optional asterisk-spandsp-plugins_0.0.20050203.orig.tar.gz 3b89bdfe88d257cb49a86a05b9b91546 316 comm optional asterisk-spandsp-plugins_0.0.20050203-1.diff.gz d8a6862f45e9478472e27fb90b7e0b49 9910 comm optional asterisk-app-fax_0.0.20050203-1_i386.deb 3a2e74da2eb7946f3ac5ea7784f73971 12650 comm optional asterisk-app-dtmftotext_0.0.20050203-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCCpJiS+BYJZB4jhERAt5gAJ9mA3G/qqX6VDskuJNVAgb6FFYEeACgk8d0 RDcKr8mgZpsfKUXxS3qHrQ8= =KMBY -END PGP SIGNATURE- Accepted: asterisk-app-dtmftotext_0.0.20050203-1_i386.deb to pool/main/a/asterisk-spandsp-plugins/asterisk-app-dtmftotext_0.0.20050203-1_i386.deb asterisk-app-fax_0.0.20050203-1_i386.deb to pool/main/a/asterisk-spandsp-plugins/asterisk-app-fax_0.0.20050203-1_i386.deb asterisk-spandsp-plugins_0.0.20050203-1.diff.gz to pool/main/a/asterisk-spandsp-plugins/asterisk-spandsp-plugins_0.0.20050203-1.diff.gz asterisk-spandsp-plugins_0.0.20050203-1.dsc to pool/main/a/asterisk-spandsp-plugins/asterisk-spandsp-plugins_0.0.20050203-1.dsc asterisk-spandsp-plugins_0.0.20050203.orig.tar.gz to pool/main/a/asterisk-spandsp-plugins/asterisk-spandsp-plugins_0.0.20050203.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mysql-ruby 2.4.5-6.1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 18 Mar 2005 01:43:13 -0800 Source: mysql-ruby Binary: libmysql-ruby libmysql-ruby1.6 libmysql-ruby1.8 Architecture: source i386 all Version: 2.4.5-6.1 Distribution: unstable Urgency: high Maintainer: Dmitry Borodaenko [EMAIL PROTECTED] Changed-By: Steve Langasek [EMAIL PROTECTED] Description: libmysql-ruby - MySQL module for Ruby libmysql-ruby1.6 - MySQL module for Ruby 1.6 libmysql-ruby1.8 - MySQL module for Ruby 1.8 Closes: 299166 Changes: mysql-ruby (2.4.5-6.1) unstable; urgency=high . * Non-maintainer upload. * High-urgency upload for sarge-targetted RC bugfix. * Rebuild against libmysqlclient12-dev instead of libmysqlclient10-dev, for compatibility with newer servers and to avoid segfaults when other mysql-using apache modules are loaded together with mod-ruby (closes: #299166). Files: 62e62567a13afb7f68e6f374d3e47d20 687 interpreters optional mysql-ruby_2.4.5-6.1.dsc 4f6812ed7d2248fc48902f5fc9cd7464 5783 interpreters optional mysql-ruby_2.4.5-6.1.diff.gz 5ed2bfd11517f89f65500d8bd3eb6e84 4518 interpreters optional libmysql-ruby_2.4.5-6.1_all.deb 50cb0fbd23b6eff8585998e287d24f03 29488 interpreters optional libmysql-ruby1.6_2.4.5-6.1_i386.deb ac2b30a5171a177f52d0dd1ea4349d90 29464 interpreters optional libmysql-ruby1.8_2.4.5-6.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCOqrYKN6ufymYLloRArC3AJ4viU59ilvnxnqiEWhHKq5tfS3cxACgq4ot OiO4g8KdWMvq1QxkzUtdxh8= =5gB1 -END PGP SIGNATURE- Accepted: libmysql-ruby1.6_2.4.5-6.1_i386.deb to pool/main/m/mysql-ruby/libmysql-ruby1.6_2.4.5-6.1_i386.deb libmysql-ruby1.8_2.4.5-6.1_i386.deb to pool/main/m/mysql-ruby/libmysql-ruby1.8_2.4.5-6.1_i386.deb libmysql-ruby_2.4.5-6.1_all.deb to pool/main/m/mysql-ruby/libmysql-ruby_2.4.5-6.1_all.deb mysql-ruby_2.4.5-6.1.diff.gz to pool/main/m/mysql-ruby/mysql-ruby_2.4.5-6.1.diff.gz mysql-ruby_2.4.5-6.1.dsc to pool/main/m/mysql-ruby/mysql-ruby_2.4.5-6.1.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted asterisk-oh323 0.6.6pre3-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 21 Jan 2005 20:53:09 +0100 Source: asterisk-oh323 Binary: asterisk-oh323 Architecture: source i386 Version: 0.6.6pre3-1 Distribution: experimental Urgency: low Maintainer: Debian VoIP Team [EMAIL PROTECTED] Changed-By: Kilian Krause [EMAIL PROTECTED] Description: asterisk-oh323 - oh323 channel driver for Asterisk Changes: asterisk-oh323 (0.6.6pre3-1) experimental; urgency=low . * Initial Release. Files: b729ebb140a828bd1e05974852df066e 880 comm optional asterisk-oh323_0.6.6pre3-1.dsc 50b83a951d64dfe6e7fc4127f6dac404 85523 comm optional asterisk-oh323_0.6.6pre3.orig.tar.gz b13f44ba3111267b240376d61098d1ea 2333 comm optional asterisk-oh323_0.6.6pre3-1.diff.gz c520fa355b9fccd887cc3d28ccc3c22e 205616 comm optional asterisk-oh323_0.6.6pre3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB+sSAS+BYJZB4jhERAjMDAJ9Wv2EVwp3kwj7PaeuDNbCOW5rSfgCgnPjN 4zc/K+JzNmbxGXqZcQfill8= =xxmx -END PGP SIGNATURE- Accepted: asterisk-oh323_0.6.6pre3-1.diff.gz to pool/main/a/asterisk-oh323/asterisk-oh323_0.6.6pre3-1.diff.gz asterisk-oh323_0.6.6pre3-1.dsc to pool/main/a/asterisk-oh323/asterisk-oh323_0.6.6pre3-1.dsc asterisk-oh323_0.6.6pre3-1_i386.deb to pool/main/a/asterisk-oh323/asterisk-oh323_0.6.6pre3-1_i386.deb asterisk-oh323_0.6.6pre3.orig.tar.gz to pool/main/a/asterisk-oh323/asterisk-oh323_0.6.6pre3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted asterisk-oh323 0.6.6pre3-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Feb 2005 22:45:29 +0100 Source: asterisk-oh323 Binary: asterisk-oh323 Architecture: source i386 Version: 0.6.6pre3-2 Distribution: unstable Urgency: low Maintainer: Debian VoIP Team [EMAIL PROTECTED] Changed-By: Kilian Krause [EMAIL PROTECTED] Description: asterisk-oh323 - oh323 channel driver for Asterisk Changes: asterisk-oh323 (0.6.6pre3-2) unstable; urgency=low . * Bumped openh323 version to Mimas. * Targetting for SID. Files: 0f85a0cbf701fc3c3458f978f49c8638 884 comm optional asterisk-oh323_0.6.6pre3-2.dsc 72f32f80c0f384f7e8ad1733d8e13bb8 2396 comm optional asterisk-oh323_0.6.6pre3-2.diff.gz aa89724cc5569f1bc81efff46ccd6816 205686 comm optional asterisk-oh323_0.6.6pre3-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCGmguS+BYJZB4jhERAnEiAJ9azztPqHz+82u+nHtTQpjcKsK3YQCgrwRU 6ZVfCX2Fdnz4tNtn2eleE70= =z/A5 -END PGP SIGNATURE- Accepted: asterisk-oh323_0.6.6pre3-2.diff.gz to pool/main/a/asterisk-oh323/asterisk-oh323_0.6.6pre3-2.diff.gz asterisk-oh323_0.6.6pre3-2.dsc to pool/main/a/asterisk-oh323/asterisk-oh323_0.6.6pre3-2.dsc asterisk-oh323_0.6.6pre3-2_i386.deb to pool/main/a/asterisk-oh323/asterisk-oh323_0.6.6pre3-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted asterisk-oh323 0.6.6pre3-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 03:21:24 +0100 Source: asterisk-oh323 Binary: asterisk-oh323 Architecture: source i386 Version: 0.6.6pre3-3 Distribution: unstable Urgency: low Maintainer: Debian VoIP Team [EMAIL PROTECTED] Changed-By: Kilian Krause [EMAIL PROTECTED] Description: asterisk-oh323 - oh323 channel driver for Asterisk Changes: asterisk-oh323 (0.6.6pre3-3) unstable; urgency=low . * Fix building on amd64 by adding -fPIC. * debian/control, debian/copyright, debian/conffiles: Fixed lintian warnings. Files: ccedd456fd29cb25e40a0ea4e747b620 884 comm optional asterisk-oh323_0.6.6pre3-3.dsc 014817c4e2fd539a1842b7f213ead543 2887 comm optional asterisk-oh323_0.6.6pre3-3.diff.gz 31041eb8ea7a582f33123e78ae051242 202656 comm optional asterisk-oh323_0.6.6pre3-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCG6r9S+BYJZB4jhERAvCeAJ0dK0wBtfMIEhP8PoYq0c0mN/5VhwCdG/ws aQV9qfCqaECQXXafKxojtZI= =+UAj -END PGP SIGNATURE- Accepted: asterisk-oh323_0.6.6pre3-3.diff.gz to pool/main/a/asterisk-oh323/asterisk-oh323_0.6.6pre3-3.diff.gz asterisk-oh323_0.6.6pre3-3.dsc to pool/main/a/asterisk-oh323/asterisk-oh323_0.6.6pre3-3.dsc asterisk-oh323_0.6.6pre3-3_i386.deb to pool/main/a/asterisk-oh323/asterisk-oh323_0.6.6pre3-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libjcode-pm-perl 0.88-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 18 Mar 2005 19:32:12 +0900 Source: libjcode-pm-perl Binary: libjcode-pm-perl Architecture: source i386 Version: 0.88-2 Distribution: unstable Urgency: low Maintainer: Atsushi KAMOSHIDA [EMAIL PROTECTED] Changed-By: Atsushi Kamoshida [EMAIL PROTECTED] Description: libjcode-pm-perl - Perl extension interface to convert Japanese text Changes: libjcode-pm-perl (0.88-2) unstable; urgency=low . * Fixed Section in control file. Files: ae234d22acec41c91d1f0f4b566e894c 597 perl optional libjcode-pm-perl_0.88-2.dsc 60ce7e3a5adcb6be562d84e73d5ba1aa 2119 perl optional libjcode-pm-perl_0.88-2.diff.gz 6772e3a1d1e2e0e1afbf3b501eaa5574 172914 perl optional libjcode-pm-perl_0.88-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCOq5qYxU8kEKVVoIRAv4vAJ94LIyXmwy5h7ZoRkHpHcuZnKC3xwCfb+Ty 8zqwxVKl4HFy5uMLKVbbSjA= =xO5U -END PGP SIGNATURE- Accepted: libjcode-pm-perl_0.88-2.diff.gz to pool/main/libj/libjcode-pm-perl/libjcode-pm-perl_0.88-2.diff.gz libjcode-pm-perl_0.88-2.dsc to pool/main/libj/libjcode-pm-perl/libjcode-pm-perl_0.88-2.dsc libjcode-pm-perl_0.88-2_i386.deb to pool/main/libj/libjcode-pm-perl/libjcode-pm-perl_0.88-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
