Release update: debian-installer, upload targets, kernels, infrastructure
Hello, world, Kernel updates -- A kernel/d-i team meeting was recently held to review the status of 2.6.8. The team leads involved eventually decided to stay with kernel 2.6.8 and 2.4.27, rather than bumping the 2.6 kernel to 2.6.10. This decision was made upon review of the known bugs in each of the 2.6 kernel versions; despite some significant bugs in the Debian 2.6.8 kernel tree, these bugs were weighed against the additional delays that a kernel version bump would introduce in the schedule for debian-installer RC3. As it happens, preparing 2.4 and 2.6 kernels with the security fixes for all architectures took roughly two months from start to finish, during which time preparation of the next debian-installer release candidate has been entirely stalled. A two-month turnaround for critical security fixes really isn't acceptable, and makes it difficult to progress towards a release. It's for this reason that all architectures are required to be synced to the same kernel version for sarge, but even so, more per-architecture kernel help is needed, particularly for the sparc and the arm port. Debian Installer RC3 The current plan of the Installer team for the RC3 includes these dates: 28 Feb all udeb changes should be complete all updated kernels must be in testing 1 Mar arrive at final go/no-go list for which udebs will be updated in rc3 2 Mar rc3 udebs synced to testing (some rc2 images may break) 2 Mar debs that were waiting on rc3 should reach testing now (parted, debootstrap) finish all needed changes to debian-installer package (manual, build system) begin debian-installer package test build 3 Mar merge updates to sarge branch of svn repository, where necessary 7 Mar debian-installer test build finishes (approximate) test period 19 Mar final netinst and businesscard CD builds begin full CD builds 20 Mar final testing 22 Mar web site updates 23 Mar rc3 release Please expect that some days off is always possible. RC bug count, BSP - The RC bug count keeps falling, partly as a result of last weekend's bug-squashing party. Despite the arrival of a lot of new bugs (missing copyright for GFDLed man pages), the bug-squashers managed to get the RC bug count down from 120 to less than 100. That's another all-time low since we started to count RC bugs. Of course, this is not enough. We need to get the number of RC bugs significantly lower for release, so please continue to help with fixing the packages you care about. If you are interested in helping, but don't have experience with bug-squashing, there is a new primer available at [1] that you may find helpful. Status of security bugs in testing -- Outside of the numerous kernel rebuilds required, sarge seems to be in good shape security wise: Joey Hess has been tracking release-critical security issues for testing, with assistance from both the Security Team and the new Debian testing security team, and a running account of known security vulnerabilities in testing can now be found at [2]. The count naturally varies from day to day, but seems to have been holding between 10 and 30 now. In the past, some of these security bugs were fixed in unstable and merely waiting to propagate to testing, largely blocked by missing builds for the mipsel architecture. For a while last month, packages out-of-date on that architecture were ignored during the testing promotion process to speed this up. Since then, another buildd has been added, so mipsel is back to its former status in testing and is no longer holding up bug fixes. testing-proposed-updates, testing-security -- Currently, some further tweaks are being made to optimize the build daemons' interface to wanna-build, after which there should only be the routine maintenance matter of setting up the wanna-build databases for these queues and configuring/updating the testing chroots on the buildds. In short, this means that the number one blocker on the release is close to resolution, and the testing-security and testing-proposed-updates queues will both be fully operational in the foreseeable future. We should now be focusing as much as possible on stabilizing the existing packages in the archive, to cut down on the number of RC bugs we'll have to find and fix after the freeze starts. Other issues In an effort to reduce the number of library packages, db4.1 and vacation are no longer part of base. Also, some outdated libraries like gnutls7, gnutls10 and libgcrypt are pending removal from sarge, although some of them are waiting for the next debian-installer release candidate first. If you encounter anything else requiring attention by the release team, please don't hesitate to bring it up. As the release approaches, we have a chance to pay attention to smaller issues. A rather
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
* Dirk Eddelbuettel ([EMAIL PROTECTED]) [050222 05:45]: It delays our releases in the sense that it affects our resources: - available maintainer and developer time, You mean, we have some great people working as porters and also giving a general helping hand, and we would loose them if we throw most arches out? :) - cpu cycles (witness Wouter's request to compile big packages rarely), It is _definitly_ a bad idea to just upload packages every few days. This has nothing to do with buildds, but just with general good or bad preparations. - security response time (more builds to do) that is not an issue. and that it - increases the load on infrastructure (t-p-u, security) There's no real difference between 2 and 11 archs - scarce resource such as release managers, ftp admins, ... no. Frankly speaking, the most costly point with other arches is that there are too often these useless discussions. _That_ is beyond all the most expansive of them. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
* Matthew Palmer ([EMAIL PROTECTED]) [050222 06:20]: Security autobuilders are on their way. You could make the argument that if we only had a couple of architectures we wouldn't really need security autobuilders, but I think that automating everything that can be automated is a Good Thing. We have security autobuilders since woody. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Thomas Bushnell BSG wrote: Dirk Eddelbuettel [EMAIL PROTECTED] writes: - mirrror capacity (witness the sad state of amd64), But dropping an arch can't improve the capacity of a mirror which doesn't carry it, and they can always simply not carry it if they want to. Nor could this possibly slow release. One of the biggest reasons provided so far against accepting amd64 is we don't have enough mirror space. Dropping a less-used port for a new commonly-used one seems an easy fix here. Most of the large mirrors currently carry all arches, hence the efforts on billie to make it easier for people to drop the less common arches. - scarce resource such as release managers, ftp admins, ... if we have to look after arches that are *not really used*. All of whom have said that this doesn't actually slow them at all. Well, I'll say differently. I've produced the last several sets of woody point release CD and DVD images. Each arch produced takes time. Reducing the sets produced would make it much easier/faster to get this done. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Into the distance, a ribbon of black Stretched to the point of no turning back -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 10:42:15AM +, Steve McIntyre wrote: Thomas Bushnell BSG wrote: Dirk Eddelbuettel [EMAIL PROTECTED] writes: - scarce resource such as release managers, ftp admins, ... if we have to look after arches that are *not really used*. All of whom have said that this doesn't actually slow them at all. Well, I'll say differently. I've produced the last several sets of woody point release CD and DVD images. Each arch produced takes time. Reducing the sets produced would make it much easier/faster to get this done. But the CD set build would take hours rather than weeks, right? I can't imagine it'd hold up the release by any appreciable amount, and building CD sets is a nicely parallelizable task. - Matt signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ...
On Tue, Feb 22, 2005 at 07:52:57AM +0100, Ingo Juergensmann wrote: On Tue, Feb 22, 2005 at 02:29:33PM +1100, Hamish Moffatt wrote: Why do the build servers install all the dependencies only to find out that some installed versions are insufficient for the build? Because the current buildd system is outdated in the meanwhile. It should be replaced by a new framework. Surely this can be determined _before_ installing the dependencies? No new information is available after install that wasn't available before. Bastian Blank worked on a database that handles all these build-deps on the central wanna-build replacement. The idea is to give out just those packages Even that sounds too complicated. Really, each buildd can work this out on its own. Given the current packages files, determine whether you can meet all the dependencies. I think 'apt-get build-dep' does exactly this. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 08:48:48PM +1300, Nick Phillips wrote: Running such a system in parallel with the current systems (and comparing the outputs) might be a good test for gcc-as-cross-compiler, then... And a hell of a lot of work. You can't just create checksums of the resulting binaries and compare those; it's not as if any difference between the two compiled binaries would constitute an error... -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
On Mon, Feb 21, 2005 at 11:46:37PM -0500, Kevin Mark wrote: On Mon, Feb 21, 2005 at 04:30:27PM +0100, Wouter Verhelst wrote: There are small KDE applications that require most of the KDE dependency chain to be installed, while on the other hand XFree86's build dependency list is (relatively) small. would it make sense to examine the queue to see if any packages have similar build dependencies and then move them to the top of the queue so they build immediately after the current one? or to re-sequence the queue to group package with similar build dependencies. That wouldn't necessary help; not all architectures (especially not the slower ones) build all packages on the same host. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
On Tue, Feb 22, 2005 at 02:29:33PM +1100, Hamish Moffatt wrote: Is the problem that you use apt-get to install the current version, and then check what you got? Because you can't tell apt-get to install at least version X else fail? Yes, that's how it works currently. Since this also makes autobuilding experimental harder, work is being done to use ``apt-cache policy'' output to determine whether the right version of a package is available and break off if not, but it's still got some bugs (including situations where the build is broken off because sbuild (incorrectly) thinks the right version of a package isn't available). -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
On Tue, Feb 22, 2005 at 10:44:42PM +1100, Hamish Moffatt wrote: Bastian Blank worked on a database that handles all these build-deps on the central wanna-build replacement. The idea is to give out just those packages Even that sounds too complicated. Really, each buildd can work this out on its own. Given the current packages files, determine whether you can meet all the dependencies. Can and should are different stories. When there's a missing build-dep on one arch, it might make sense to stop that package from being distributed for other archs, so they don't waste their time on that. You can't do that on a per buildd basis. Same for supplying additional build-deps that have already been solved on faster archs. Have you ever watched several buildds doing their work to give qualified comments on that issues? If so, join the group at #multibuild... -- Ciao... // Ingo \X/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
Marc Haber [EMAIL PROTECTED] writes: On 21 Feb 2005 20:54:36 -0800, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Dirk Eddelbuettel [EMAIL PROTECTED] writes: - security response time (more builds to do) Which DSAs came out later than they should have because of this supposed delay? Nor could this possibly slow release. There are rumours that the noticeable multi-week gap last fall when no DSAs were released at all were caused by some buildd failure on one of the lesser-userd arches and the security team decided to defer advisories until security builds could be released for all arches. I have a dedicated opinion about this time of service the major arches received during this time, but I do not want to voice it here as I am only talking about a rumour and I do not want to start yet another flame war. Greetings Marc On the other hand there have been DSAs where some archs where left out and fixed later iirc. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
Dirk Eddelbuettel [EMAIL PROTECTED] writes: For your convenience, I quote the numbers here again along with a quick percentage calculation: files.downloaded percent i386 1285422 70.5079 all 504789 27.6886 powerpc17754 0.9738 ia64 10111 0.5546 sparc 3336 0.1830 arm 850 0.0466 alpha507 0.0278 hppa 204 0.0112 mipsel91 0.0050 m68k 15 0.0008 mips 7 0.0004 s390 4 0.0002 total1823090 100. The only thing this shows is that Debian does not need to mirror s390, mips, m68k, mipsel, ... all over the world. Those architectures should be droped from all but a select few _mirrors_. As the ftp-masters have (second hand) said before, the SCC that is to come after sarge will address this issue, allowing primary mirrors to drop archs while they currently must carry all archs. Dropping those less used archs should clear up enough space for amd64 and other future addons. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
Steve McIntyre [EMAIL PROTECTED] writes: Thomas Bushnell BSG wrote: Dirk Eddelbuettel [EMAIL PROTECTED] writes: - mirrror capacity (witness the sad state of amd64), But dropping an arch can't improve the capacity of a mirror which doesn't carry it, and they can always simply not carry it if they want to. Nor could this possibly slow release. One of the biggest reasons provided so far against accepting amd64 is !The only reason! we don't have enough mirror space. Dropping a less-used port for a new commonly-used one seems an easy fix here. Most of the large mirrors currently carry all arches, hence the efforts on billie to make it easier for people to drop the less common arches. Support for archs doesn't have to be droped. Mirroring of lesser used archs to everywhere has to. But sarge is blocking that. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 03:15:58AM +, Dirk Eddelbuettel wrote: Maybe we should pick up on Petter's suggestion of stricter buildd requirements. Maybe we should only build base and essential packages for the minor architectures [ after, apt-source is there for everybody to go further ]. Debian is not a source-based distribution. If people want to compile their own packages, they usually go to one of the BSD's or Gentoo. In the mean time, our users expect to be able to run 'apt-get install' and be done with it. We should not break that expectation, because that would not be in the interest of our users; we should ensure that all software our users would want to run is available. I agree that we should not continue to provide software for outdated hardware platforms just for the sake of it; but as it is, there are still people interested in m68k (some hobbyists, some embedded developers, some who just use their old trusty hardware as their home firewall, etc) and, I'm sure, other currently less-used hardware, so as long as a port doesn't continually stall the release (which none currently does; there are occasionally problems, but that happens in every major undertaking), I see no reason to drop any port. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
Kevin Mark [EMAIL PROTECTED] writes: would it make sense to examine the queue to see if any packages have similar build dependencies and then move them to the top of the queue so they build immediately after the current one? or to re-sequence the queue to group package with similar build dependencies. -Kev That only works if you would just install/purge the difference between Build-Depends of the last and next build. The official buildds don't do that. My local, experimental buildd includes this in the API but for lack of time the current update-build-depends dist old-package=version new-package=version script just does purge all old, install all new (and on amd64 I rarely care). I also have a ToDo item to give out packages to buildds in groups with overlapping Build-Depends so as to take advantage of the above. So a buildd asking for things to build would get item 1, 3 and 7, all being kde packages, instead of 1, 2 and 3. But that's just an idea for now. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 08:54:36PM -0800, Thomas Bushnell BSG wrote: Dirk Eddelbuettel [EMAIL PROTECTED] writes: - cpu cycles (witness Wouter's request to compile big packages rarely), So you're saying that if we dropped the mips buildd's we'd have more cycles for other archs? No, he's saying that if we dropped the slower architectures we'd be able to do more frequent updates of large packages, such as KDE. However, this is false. You'd get * Angry mirror administrators that don't like the fact that users now have to download a *much* larger amount of data every day for their daily updates, thus eating a larger part of their bandwidth, * Angry users who, like me, have a traffic quota on their Internet connection and who'd get problems staying within the quota if they want to keep up with unstable, * Problems keeping track of all those versions, and the relation to when bugs were fixed (there are always users who do not have the latest version of a package installed and still file bugs). * Problems with your own development pace, because you'd be spending more time on performing package builds and making sure they get updated correctly than you'd be spending on the improvement of those packages. As I said before, this is not just a buildd problem, it's a sensible approach to maintaining large packages in general; and if you as the maintainer of a large package really made a stupid mistake and need to upload a package within two hours after the previous one, then so be it. We only request that you try to avoid it as much as possible. - security response time (more builds to do) Which DSAs came out later than they should have because of this supposed delay? Nor could this possibly slow release. In fairness, this is not just a fairy tale. DSA's are sent out for all architectures at once; if a package requires two days to build on the slower architectures (there are packages for which this is true), then the DSA will take two days to be prepared. I should note that security builds are given priority, however, and are done on the fastest machines in the architecture's buildd pool. That said, your statement that it could not slow release is, of course, true. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
On Tue, Feb 22, 2005 at 12:51:16PM +0100, Ingo Juergensmann wrote: On Tue, Feb 22, 2005 at 10:44:42PM +1100, Hamish Moffatt wrote: Bastian Blank worked on a database that handles all these build-deps on the central wanna-build replacement. The idea is to give out just those packages Even that sounds too complicated. Really, each buildd can work this out on its own. Given the current packages files, determine whether you can meet all the dependencies. Can and should are different stories. When there's a missing build-dep on one arch, it might make sense to stop that package from being distributed for other archs, so they don't waste their time on that. You can't do that on a per buildd basis. True. But even what I proposed is a big improvement on the current situation. Same for supplying additional build-deps that have already been solved on faster archs. Do we still do this? Aren't missing deps just sent back as FTBFS bugs? Have you ever watched several buildds doing their work to give qualified comments on that issues? If so, join the group at #multibuild... No, but I don't see why I shouldn't comment anyway. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
On Tue, Feb 22, 2005 at 12:50:02PM +0100, Wouter Verhelst wrote: On Tue, Feb 22, 2005 at 02:29:33PM +1100, Hamish Moffatt wrote: Is the problem that you use apt-get to install the current version, and then check what you got? Because you can't tell apt-get to install at least version X else fail? Yes, that's how it works currently. Since this also makes autobuilding experimental harder, work is being done to use ``apt-cache policy'' output to determine whether the right version of a package is available and break off if not, but it's still got some bugs (including situations where the build is broken off because sbuild (incorrectly) thinks the right version of a package isn't available). Thanks for the explanation Wouter. That sounds like a big improvement. By the way, does this duplicate the functionality of 'apt-get build-dep'? Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
On Tue, Feb 22, 2005 at 11:23:51PM +1100, Hamish Moffatt wrote: Thanks for the explanation Wouter. That sounds like a big improvement. By the way, does this duplicate the functionality of 'apt-get build-dep'? Possibly. Sbuild, however, predates the implementation of 'apt-get build-dep', so it's always had its own build-depends parsing code. For reference, sbuild is the component in buildd that fetches the source, installs build-dependencies, and does the actual build. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
unsubscribe
unsubscribe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
On Tue, Feb 22, 2005 at 11:22:37PM +1100, Hamish Moffatt wrote: Can and should are different stories. When there's a missing build-dep on one arch, it might make sense to stop that package from being distributed for other archs, so they don't waste their time on that. You can't do that on a per buildd basis. True. But even what I proposed is a big improvement on the current situation. As Wouter wrote in another mail: sbuild has its own implementation for that. Maybe you want to file a bug against sbuild then for a better implementation? Same for supplying additional build-deps that have already been solved on faster archs. Do we still do this? Aren't missing deps just sent back as FTBFS bugs? Erm, sort of... of course FTBFS are filed. But when a (new) build-dep is missing and this is discovered on one arch, it is a stupid thing to let it fail (and waste time) on all other archs as well, just to send in multiple FTBFS bugreports for all archs. IMHO, it would be smarter to just file a single FTBFS bug and add the missing build-dep to the other archs. Sure, it is arguable if that packages should be build anyway, but it would save time on the buildds. Have you ever watched several buildds doing their work to give qualified comments on that issues? If so, join the group at #multibuild... No, but I don't see why I shouldn't comment anyway. As I said: if you have valuable comments/contributions, those people there might have an open ear to you. It is known (at least to some persons) that the current buildd system has drawbacks, but that's not a reason to drop some archs from the release. Sadly, many DDs don't have any/much clue about how buildds actually work. Good thing is, that the number of DDs that have, has increased over the last few years. But still, there are many discussions floating around that are based on non-knowledge about buildds. -- Ciao... // Ingo \X/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Cross-compiling and dist-cc (Was: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]))
On Tue, Feb 22, 2005 at 12:44:27PM +0100, Wouter Verhelst wrote: On Tue, Feb 22, 2005 at 08:48:48PM +1300, Nick Phillips wrote: Running such a system in parallel with the current systems (and comparing the outputs) might be a good test for gcc-as-cross-compiler, then... And a hell of a lot of work. You can't just create checksums of the resulting binaries and compare those; it's not as if any difference between the two compiled binaries would constitute an error... Why not? Is there something non-deterministic in the compilation process? Ideally, version x of gcc should produce the same output natively as when cross-compiling. Or have I missed something important? (I'm actually quite fond of the idea of dist-cc sending pre-processed C code to remote (faster) machines and getting unlinked object code back. I haven't got a good use for it yet, but the _idea_ is neat.) -- --- Paul TBBle Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ...
Hamish Moffatt [EMAIL PROTECTED] writes: On Tue, Feb 22, 2005 at 07:52:57AM +0100, Ingo Juergensmann wrote: On Tue, Feb 22, 2005 at 02:29:33PM +1100, Hamish Moffatt wrote: Why do the build servers install all the dependencies only to find out that some installed versions are insufficient for the build? Because the current buildd system is outdated in the meanwhile. It should be replaced by a new framework. Surely this can be determined _before_ installing the dependencies? No new information is available after install that wasn't available before. Bastian Blank worked on a database that handles all these build-deps on the central wanna-build replacement. The idea is to give out just those packages Even that sounds too complicated. Really, each buildd can work this out on its own. Given the current packages files, determine whether you can meet all the dependencies. I think 'apt-get build-dep' does exactly this. 'apt-get build-dep' can't handle virtual packages reliably. Everything with a Build-Depends: automaken will fail and many many more. Even virtual packages with only one provider fail if there are multiple sources for the package (different builds or versions). The first one is a bug (current unwritten policy) in the package while the later has a patch in BTS. So it wouldn't be unsurmountable obstacles. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
Hamish Moffatt [EMAIL PROTECTED] writes: On Tue, Feb 22, 2005 at 07:52:57AM +0100, Ingo Juergensmann wrote: On Tue, Feb 22, 2005 at 02:29:33PM +1100, Hamish Moffatt wrote: Why do the build servers install all the dependencies only to find out that some installed versions are insufficient for the build? Because the current buildd system is outdated in the meanwhile. It should be replaced by a new framework. Surely this can be determined _before_ installing the dependencies? No new information is available after install that wasn't available before. Bastian Blank worked on a database that handles all these build-deps on the central wanna-build replacement. The idea is to give out just those packages Even that sounds too complicated. Really, each buildd can work this out on its own. Given the current packages files, determine whether you can meet all the dependencies. One more though, the idea in multibuild is also that packages could be scheduled to get the Build-Depends needed build first. The more waiting packages the higher the priority or such. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cross-compiling and dist-cc (Was: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]))
Paul Hampson wrote: On Tue, Feb 22, 2005 at 12:44:27PM +0100, Wouter Verhelst wrote: On Tue, Feb 22, 2005 at 08:48:48PM +1300, Nick Phillips wrote: Running such a system in parallel with the current systems (and comparing the outputs) might be a good test for gcc-as-cross-compiler, then... And a hell of a lot of work. You can't just create checksums of the resulting binaries and compare those; it's not as if any difference between the two compiled binaries would constitute an error... Why not? Is there something non-deterministic in the compilation process? Yes. Ideally, version x of gcc should produce the same output natively as when cross-compiling. Or have I missed something important? gcc -fno-guess-branch-probability Thiemo signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ...
Wouter Verhelst [EMAIL PROTECTED] writes: On Tue, Feb 22, 2005 at 02:29:33PM +1100, Hamish Moffatt wrote: Is the problem that you use apt-get to install the current version, and then check what you got? Because you can't tell apt-get to install at least version X else fail? Yes, that's how it works currently. Since this also makes autobuilding experimental harder, work is being done to use ``apt-cache policy'' output to determine whether the right version of a package is available and break off if not, but it's still got some bugs (including situations where the build is broken off because sbuild (incorrectly) thinks the right version of a package isn't available). apt-get build-dep should be improved to be buildd useable instead. It's is wastefull to have two seperate and differently buggy implementations floating around. Improving apt-get instead of sbuild since that is already doing a better job at detecting missing things and since users use it too. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Add a videocard to Discover
Hello, During install my videocard is not detected by Debconf. It is a cheap Nvidia compatible videocard what uses the nv driver. How can I tell the Discover-developpers about this videocard? With regards, Paul van der Vlis. BTW: This is from lspci -vv - :01:00.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 4000 AGP 8x] (rev c1) (prog-if 00 [VGA]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 (1250ns min, 250ns max) Interrupt: pin A routed to IRQ 193 Region 0: Memory at ee00 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at f000 (32-bit, prefetchable) [size=128M] Expansion ROM at effe [disabled] [size=128K] Capabilities: [60] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [44] AGP version 3.0 Status: RQ=32 Iso- ArqSz=0 Cal=3 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8 Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=none --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cross-compiling and dist-cc
Wouter Verhelst wrote: And a hell of a lot of work. You can't just create checksums of the resulting binaries and compare those; it's not as if any difference between the two compiled binaries would constitute an error... The idea is to cross-compile and native-compile _for_ _the_ _same_ _target_ _architecture_ and then compare the binaries. I don't see why they should differ. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cross-compiling and dist-cc
On Tuesday 22 February 2005 14:01, John Hasler wrote: Wouter Verhelst wrote: And a hell of a lot of work. You can't just create checksums of the resulting binaries and compare those; it's not as if any difference between the two compiled binaries would constitute an error... The idea is to cross-compile and native-compile _for_ _the_ _same_ _target_ _architecture_ and then compare the binaries. I don't see why they should differ. A suprising number of programs embed the current date, time, hostname etc. in their user visible version strings. The Linux kernel for example, does not compile identically twice unless you hack it slightly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
* Goswin von Brederlow ([EMAIL PROTECTED]) [050222 15:15]: Wouter Verhelst [EMAIL PROTECTED] writes: On Tue, Feb 22, 2005 at 02:29:33PM +1100, Hamish Moffatt wrote: Is the problem that you use apt-get to install the current version, and then check what you got? Because you can't tell apt-get to install at least version X else fail? Yes, that's how it works currently. Since this also makes autobuilding experimental harder, work is being done to use ``apt-cache policy'' output to determine whether the right version of a package is available and break off if not, but it's still got some bugs (including situations where the build is broken off because sbuild (incorrectly) thinks the right version of a package isn't available). apt-get build-dep should be improved to be buildd useable instead. It's is wastefull to have two seperate and differently buggy implementations floating around. It would be definitly a good idea to improve apt-get build-dep, and make sbuild using a solution based on apt. But, I'm not going to hold my breath for that to happen. :) And, as always, patches welcome. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
On Tue, Feb 22, 2005 at 03:07:54PM +0100, Goswin von Brederlow wrote: Wouter Verhelst [EMAIL PROTECTED] writes: Since this also makes autobuilding experimental harder, work is being done to use ``apt-cache policy'' output to determine whether the right version of a package is available and break off if not, but it's still got some bugs (including situations where the build is broken off because sbuild (incorrectly) thinks the right version of a package isn't available). apt-get build-dep should be improved to be buildd useable instead. If you don't have patches, don't tell me how to do things. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296448: ITP: poc -- MP3 streaming server and tools
Package: wnpp Severity: wishlist Owner: Joachim Breitner [EMAIL PROTECTED] * Package name: poc Version : 0.4. Upstream Author : Manuel Odendahl [EMAIL PROTECTED] * URL : http://www.bl0rg.net/software/poc/ * License : BSD Description : MP3 streaming server and tools poc is a suite of MP3 tools and MP3 streaming programs. It can stream MP3s over HTTP, RTP (RFC 2250 and RFC 3119) and a special protocol to enable the use of Forward Error Correction to protect the MP3 stream against packet loss. It can also stream OGGs over HTTP. In addition to the streaming programs, poc contains two MP3 tools: mp3cue and mp3cut. mp3cue can cut a big MP3 file according to a tracklisting contained in a .cue file. mp3cut can split and concatenate MP3 files according to time slices given on the command line. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10.otto Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
Wouter Verhelst [EMAIL PROTECTED] writes: On Tue, Feb 22, 2005 at 03:07:54PM +0100, Goswin von Brederlow wrote: Wouter Verhelst [EMAIL PROTECTED] writes: Since this also makes autobuilding experimental harder, work is being done to use ``apt-cache policy'' output to determine whether the right version of a package is available and break off if not, but it's still got some bugs (including situations where the build is broken off because sbuild (incorrectly) thinks the right version of a package isn't available). apt-get build-dep should be improved to be buildd useable instead. If you don't have patches, don't tell me how to do things. Since I have (some) can I now tell you how to do things? :) I can always tell you how to do things and you never have to listen. But my opinion stands that improving apt-get is the right thing to do, not having two divergent systems. What you do with that is your choice. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
On Tue, Feb 22, 2005 at 05:43:43PM +0100, Goswin von Brederlow wrote: I can always tell you how to do things and you never have to listen. But my opinion stands that improving apt-get is the right thing to do, not having two divergent systems. sbuild includes some centralized build-dependency override system which would be a bad idea to use with apt-get, but which is part of its build-dependency parsing code. How you want to merge the two considering the above is a mystery to me :-) -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
* Wouter Verhelst ([EMAIL PROTECTED]) [050222 18:00]: On Tue, Feb 22, 2005 at 05:43:43PM +0100, Goswin von Brederlow wrote: I can always tell you how to do things and you never have to listen. But my opinion stands that improving apt-get is the right thing to do, not having two divergent systems. sbuild includes some centralized build-dependency override system which would be a bad idea to use with apt-get, but which is part of its build-dependency parsing code. How you want to merge the two considering the above is a mystery to me :-) I think this is possible with some special option to apt. In fact, I think this would make a nice target - but, as it is with nice targets, they're usually not the things that are implemented, but just the pressing targets. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Add a videocard to Discover
|| On Tue, 22 Feb 2005 15:15:39 +0100 || Paul van der Vlis [EMAIL PROTECTED] wrote: pvdv Hello, pvdv During install my videocard is not detected by Debconf. It is a cheap pvdv Nvidia compatible videocard what uses the nv driver. pvdv How can I tell the Discover-developpers about this videocard? pvdv With regards, pvdv Paul van der Vlis. pvdv BTW: This is from lspci -vv pvdv - pvdv :01:00.0 VGA compatible controller: nVidia Corporation NV18 pvdv [GeForce4 MX 4000 AGP 8x] (rev c1) (prog-if 00 [VGA]) pvdv Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- pvdv ParErr- Stepping- SERR- FastB2B- pvdv Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- pvdv Latency: 64 (1250ns min, 250ns max) pvdv Interrupt: pin A routed to IRQ 193 pvdv Region 0: Memory at ee00 (32-bit, non-prefetchable) [size=16M] pvdv Region 1: Memory at f000 (32-bit, prefetchable) [size=128M] pvdv Expansion ROM at effe [disabled] [size=128K] pvdv Capabilities: [60] Power Management version 2 pvdv Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA pvdv PME(D0-,D1-,D2-,D3hot-,D3cold-) pvdv Status: D0 PME-Enable- DSel=0 DScale=0 PME- pvdv Capabilities: [44] AGP version 3.0 pvdv Status: RQ=32 Iso- ArqSz=0 Cal=3 SBA+ ITACoh- GART64- pvdv HTrans- 64bit- FW+ AGP3+ Rate=x4,x8 pvdv Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- pvdv FW- Rate=none pvdv --- You need to pass the: lspci -n lspci outputs. Better is report a bug in BTS for it. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
* Wouter Verhelst ([EMAIL PROTECTED]) [050222 18:00]: On Tue, Feb 22, 2005 at 05:43:43PM +0100, Goswin von Brederlow wrote: I can always tell you how to do things and you never have to listen. But my opinion stands that improving apt-get is the right thing to do, not having two divergent systems. sbuild includes some centralized build-dependency override system which would be a bad idea to use with apt-get, but which is part of its build-dependency parsing code. We have to disagree there. Having that system in sbuild but not apt-get means that rebuilding packages from source becomes non trivial and somewhat mysterious. People rebuilding packages get unforseen differences and even build failures. Is that realy in the spirit of free software and wanted? Let me quote the GPL for something more to think about: | For an executable work, complete source code means all the source | code for all modules it contains, plus any associated interface | definition files, plus the scripts used to control compilation and | installation of the executable. Since wanna-build and sbuild scripts and the centralized build-dependency override system is part of 'the scripts used to control compilation' doesn't Debian already violate the GPL by not distributing those in the Debian archive? Even worse is when the buildd applies additional patches to the source before building. That is a gross violation of the GPL in my eyes. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cross-compiling and dist-cc
* Will Newton | A suprising number of programs embed the current date, time, hostname etc. in | their user visible version strings. The Linux kernel for example, does not | compile identically twice unless you hack it slightly. Even with the same preprocessed source? -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cross-compiling and dist-cc (Was: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]))
[EMAIL PROTECTED] (Paul Hampson) writes: Or have I missed something important? Yes. There are a jillion different machine code programs that do the same thing and a compiler could generate any one of them in response to the same source. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cross-compiling and dist-cc
John Hasler [EMAIL PROTECTED] writes: Wouter Verhelst wrote: And a hell of a lot of work. You can't just create checksums of the resulting binaries and compare those; it's not as if any difference between the two compiled binaries would constitute an error... The idea is to cross-compile and native-compile _for_ _the_ _same_ _target_ _architecture_ and then compare the binaries. I don't see why they should differ. A compiler is allowed to generate any machine code that correctly does what the source program does. But there are many such machine code programs possible (bajillions, in fact), and a compiler can generate any one of them. There is no reason to think that two successive versions of the same compiler, let alone different compilers, would produce the same machine code. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Steve McIntyre [EMAIL PROTECTED] writes: Well, I'll say differently. I've produced the last several sets of woody point release CD and DVD images. Each arch produced takes time. Reducing the sets produced would make it much easier/faster to get this done. Does this delay release? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
FW: A Call to Action in OASIS
- Forwarded message from Lawrence Rosen [EMAIL PROTECTED] - From: Lawrence Rosen [EMAIL PROTECTED] Date: Tue, 22 Feb 2005 09:36:47 -0800 Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: A Call to Action in OASIS A Call to Action in OASIS The free and open source software community has long demanded that industry standards be freely available to all to implement without patent or other licensing encumbrances. Open standards are essential for free software and open source to thrive. Now OASIS, a major industry consortium that produces e-business and Web services standards, has adopted a patent policy that threatens to undermine our development and licensing model. This patent policy (available, grouped together with other unrelated legal issues, in http://www.oasis-open.org/who/intellectualproperty.php) permits standards to be based upon so-called reasonable and non-discriminatory patent license terms--terms which invariably and unreasonably discriminate against open source and free software to the point of prohibiting them entirely. It would lead to the adoption of standards that cannot be implemented in open source and free software, that cannot be distributed under our licenses. While the policy includes a provision for royalty-free standards, it is a secondary option, which will have little effect if a few OASIS members with patents can ensure it is not used. The OASIS patent policy will encourage large patent holders to negotiate private arrangements among themselves, locking out all free software and open source developers. This is not a new issue for us. We fought hard for a royalty-free patent policy in W3C and encouraged that standards organization to commit its members to open standards. But some W3C member companies, steadfast opponents of software freedom, moved their efforts to OASIS. Without consulting the free software/open source community, they produced a patent policy designed so that we cannot live with it. We ask you to stand with us in opposition to the OASIS patent policy. Do not implement OASIS standards that aren't open. Demand that OASIS revise its policies. If you are an OASIS member, do not participate in any working group that allows encumbered standards that cannot be implemented in open source and free software. Please send email to [EMAIL PROTECTED] to indicate your support. We will forward your comments to the proper authorities at OASIS. If we stand united in opposition to this unacceptable patent policy, we can persuade OASIS to change it. /signed/ Lawrence Rosen Bruce Perens Richard Stallman Lawrence Lessig Eben Moglen Marten Mickos John Weathersby John Terpstra Tim O'Reilly Tony Stanco Don Marti Michael Tiemann Andrew Aitken Karen Copenhaver Doug Levin Dan Ravicher Larry Augustin Mitchell Kapor Russell Nelson Guido van Rossum Daniel Quinlan Murugan Pal Stuart Cohen Danese Cooper Eric Raymond Mark Webbink Ken Coar Doc Searls Brian Behlendorf ___ Spi-general mailing list [EMAIL PROTECTED] http://lists.spi-inc.org/cgi-bin/listinfo/spi-general - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cross-compiling and dist-cc (Was: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]))
On Wed, Feb 23, 2005 at 12:38:46AM +1100, Paul Hampson wrote: Why not? Is there something non-deterministic in the compilation process? Ideally, version x of gcc should produce the same output natively as when cross-compiling. Or have I missed something important? -frandom-seed=string This option provides a seed that GCC uses when it would otherwise use random numbers. At present, this is used to generate certain symbol names that have to be different in every compiled file. The string should be different for every file you compile. -fno-guess-branch-probability Do not guess branch probabilities using a randomized model. Sometimes gcc will opt to use a randomized model to guess branch probabilities, when none are available from either profiling feedback (-fprofile-arcs) or __builtin_expect. This means that different runs of the compiler on the same program may produce different object code. Also, the first 16 bytes will differ in an ELF format .o, see http://lists.debian.org/debian-devel/2004/09/msg00201.html -- Petri Latvala signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Thomas Bushnell BSG wrote: - network bandwith (witness the discussion on mirror efficiency), Mirrors don't have to (and don't need to) copy all the archs. They can support whichever ones they want. Nor could this possibly slow release. - mirrror capacity (witness the sad state of amd64), But dropping an arch can't improve the capacity of a mirror which doesn't carry it, and they can always simply not carry it if they want to. That's predicated on the assumption that mirrors can easily or feasibly do such a partial mirror. The small number of mirrors that have, the smaller number of important mirrors (push-primary, top-level country code mirrors, etc) that have, and the fact that the ftp-masters have this upcoming SCC project to make it easier, belies that. - security response time (more builds to do) Which DSAs came out later than they should have because of this supposed delay? Nor could this possibly slow release. DSAs are occasionally delayed waiting on builds. The priveliged nature of much of the information surrounding DSAs makes it impossible for me to give a list, but I've seen it happen repeatedly. The most glaring example in recent memory is the 6 or so months it took for us to get updated kernels in stable for last spring's set of very bad kernel security holes. Security bugs which are currently not fixed in testing, and which either would be fixed there or would not be a concern if it wasn't for the need to support all architectures include: bidwatcher 1.3.17-1 needed, have 1.3.16-1 for DSA-687-1 bind 1:8.4.6-1 needed, have 1:8.4.4-1 for CAN-2005-0033 emacs21 21.3+1-9 needed, have 21.3+1-8 for CAN-2005-0100, DSA-685-1 kdeedu 4:3.3.2-2 needed, have 4:3.3.1-3 for CAN-2005-0011 kdelibs 4:3.3.2-2 needed, have 4:3.3.2-1 for CAN-2005-0365 kernel-image-2.4.27-alpha (unfixed; bug #280492) for CAN-2003-0465 kernel-image-2.4.27-sparc 2.4.27-2 needed, have 2.4.27-1 for CAN-2004-1056, CAN-2004-1235 kernel-patch-powerpc-2.4.27 (unfixed) for CAN-2004-1056, CAN-2004-1235 xemacs21 21.4.16-2 needed, have 21.4.16-1 for CAN-2005-0100, DSA-671-1 xview 3.2p1.4-19 needed, have 3.2p1.4-16 for DSA-672-1 - scarce resource such as release managers, ftp admins, ... if we have to look after arches that are *not really used*. All of whom have said that this doesn't actually slow them at all. To the contrary, I've publically said before that the need to support all our architectures (in d-i) has prevented me from doing other work that I could have done to advance the release. The release of d-i RC3 has been delayed for several months now because that's how long it takes to update the debian kernel packages for all arches. I've spent at least one man-week of full-time work during that time period in tracking what work still needed to be done and working with the debian-kernel team, ftp-masters, d-i team, and others to get the updated kernels in place. I've spent approximatly one man-month of time in the past year on setting up and running an automated test lab for the debian-installer on 6 or 7 architectures. For some lesser-used architectures, the install tests from this lab are the only way we have to know if the installer is generally working on a day-to-day basis, since we get only rare installation reports from users of those arches. The above is just the tip of the iceberg WRT architecture specific d-i work that I have to do. If I hadn't needed to work on that stuff due to the requirement that d-i release on all arches, then I would have certianly been able to devote more time to other things, including testing security work, other release-critical areas of d-i, and so on. I'm not particularly advocating dropping any architectures at this point, but I do think that people who shrug off the impact of our supporting so many architectures are not arguing from a very strong position. -- see shy jo signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ...
Thaddeus H. Black [EMAIL PROTECTED] writes: [Not private. Reply on-list if you wish.] However, I do think that not including amd64 (while keeping mips and friends) in the sarge release due to mirroring problems is ridiculous. Amen, brother. ... packages are uploaded too frequently, ... How often is probably too often, in your view? (This is just a question. I happen to keep a package which uploads irregularly ten or fifteen times per year.) Short answer: As long as your package is a candidate for testing (and you feel is generally fit for testing) but is being blocked by something else, you should probably wait to upload until the current version makes it into testing. How often is that? Well... Consider package 'foo', which has either a direct or indirect relationship with 50 other packages in Debian (it depends directly on a few packages, those packages depend on other stuff, and some packages depend directly on foo, etc.). And say it's being blocked from testing because some package in there is broken. How do you get all of these into testing? You have to fix the broken package, and have all of the interrelated packages become simultaneously eligible for inclusion in testing. Since there's a constant churn of packages in unstable, probably someone will upload some package in chain, which means all of the others will have to wait for it. Or someone uploads a new upstream release, which turns out to be too buggy. Then all of the packages have to wait for that one to get fixed. In general, it would probably work best for testing if an upload turns out to be free of RC bugs that the maintainer doesn't touch it for a couple months. Of course, we're all volunteers and maybe in a couple of months the maintainer won't have time to do another upload. But he or she has time now, so why not just do it now? And, without any kind of established release timeframe, maintainers don't generally know if it's best to wait on an upload or just do it right away. For example, if a maintainer decides it's best to wait until the next release to make a big packaging change because the release appears to be near, more than likely that maintainer will be sitting on their hands for 6 months before they finally realize, hey, we're not actually going to release soon. So they make the upload, break some stuff, and generally push back the release even more. I don't think overly frequent uploads are the real problem. I think the more significant problems are: 1. Package dependencies are too complicated and interrelated. 2. Library shlibs are too tight. 3. The overall discontent with our releases taking too long make some of the general developer population disinterested with the release, and thus don't take proper care to ensure their packages are entering and working in testing. The newer libtool versions are definitely helping with (1), though only to an extent. Modern software is just getting very complicated and is using lots of libraries. Unless we throw out things like GNOME and KDE, there's really no way around it. (2) is definitely something that needs work. It seems like every library package out there is just using 'dh_makeshlibs -V', and that's unfortunate since the dependencies produced are in most cases overly tight. As for (3), well, that's been a known problem for years and no RM has yet figured out how to motivate the troops. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cross-compiling and dist-cc (Was: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]))
Petri Latvala wrote: [snip] Also, the first 16 bytes will differ in an ELF format .o, see http://lists.debian.org/debian-devel/2004/09/msg00201.html That's incorrect, strictly speaking. The first (magic) bytes have to be identical, only the padding bytes could be different (but are usually zeroed). Thiemo signature.asc Description: Digital signature
FROM MR MIKE MAZE
Attin/Dear . I would like to apply through this medium for your co-operation and to secure an opportunity to invest and do joint business with you in your country. I have a substantial capital i honourably intend to invest in your country into a very lucrative business venture of which you are to advise and execute the said venture over there for the mutual benefits of both of us. Your able co-operation is to become my business partner in your country and create ideas on how money will be invested,properly managed and the type of investment after the money is transferred to your custody with your help and assistance. Meanwhile,on indication of your willingness to handle this transaction sincerely by protecting our interests and upon your acceptance of this proposal,I would furnish you with the full detailed information, procedure,amount involve and mutually agree on your percentage interest or share holding for helping me to secure the release of the deposit and investing the money. I shall be glad to reserve this respect and opportunity for you,if you so desire,but do urge you to give the matter your immediate attention it deserves. If this proposal is acceptable by you,please do not make undue advantage of the trust i bestow on you,and your urgent call and reply is highly needed,for more detailed informations and oral talks. Looking forward to your urgent call and positive response today and a mutual healthy businessrelationship with you. Best regards,and have a great day. Yours Faithfully, MR MIKE MAZE -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.3.0 - Release Date: 21/02/2005
Re: Bug#296279: ITP: tarp -- small script adding progress bar support for GNU tar
Mon, 21 Feb 2005 16:13:09 +0100 Christoph Berg [EMAIL PROTECTED] wrote: Simple perl script adding progress bar support for GNU tar. Hi, I'd say this is way to small to justify a package for it. Did you try to contact the tar maintainer to get it included there? Hello Well, for telling truth, I agree it's small, or seem to be small, but in my opinion it works quite nice (with medium-large archives) and can be usefull. I'm not convinced if it would work well in group of other tools (as Eduard Bloch has written) because it requires a specific alias for tar and manpage read ;) despite its simplicity. Best regards, Grzegorz Bizon -- [EMAIL PROTECTED] // [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
Em Ter, 2005-02-22 s 15:28 +0100, Wouter Verhelst escreveu: On Tue, Feb 22, 2005 at 03:07:54PM +0100, Goswin von Brederlow wrote: Wouter Verhelst [EMAIL PROTECTED] writes: Since this also makes autobuilding experimental harder, work is being done to use ``apt-cache policy'' output to determine whether the right version of a package is available and break off if not, but it's still got some bugs (including situations where the build is broken off because sbuild (incorrectly) thinks the right version of a package isn't available). apt-get build-dep should be improved to be buildd useable instead. If you don't have patches, don't tell me how to do things. While I agree with the core of your reasoning, I think you should approach Goswin's comments as advice, not as 'telling one how to do things'. Maybe we just need to learn how to use a more pleasant language =D. See ya, -- [EMAIL PROTECTED]: Gustavo Noronha http://couve.no-ip.org/~kov/ Debian: http://www.debian.org/ * http://www.debian-br.org/ signature.asc Description: Esta =?ISO-8859-1?Q?=E9?= uma parte de mensagem assinada digitalmente
Status update for the inofficial Debian-amd64 sarge
Hi, just an update about a small milestone we've taken. Both current gnome and kde meta packages now have all their dependencies fullfilled in the sarge tree. With recent reports of successfull D-I installs with sarge we are now caught up with the official release. Our next step will be to get the 14 debian-amd64 mirrors to add sarge (those that don't have it already) and producing a full sarge CD set. We thank everyone that has added patches for amd64 already and hope we get the last few critical bugs fixed as well soon: * Packages in sarge with patches - syslinux (#249506) - util-linux (#248121): fixed in sid, frozen package, will probably be fixed by the maintainer - libtunepimp (#276742): needed to build kde, waiting on libflac6 before rattling cages MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
Hi, Also: As far as the kernel is concerned, any local IP is local to *all* interfaces, and it will happly reply to it (ARP and so on) if allowed to. The rp_filter will often avoid trouble here, BUT routers often have to disable rp_filter. So add some rules to the firewall make sure nothing gets into 127.0.0.0/8 unless it is a local packet. So, by this implication, if I use arping and pretend to be 127.0.0.1 to another host, that host will try to ping the network if I ping 127.0.0.1 on the target host? regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
On Wed, 23 Feb 2005, Junichi Uekawa wrote: The rp_filter will often avoid trouble here, BUT routers often have to disable rp_filter. So add some rules to the firewall make sure nothing gets into 127.0.0.0/8 unless it is a local packet. So, by this implication, if I use arping and pretend to be 127.0.0.1 to another host, that host will try to ping the network if I ping 127.0.0.1 on the target host? Only if the kernel is starking mad and buggy as all hell, you cannot take over a local IP from the network, especially one that belongs to a NOARP interface. OTOH, you can probably reach all sort of nice stuff that is bound to 127.0.0.1 in another host over the network, and a lot of people will be caught with their ports open on that one. If you send a packet to 127.0.0.1 with the MAC address of any of the local interfaces, and forwarding is enabled, well... I am not sure it will work with forwarding disabled. Anyone cares to test? Disable rp_filter first. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 10:17:39AM -0800, Thomas Bushnell BSG wrote: Steve McIntyre [EMAIL PROTECTED] writes: Well, I'll say differently. I've produced the last several sets of woody point release CD and DVD images. Each arch produced takes time. Reducing the sets produced would make it much easier/faster to get this done. Does this delay release? It delays the release of the CDs and DVDs, yes. I don't know if you care about that. It also adds significantly to the amount of work needed regularly for the weekly sarge CD and DVD builds. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] You raise the blade, you make the change... You re-arrange me 'til I'm sane... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, 22 Feb 2005, Dirk Eddelbuettel wrote: files.downloaded percent i386 1285422 70.5079 all 504789 27.6886 powerpc17754 0.9738 ia64 10111 0.5546 sparc 3336 0.1830 arm 850 0.0466 alpha507 0.0278 hppa 204 0.0112 mipsel91 0.0050 m68k 15 0.0008 mips 7 0.0004 s390 4 0.0002 total1823090 100. These numbers show a cross-section of users who use this particular mirror. It is not represenative of the world as a whole. Far from it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
On Sat, Feb 19, 2005 at 12:13:34AM -0200, Henrique de Moraes Holschuh wrote: Also: As far as the kernel is concerned, any local IP is local to *all* interfaces, and it will happly reply to it (ARP and so on) if allowed to. The rp_filter will often avoid trouble here, BUT routers often have to disable rp_filter. So add some rules to the firewall make sure nothing gets into 127.0.0.0/8 unless it is a local packet. Can't you just leave rp_filter on for lo, or disable it only on those interfaces on which you are likely to see asymmetric routes arriving? -- --- Paul TBBle Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Bug#296520: ITP: yzis -- text editor inspired by vim
Package: wnpp Severity: wishlist Owner: Isaac Clerencia [EMAIL PROTECTED] * Package name: yzis Version : 0.0-M4 Upstream Author : Mickael Marchand [EMAIL PROTECTED] and others * URL : http://www.yzis.org/ * License : GPL (programs) / LGPL (libs) Description : text editor inspired by vim Yzis is a vim-compatible editor. The core of Yzis is a reusable vi engine, which can be embedded as an editor. Frontends are provided for ncurses, a standalone KDE application and the KDE component system KParts. . Yzis can be embedded into some KDE applications like KDevelop, Quanta, KMail and Konqueror. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
In article [EMAIL PROTECTED] you wrote: So, by this implication, if I use arping and pretend to be 127.0.0.1 to another host, that host will try to ping the network if I ping 127.0.0.1 on the target host? no, there are some obvious illegal addresses excluded. Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
amd64 is already the 2nd most important arch (WasRe: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Don Armstrong don at debian.org writes: On Tue, 22 Feb 2005, Dirk Eddelbuettel wrote: Thanks for cutting and completely ignoring the part where I demonstrated the lack of usage beyond i386 and maybe four or five other arches. You used package download results from one (1!) debian mirror to demonstrate the supposed lack of usage. However, those download stats only point to who is actually downloading packages with that architecture from only that mirror in a single month. These were the only public usage numbers, broken out by arch, from a primary mirror, that I am aware of. Which is why I used them. If you suspect that they are unrepresentative, you would greatly enhance the debate by providing additional data from the US, UK, DE, FR, JP, ... mirrors and actually proving me wrong -- rather than just calling the Earth flat. In any event, I found a way to complement these numbers -- using the upload reports from popcon.debian.org, taken earlier today. With a little emacs editing, we get the data file below, which is used by the few R commands include below as well. [1] reports percent hurd-i386 1 0.0175 kfreebsd-i386 1 0.0175 ppc64 1 0.0175 arm 2 0.0351 mipsel 2 0.0351 m68k3 0.0526 s3904 0.0702 mips5 0.0877 ia649 0.1579 hppa 12 0.2106 alpha 33 0.5790 sparc 47 0.8247 powerpc87 1.5266 amd64 257 4.5096 i386 5235 91.8582 total5699 100. Now this shows that *amd64 is already the second most important arch*. We are so busy looking after the arches used by basically nobody that we are not getting around to releasing with what is becoming *the* main alternative to i386. Oh boy. Dirk [1] I removed the entry unknown -- this corresponds to assuming that unknown as population corresponds to the distribution of all known dists shown here. Lacking knowledge of what drives unknown, this appears fair. If someone has a breakdown of unknown, I will gladly use it. [2] Raw data, stored in /tmp/popcon.txt reports alpha 33 amd64 257 arm 2 hppa 12 hurd-i386 1 i386 5235 ia64 9 kfreebsd-i386 1 m68k 3 mips 5 mipsel2 powerpc 87 ppc64 1 s390 4 sparc 47 unknown 1116 [3] Simple transformation script popcon.R Raw - read.table(/tmp/popcon.txt, header=TRUE, row.names=1) ind - which(Raw==Raw[unknown,1]) ## find row with unknown Dat - Raw[-ind,,drop=FALSE]## create new data.frame without it Dat - Dat[order(Dat[,1]),1,drop=FALSE] ## order by downloads Dat - rbind(Dat, total=sum(Dat[,1])) ## add a new row for totals Dat - cbind(Dat, ## add a percentage column percent=round(100*Dat[,1]/Dat[total,1], 4)) print(Dat) ## show result -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Let's get more data, please (Was: Let's remove mips, mipsel, s390, ... )
Adam Heath doogie at debian.org writes: On Tue, 22 Feb 2005, Dirk Eddelbuettel wrote: files.downloaded percent i386 1285422 70.5079 all 504789 27.6886 powerpc17754 0.9738 ia64 10111 0.5546 sparc 3336 0.1830 arm 850 0.0466 alpha507 0.0278 hppa 204 0.0112 mipsel91 0.0050 m68k 15 0.0008 mips 7 0.0004 s390 4 0.0002 total1823090 100. These numbers show a cross-section of users who use this particular mirror. It is not represenative of the world as a whole. Far from it. Thank you. You are about the fifth or sixth person who took the time to explain that to me. But guess what? I knew that too --- but these were *the only numbers* I had ever seem. As I just said in another follow-up, the debate would be helped greatly if we had data from more primary mirrors and/or popular hosts, and longer time frames. We actually need that data to have the qualitative discussion to determine at what point the cross-product of nArches * mSourcePackages is too much for our infrastructure. Lacking access to the actual apt-get usage data, I just posted another complimentary analysis using the data based on popcon.debian.org reports. You may find it interesting. It does not contradict the above in any meaningful way (esp. once you acknowledge that it is based on a smaller sample, and a potentially biased population of core Debian developers and supporters aware of popcon, as opposed to mompop just using apt). Regards, Dirk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64 is already the 2nd most important arch (WasRe: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Wed, Feb 23, 2005 at 03:08:11AM +, Dirk Eddelbuettel wrote: reports percent hurd-i386 1 0.0175 kfreebsd-i386 1 0.0175 ppc64 1 0.0175 arm 2 0.0351 mipsel 2 0.0351 m68k3 0.0526 s3904 0.0702 mips5 0.0877 ia649 0.1579 hppa 12 0.2106 alpha 33 0.5790 sparc 47 0.8247 powerpc87 1.5266 amd64 257 4.5096 i386 5235 91.8582 total5699 100. Now this shows that *amd64 is already the second most important arch*. We are so busy looking after the arches used by basically nobody that we are not getting around to releasing with what is becoming *the* main alternative to i386. Oops. You jumped from second most common to second most important, as if they're synonymous. Maybe they are to some people, but that's not at all beyond debate: AMD64 will probably be supported by all serious distributions, while Debian is, from what I recall, the *only* way to get a sensible Unix installation on many of the less common systems. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64 is already the 2nd most important arch (WasRe: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, 22 Feb 2005 22:25:25 -0500 Glenn Maynard [EMAIL PROTECTED] wrote: On Wed, Feb 23, 2005 at 03:08:11AM +, Dirk Eddelbuettel wrote: reports percent hurd-i386 1 0.0175 kfreebsd-i386 1 0.0175 ppc64 1 0.0175 arm 2 0.0351 mipsel 2 0.0351 m68k3 0.0526 s3904 0.0702 mips5 0.0877 ia649 0.1579 hppa 12 0.2106 alpha 33 0.5790 sparc 47 0.8247 powerpc87 1.5266 amd64 257 4.5096 i386 5235 91.8582 total5699 100. Now this shows that *amd64 is already the second most important arch*. We are so busy looking after the arches used by basically nobody that we are not getting around to releasing with what is becoming *the* main alternative to i386. Oops. You jumped from second most common to second most important, as if they're synonymous. Maybe they are to some people, but that's not at all beyond debate: AMD64 will probably be supported by all serious distributions, while Debian is, from what I recall, the *only* way to get a sensible Unix installation on many of the less common systems. Or you can debate whether something like a sparc and alpha will be used for more important projects than the average amd64. In that case, one sparc or alpha could carry more weight than one amd64. Important can be a totally different twist that's very open to definition. Jacob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64 is already the 2nd most important arch (WasRe: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, 2005-02-22 at 22:25 -0500, Glenn Maynard wrote: On Wed, Feb 23, 2005 at 03:08:11AM +, Dirk Eddelbuettel wrote: [snip] Oops. You jumped from second most common to second most important, as if they're synonymous. Maybe they are to some people, but that's not at all beyond debate: AMD64 will probably be supported by all serious distributions, while Debian is, from what I recall, the *only* way to get a sensible Unix installation on many of the less common systems. NetBSD? -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. Since when do business goals (profit) come before values, ethics, and decency? Dr. Laura Schlessinger Since the time of the writing of the Old Testament... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
MD5 sum for d-i isos
Could it be possible to have md5sums for d-i ISOs available at (http://www.debian.org/devel/debian-installer) ? Regards maykel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted attal 0.9.2-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 14 Feb 2005 09:35:58 +0100 Source: attal Binary: attal Architecture: source i386 Version: 0.9.2-1 Distribution: unstable Urgency: low Maintainer: Raphael Goulais [EMAIL PROTECTED] Changed-By: Raphael Goulais [EMAIL PROTECTED] Description: attal - turn-based strategy game Closes: 288742 Changes: attal (0.9.2-1) unstable; urgency=low . * New Upstream Release (Closes: #288742). Files: d394bdd7a1423582046a283a303b749f 613 games optional attal_0.9.2-1.dsc 626b04af425d51d5a2ba2f2cf78729e6 352776 games optional attal_0.9.2.orig.tar.gz e06591527f601f664071f544d11eb0f9 5975 games optional attal_0.9.2-1.diff.gz d3cdaed7c5acca02bc0ba2e3da09d107 941704 games optional attal_0.9.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCEGofjkvXTDjOnPoRAm0lAJ9EDbWJlYdLdUPuoNeMQQusnzTW0QCggPj6 j7nPd1cZ0Q33twy+G9NJGbk= =vJIk -END PGP SIGNATURE- Accepted: attal_0.9.2-1.diff.gz to pool/main/a/attal/attal_0.9.2-1.diff.gz attal_0.9.2-1.dsc to pool/main/a/attal/attal_0.9.2-1.dsc attal_0.9.2-1_i386.deb to pool/main/a/attal/attal_0.9.2-1_i386.deb attal_0.9.2.orig.tar.gz to pool/main/a/attal/attal_0.9.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gpx2shp 0.69-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 08:48:18 +0100 Source: gpx2shp Binary: gpx2shp Architecture: source i386 Version: 0.69-1 Distribution: unstable Urgency: low Maintainer: Petter Reinholdtsen [EMAIL PROTECTED] Changed-By: Petter Reinholdtsen [EMAIL PROTECTED] Description: gpx2shp- convert GPS or GPX file to ESRI Shape file Closes: 292614 Changes: gpx2shp (0.69-1) unstable; urgency=low . * New upstream release. - Fix segfault when only -v is used on the command line (Closes: #292614) * Patched Makefile.am to make sure 'make check' work out of the box, and to make sure the files generated by 'make check' are removed on 'make clean'. Files: 40c7a35738ff076aaf99f73a39d2d27c 582 science optional gpx2shp_0.69-1.dsc 2ec366e2bdb8e18b800e819bbcbcf603 201641 science optional gpx2shp_0.69.orig.tar.gz 04449a3348ca2702c39d4c5ef4c515ed 730 science optional gpx2shp_0.69-1.diff.gz 19e7952dd4f8e8bff7246f7c769cfa4f 35544 science optional gpx2shp_0.69-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCGumD20zMSyow1ykRAsTUAJ0YhUbTY7I1LKfeWNUsJ6iSrk5kogCeNknw wqE6gYRlr4CG6bt1t2kGOOU= =aouR -END PGP SIGNATURE- Accepted: gpx2shp_0.69-1.diff.gz to pool/main/g/gpx2shp/gpx2shp_0.69-1.diff.gz gpx2shp_0.69-1.dsc to pool/main/g/gpx2shp/gpx2shp_0.69-1.dsc gpx2shp_0.69-1_i386.deb to pool/main/g/gpx2shp/gpx2shp_0.69-1_i386.deb gpx2shp_0.69.orig.tar.gz to pool/main/g/gpx2shp/gpx2shp_0.69.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted attal-themes-medieval 0.9.2-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 14 Feb 2005 09:40:17 +0100 Source: attal-themes-medieval Binary: attal-themes-medieval Architecture: source all Version: 0.9.2-1 Distribution: unstable Urgency: low Maintainer: Raphael Goulais [EMAIL PROTECTED] Changed-By: Raphael Goulais [EMAIL PROTECTED] Description: attal-themes-medieval - medieval theme for attal Changes: attal-themes-medieval (0.9.2-1) unstable; urgency=low . * New Upstream Release Files: 91141237134c25f0e07783f36c4cdf11 626 games optional attal-themes-medieval_0.9.2-1.dsc 9f5f3f43dddbfce9d6944bc2310a5789 27197911 games optional attal-themes-medieval_0.9.2.orig.tar.gz ade57f267310b17c4d5ba391a6f25e35 1380 games optional attal-themes-medieval_0.9.2-1.diff.gz 856259239f086c5ea351adb17c56a058 27216258 games optional attal-themes-medieval_0.9.2-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCEGUTjkvXTDjOnPoRApGeAJ0RMeWR1SDVkWDwkV/Bx7Bdep8hQQCfYzml 1jhnj58sI1DFP08brvHwbQA= =kGeq -END PGP SIGNATURE- Accepted: attal-themes-medieval_0.9.2-1.diff.gz to pool/main/a/attal-themes-medieval/attal-themes-medieval_0.9.2-1.diff.gz attal-themes-medieval_0.9.2-1.dsc to pool/main/a/attal-themes-medieval/attal-themes-medieval_0.9.2-1.dsc attal-themes-medieval_0.9.2-1_all.deb to pool/main/a/attal-themes-medieval/attal-themes-medieval_0.9.2-1_all.deb attal-themes-medieval_0.9.2.orig.tar.gz to pool/main/a/attal-themes-medieval/attal-themes-medieval_0.9.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted afterstep 2.00.02-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Feb 2005 21:33:46 +0100 Source: afterstep Binary: libafterstep0 afterstep libafterimage-dev libafterimage0 Architecture: source i386 Version: 2.00.02-4 Distribution: unstable Urgency: medium Maintainer: Robert Luberda [EMAIL PROTECTED] Changed-By: Robert Luberda [EMAIL PROTECTED] Description: afterstep - window manager with the NEXTSTEP look and feel libafterimage-dev - imaging library designed for AfterStep - development files libafterimage0 - imaging library designed for AfterStep - runtime files libafterstep0 - shared libraries for the AfterStep window manager Changes: afterstep (2.00.02-4) unstable; urgency=medium . * Fix configure not to strip CFLAGS when setting NO_DEBUG_OUTPUT. Files: 82d258bb042ebd616763a397087acc51 823 x11 optional afterstep_2.00.02-4.dsc 634c46e61acdde4c58f5c9b5eb567939 46560 x11 optional afterstep_2.00.02-4.diff.gz 20a9957ee11bb2ed3d3a54eab7ecde50 3031416 x11 optional afterstep_2.00.02-4_i386.deb 39549f93767c71a50f91867c9aee5db0 256228 libs optional libafterstep0_2.00.02-4_i386.deb d773383f6d02342755a1b7178d71cd2d 250276 libs optional libafterimage0_2.00.02-4_i386.deb f0ef44cc9315301c48d27ad8d9b6d852 718438 libdevel optional libafterimage-dev_2.00.02-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCGklhThh1cJ0wnDsRAgZ0AJ9aY2nPEtrKrYqvNMGwMSsL/6eOtACePA6h yaTY+BvfOqKEmm0rgqKjJjs= =9A5w -END PGP SIGNATURE- Accepted: afterstep_2.00.02-4.diff.gz to pool/main/a/afterstep/afterstep_2.00.02-4.diff.gz afterstep_2.00.02-4.dsc to pool/main/a/afterstep/afterstep_2.00.02-4.dsc afterstep_2.00.02-4_i386.deb to pool/main/a/afterstep/afterstep_2.00.02-4_i386.deb libafterimage-dev_2.00.02-4_i386.deb to pool/main/a/afterstep/libafterimage-dev_2.00.02-4_i386.deb libafterimage0_2.00.02-4_i386.deb to pool/main/a/afterstep/libafterimage0_2.00.02-4_i386.deb libafterstep0_2.00.02-4_i386.deb to pool/main/a/afterstep/libafterstep0_2.00.02-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mma 0.12-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 09:55:03 +0100 Source: mma Binary: mma Architecture: source all Version: 0.12-1 Distribution: unstable Urgency: low Maintainer: Raphael Goulais [EMAIL PROTECTED] Changed-By: Raphael Goulais [EMAIL PROTECTED] Description: mma- Musical Midi Accompaniment generator Closes: 296303 Changes: mma (0.12-1) unstable; urgency=low . * New Upstream Release (Closes: #296303). Files: e3d8d217adff05fb3d849363c850088f 570 sound optional mma_0.12-1.dsc 69961e2d18b594c87ce0a858615590ba 1186769 sound optional mma_0.12.orig.tar.gz 846611975d6f2c9bb990c5b497a23b4e 2085 sound optional mma_0.12-1.diff.gz f0d324bd5fe0d182068ca7a9882e94f2 1183702 sound optional mma_0.12-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCGvUTjkvXTDjOnPoRAp0BAKCgIfAHor2xnTNPt1CjqkWcfgKtXwCcD8dw dQ1hUJTffLRcdPUaQdBLwYI= =4itU -END PGP SIGNATURE- Accepted: mma_0.12-1.diff.gz to pool/main/m/mma/mma_0.12-1.diff.gz mma_0.12-1.dsc to pool/main/m/mma/mma_0.12-1.dsc mma_0.12-1_all.deb to pool/main/m/mma/mma_0.12-1_all.deb mma_0.12.orig.tar.gz to pool/main/m/mma/mma_0.12.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted zapping 0.9.1-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 10:47:31 +0100 Source: zapping Binary: zapping Architecture: source i386 Version: 0.9.1-2 Distribution: unstable Urgency: low Maintainer: Christian Marillat [EMAIL PROTECTED] Changed-By: Christian Marillat [EMAIL PROTECTED] Description: zapping- television viewer for the GNOME environment Changes: zapping (0.9.1-2) unstable; urgency=low . * debian/rules Install the schemas file that the Makefile doesn't install. Files: 07ba1723908dec8b5cf58add527a1fa2 829 gnome extra zapping_0.9.1-2.dsc 14a446e7fd5c55237f1b4adb395fc7f8 18206 gnome extra zapping_0.9.1-2.diff.gz 1f56479ad388e93a96415be354da6d2c 903718 gnome extra zapping_0.9.1-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCGwN3B9xWPR9BuQcRApPtAKCInJWfTObEezAsL0aZ+Uvjq9C1SQCeKZOu PR/MZRmV8pXBewuQscbjIX8= =AdPK -END PGP SIGNATURE- Accepted: zapping_0.9.1-2.diff.gz to pool/main/z/zapping/zapping_0.9.1-2.diff.gz zapping_0.9.1-2.dsc to pool/main/z/zapping/zapping_0.9.1-2.dsc zapping_0.9.1-2_i386.deb to pool/main/z/zapping/zapping_0.9.1-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted octave2.1 2.1.65-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 09:39:05 +0100 Source: octave2.1 Binary: octave2.1-htmldoc octave octave2.1-info octave2.1-emacsen octave2.1 octave2.1-headers octave2.1-doc Architecture: source i386 all Version: 2.1.65-1 Distribution: unstable Urgency: low Maintainer: Debian Octave Group [EMAIL PROTECTED] Changed-By: Debian Octave Group [EMAIL PROTECTED] Description: octave - GNU Octave language for numerical computations (2.1 branch) octave2.1 - GNU Octave language for numerical computations (2.1 branch) octave2.1-doc - Postscript documentation on the GNU Octave language (2.1 branch) octave2.1-emacsen - Emacs support for the GNU Octave language (2.1 branch) octave2.1-headers - header files for the GNU Octave language (2.1 branch) octave2.1-htmldoc - HTML documentation on the GNU Octave language (2.1 branch) octave2.1-info - GNU Info documentation on the GNU Octave language (2.1 branch) Closes: 292917 293562 Changes: octave2.1 (2.1.65-1) unstable; urgency=low . +++ Changes by J. Rafael Rodriguez Galvan: . * New upstream release 2.1.65 released 24 hours ago . +++ Changes by Rafael Laboissiere . * debian/*.postinst.in, debian/*.prerm.in: Moved these files from the original *.postinst and *. prerm ones * debian/octave2.1.lintian.in: Idem from octave2.1.lintian * debian/defs.make, debian/octave-depends: Added files * debian/rules: - (configure-stamp) Generate *.postinst, *.prerm, and *.lintian by replacing the @VERSION@ string with the current Octave version number - (clean) Remove the *.postinst, *.prerm, *.lintian files generated automatically - (install) Install files defs.make and octave-depends in octave2.1-headers package * Install PDF documentation files instead of the PS ones. There is a pdfdocs variable in debian/rules now that control which files are built/installed. Build-Depends on tetex-bin. (Closes: #293562) . +++ Changes by Adam Conrad: . * Add logic to debian/rules and debian/control to make sure that octave2.1-headers depends on f2c on m68k (closes: #292917) Files: 718ca056796519826670c9a529f736be 931 math optional octave2.1_2.1.65-1.dsc dc46aaf22b7e37b32a36d5d79ea82566 5517306 math optional octave2.1_2.1.65.orig.tar.gz a19dc1e7a086796bdaf4f166961e7acc 29044 math optional octave2.1_2.1.65-1.diff.gz c087d3cf0e67ec56650c631e880a0803 5703648 math optional octave2.1_2.1.65-1_i386.deb 150438ac91d8e68c9d51e523218a92d1 261022 math optional octave2.1-headers_2.1.65-1_i386.deb 2321a3bc70e6a33b4c396fe2b94f9d43 45012 math optional octave_2.1.65-1_i386.deb 70cdaecc2fc9d4af939a08369b543d98 1777054 doc optional octave2.1-doc_2.1.65-1_all.deb fab5f465124b932bbcdc0a065e2322e7 383416 math optional octave2.1-htmldoc_2.1.65-1_all.deb 56e3ed3e732dd510b7356fbd0245c3cc 68312 math optional octave2.1-emacsen_2.1.65-1_all.deb 458c1bb392f189f0f3faf0dd8e63da2e 301994 math optional octave2.1-info_2.1.65-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCGwi9k3oga0pdcv4RAqR5AJ446HR3Ed2S13VdX0ZJoKhrsODuuACaAtVf 94HxGx6NNe++S8pOjGBlPwY= =DTUs -END PGP SIGNATURE- Accepted: octave2.1-doc_2.1.65-1_all.deb to pool/main/o/octave2.1/octave2.1-doc_2.1.65-1_all.deb octave2.1-emacsen_2.1.65-1_all.deb to pool/main/o/octave2.1/octave2.1-emacsen_2.1.65-1_all.deb octave2.1-headers_2.1.65-1_i386.deb to pool/main/o/octave2.1/octave2.1-headers_2.1.65-1_i386.deb octave2.1-htmldoc_2.1.65-1_all.deb to pool/main/o/octave2.1/octave2.1-htmldoc_2.1.65-1_all.deb octave2.1-info_2.1.65-1_all.deb to pool/main/o/octave2.1/octave2.1-info_2.1.65-1_all.deb octave2.1_2.1.65-1.diff.gz to pool/main/o/octave2.1/octave2.1_2.1.65-1.diff.gz octave2.1_2.1.65-1.dsc to pool/main/o/octave2.1/octave2.1_2.1.65-1.dsc octave2.1_2.1.65-1_i386.deb to pool/main/o/octave2.1/octave2.1_2.1.65-1_i386.deb octave2.1_2.1.65.orig.tar.gz to pool/main/o/octave2.1/octave2.1_2.1.65.orig.tar.gz octave_2.1.65-1_i386.deb to pool/main/o/octave2.1/octave_2.1.65-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted hawxy 1.1.0-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 5 Aug 2003 18:01:31 +0100 Source: hawxy Binary: hawxy Architecture: source all Version: 1.1.0-2 Distribution: unstable Urgency: low Maintainer: Debian QA Group [EMAIL PROTECTED] Changed-By: Neil McGovern [EMAIL PROTECTED] Description: hawxy - a script that makes PHP-enabled webservers to HAWHAW proxies Changes: hawxy (1.1.0-2) unstable; urgency=low . * Orphaning Files: 1766524f2b1312a6de982a4b31d59729 574 web optional hawxy_1.1.0-2.dsc ec38b44ed815ac2711fe29deb88cb822 3300 web optional hawxy_1.1.0-2.diff.gz f922f7e337ca3d1dc9704d7be78e8c88 12554 web optional hawxy_1.1.0-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCGxT697LBwbNFvdMRAtGTAJ4jj+/vzndWitSmGIMN8JN654MepgCeL3UE Aey8i0IGGs3FELIjPZfYwBA= =jSGd -END PGP SIGNATURE- Accepted: hawxy_1.1.0-2.diff.gz to pool/main/h/hawxy/hawxy_1.1.0-2.diff.gz hawxy_1.1.0-2.dsc to pool/main/h/hawxy/hawxy_1.1.0-2.dsc hawxy_1.1.0-2_all.deb to pool/main/h/hawxy/hawxy_1.1.0-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted hawhaw 5.1.0-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 5 Aug 2003 18:01:10 +0100 Source: hawhaw Binary: libphp-hawhaw Architecture: source all Version: 5.1.0-2 Distribution: unstable Urgency: low Maintainer: Debian QA Group [EMAIL PROTECTED] Changed-By: Neil McGovern [EMAIL PROTECTED] Description: libphp-hawhaw - a PHP toolkit to create universal mobile applications Changes: hawhaw (5.1.0-2) unstable; urgency=low . * Orphaning Files: 46c41d9f6014650be1c8f3510703927e 586 web optional hawhaw_5.1.0-2.dsc dbb3e212fb88bca3465ee2e3b53f859e 3139 web optional hawhaw_5.1.0-2.diff.gz cecb278712408ff0b07b2b164e7611dd 32444 web optional libphp-hawhaw_5.1.0-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCGxJh97LBwbNFvdMRAroNAJ4ppWgMytRfdCxxIOiWTBOvfyeg7wCfV2No W/oPT8dAbW3UL+WMRYF92uc= =OO6j -END PGP SIGNATURE- Accepted: hawhaw_5.1.0-2.diff.gz to pool/main/h/hawhaw/hawhaw_5.1.0-2.diff.gz hawhaw_5.1.0-2.dsc to pool/main/h/hawhaw/hawhaw_5.1.0-2.dsc libphp-hawhaw_5.1.0-2_all.deb to pool/main/h/hawhaw/libphp-hawhaw_5.1.0-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted drivel 1.2.4-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 27 Jan 2005 01:31:08 + Source: drivel Binary: drivel Architecture: source i386 Version: 1.2.4-1 Distribution: unstable Urgency: low Maintainer: Neil McGovern [EMAIL PROTECTED] Changed-By: Neil McGovern [EMAIL PROTECTED] Description: drivel - LiveJournal client for the GNOME desktop Changes: drivel (1.2.4-1) unstable; urgency=low . * New upstream release * Change of maintainer email address Files: f27bc277eb90bdffe4335278415e3a9f 884 net optional drivel_1.2.4-1.dsc 6ba7a07361c0cc1102e26c796beb233b 730281 net optional drivel_1.2.4.orig.tar.gz d80e770202755eb69a1af698c7414506 37464 net optional drivel_1.2.4-1.diff.gz 798a26b7223b1621891229afb30886cb 248570 net optional drivel_1.2.4-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCGxbW97LBwbNFvdMRAhBeAJoCbWDn/Avy4888bjiS1Bi8FhxAQwCeLK/N 0m7S8oc/6vViiKDp0523Mhk= =Zrfv -END PGP SIGNATURE- Accepted: drivel_1.2.4-1.diff.gz to pool/main/d/drivel/drivel_1.2.4-1.diff.gz drivel_1.2.4-1.dsc to pool/main/d/drivel/drivel_1.2.4-1.dsc drivel_1.2.4-1_i386.deb to pool/main/d/drivel/drivel_1.2.4-1_i386.deb drivel_1.2.4.orig.tar.gz to pool/main/d/drivel/drivel_1.2.4.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kernel-patch-2.4.27-arm 2.4.27-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 18 Nov 2004 12:51:30 + Source: kernel-patch-2.4.27-arm Binary: kernel-patch-2.4.27-arm Architecture: source all Version: 2.4.27-1 Distribution: unstable Urgency: low Maintainer: Vincent Sanders [EMAIL PROTECTED] Changed-By: Vincent Sanders [EMAIL PROTECTED] Description: kernel-patch-2.4.27-arm - Diffs to the Linux kernel source 2.4.27 for ARM Changes: kernel-patch-2.4.27-arm (2.4.27-1) unstable; urgency=low . * Update head code with zImage fix for nettrom bootloader * Ensure patch works correctly with updated Debian kernel source Files: d7693c232405d8c9bb77ac8970fdc740 565 devel extra kernel-patch-2.4.27-arm_2.4.27-1.dsc 306d6c255da2469d518acd2addd07ef7 828116 devel extra kernel-patch-2.4.27-arm_2.4.27-1.tar.gz 9189b917190df307ff8cf92ec774bf82 832402 devel extra kernel-patch-2.4.27-arm_2.4.27-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCGw7QiUwwPOvjHvURArBqAKD04O5wSlsv5SBZMhc8TEib6eufnwCgj3/2 b+UqL5qWTT/Eh7S2fXI33+c= =ujMt -END PGP SIGNATURE- Accepted: kernel-patch-2.4.27-arm_2.4.27-1.dsc to pool/main/k/kernel-patch-2.4.27-arm/kernel-patch-2.4.27-arm_2.4.27-1.dsc kernel-patch-2.4.27-arm_2.4.27-1.tar.gz to pool/main/k/kernel-patch-2.4.27-arm/kernel-patch-2.4.27-arm_2.4.27-1.tar.gz kernel-patch-2.4.27-arm_2.4.27-1_all.deb to pool/main/k/kernel-patch-2.4.27-arm/kernel-patch-2.4.27-arm_2.4.27-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kernel-image-2.4.27-arm 2.4.27-1 (arm source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 18 Nov 2004 12:35:28 + Source: kernel-image-2.4.27-arm Binary: kernel-headers-2.4.27 kernel-build-2.4.27 kernel-image-2.4.27-bast kernel-image-2.4.27-riscstation kernel-image-2.4.27-riscpc kernel-image-2.4.27-netwinder kernel-image-2.4.27-lart Architecture: source arm Version: 2.4.27-1 Distribution: unstable Urgency: low Maintainer: Vincent Sanders [EMAIL PROTECTED] Changed-By: Vincent Sanders [EMAIL PROTECTED] Description: kernel-build-2.4.27 - Headers for building modules for Linux 2.4.27 kernel-headers-2.4.27 - Header files related to Linux kernel version 2.4.27 kernel-image-2.4.27-bast - Linux kernel image for version 2.4.27 for Bast. kernel-image-2.4.27-lart - Linux kernel image for version 2.4.27 for LART. kernel-image-2.4.27-netwinder - Linux kernel image for version 2.4.27 for Netwinder. kernel-image-2.4.27-riscpc - Linux kernel image for version 2.4.27 for RiscPC. kernel-image-2.4.27-riscstation - Linux kernel image for version 2.4.27 for Riscstations. Changes: kernel-image-2.4.27-arm (2.4.27-1) unstable; urgency=low . * Updated source package to fix issue with some bootloaders and their inability to use non zImage tagged kernels. * Update netwinder config to use VESA VGA framebuffer driver Files: e0c8512d424680587db6769c3e4fc13c 804 devel optional kernel-image-2.4.27-arm_2.4.27-1.dsc 359cc8bf2c7fdc575adc42557c3254c3 32033 devel optional kernel-image-2.4.27-arm_2.4.27-1.tar.gz 250502bc65fb21e67a7f5a0dc5d574c1 4656500 devel optional kernel-headers-2.4.27_2.4.27-1_arm.deb bc74e5e57872ef936592374f1e663253 1629962 base optional kernel-image-2.4.27-bast_2.4.27-1_arm.deb 11ad32dbd14ddf769e18f1694c0fdd83 1018540 base optional kernel-image-2.4.27-lart_2.4.27-1_arm.deb ee3277df2f2c73fd32a06a466f8d8fff 7087854 base optional kernel-image-2.4.27-netwinder_2.4.27-1_arm.deb 9eed91abbb4da62f6de7339217b3f202 3048164 base optional kernel-image-2.4.27-riscpc_2.4.27-1_arm.deb fbadb8eba6b2ec1c05dad6c7db21f702 3546494 base optional kernel-image-2.4.27-riscstation_2.4.27-1_arm.deb 53a0e3574f39e4dae0f4d27e5f138ca6 462918 devel optional kernel-build-2.4.27_2.4.27-1_arm.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCGyMyiUwwPOvjHvURAkPhAJ0bUrPfPAJjdCh0b5RRHLnhurIvAwCg/IlB VOsORcpN0DJBcGq5JdDdDyw= =io8G -END PGP SIGNATURE- Accepted: kernel-build-2.4.27_2.4.27-1_arm.deb to pool/main/k/kernel-image-2.4.27-arm/kernel-build-2.4.27_2.4.27-1_arm.deb kernel-headers-2.4.27_2.4.27-1_arm.deb to pool/main/k/kernel-image-2.4.27-arm/kernel-headers-2.4.27_2.4.27-1_arm.deb kernel-image-2.4.27-arm_2.4.27-1.dsc to pool/main/k/kernel-image-2.4.27-arm/kernel-image-2.4.27-arm_2.4.27-1.dsc kernel-image-2.4.27-arm_2.4.27-1.tar.gz to pool/main/k/kernel-image-2.4.27-arm/kernel-image-2.4.27-arm_2.4.27-1.tar.gz kernel-image-2.4.27-bast_2.4.27-1_arm.deb to pool/main/k/kernel-image-2.4.27-arm/kernel-image-2.4.27-bast_2.4.27-1_arm.deb kernel-image-2.4.27-lart_2.4.27-1_arm.deb to pool/main/k/kernel-image-2.4.27-arm/kernel-image-2.4.27-lart_2.4.27-1_arm.deb kernel-image-2.4.27-netwinder_2.4.27-1_arm.deb to pool/main/k/kernel-image-2.4.27-arm/kernel-image-2.4.27-netwinder_2.4.27-1_arm.deb kernel-image-2.4.27-riscpc_2.4.27-1_arm.deb to pool/main/k/kernel-image-2.4.27-arm/kernel-image-2.4.27-riscpc_2.4.27-1_arm.deb kernel-image-2.4.27-riscstation_2.4.27-1_arm.deb to pool/main/k/kernel-image-2.4.27-arm/kernel-image-2.4.27-riscstation_2.4.27-1_arm.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted aspell-pl 20050222-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 15:04:33 +0100 Source: aspell-pl Binary: aspell-pl Architecture: source i386 Version: 20050222-1 Distribution: unstable Urgency: low Maintainer: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] Changed-By: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] Description: aspell-pl - alternative Polish dictionary for aspell Closes: 295871 Changes: aspell-pl (20050222-1) unstable; urgency=low . * New upstream release * debian/control - cdbs added to build-depends (closes: #295871) Files: dd7bad68e6a78eb557a72fac11974447 619 text optional aspell-pl_20050222-1.dsc baf9fa592b6008cd638cd0587e51051a 1067952 text optional aspell-pl_20050222.orig.tar.gz a532b9b60c80d415ab2aa0bc96500f5a 6514 text optional aspell-pl_20050222-1.diff.gz fb8d17b8ef707e87d54fb8e7c6370c09 21094222 text optional aspell-pl_20050222-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCGz1J+NMfSd6w7DERAoWuAJsHyOXiQYLtNi1o3v2jtN+0LsDcAgCeK9F6 H+heMy01auPpv0vIjrY0a9U= =vaf4 -END PGP SIGNATURE- Accepted: aspell-pl_20050222-1.diff.gz to pool/main/a/aspell-pl/aspell-pl_20050222-1.diff.gz aspell-pl_20050222-1.dsc to pool/main/a/aspell-pl/aspell-pl_20050222-1.dsc aspell-pl_20050222-1_i386.deb to pool/main/a/aspell-pl/aspell-pl_20050222-1_i386.deb aspell-pl_20050222.orig.tar.gz to pool/main/a/aspell-pl/aspell-pl_20050222.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dictionaries-common 0.24.10 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 15:45:08 +0100 Source: dictionaries-common Binary: dictionaries-common-dev dictionaries-common Architecture: source all Version: 0.24.10 Distribution: unstable Urgency: low Maintainer: Agustin Martin Domingo [EMAIL PROTECTED] Changed-By: Agustin Martin Domingo [EMAIL PROTECTED] Description: dictionaries-common - Common utilities for spelling dictionary tools dictionaries-common-dev - Developer tools and Policy for spelling dictionary tools Closes: 296305 296411 Changes: dictionaries-common (0.24.10) unstable; urgency=low . * debian/po: - Updated Galician debconf templates translation, thanks to Jacobo Tarrio (closes: #296305). - Added new Tagalog debconf templates translation, thanks to Eric Pareja (closes: #296411) * scripts/system/update-ispell-hash: - Added to the CVS and the sources, but not yet installed. Files: 31f0598f179b1577f7f5d9924441276f 735 text standard dictionaries-common_0.24.10.dsc 344058c9544e0b933f29b165648ffec5 211381 text standard dictionaries-common_0.24.10.tar.gz 6b439694c389b74e1241d76125ae27f6 191870 text standard dictionaries-common_0.24.10_all.deb 1db1b302052af5422587a25b645e9b1b 92306 text optional dictionaries-common-dev_0.24.10_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCG0Y/WMZwCEWXpZMRAkz3AKChpTSLZkEF+d3BT/i2FuDmjcU2TgCgmZES oH0AZtR+lnK5WPb6HWZdx4s= =DJS/ -END PGP SIGNATURE- Accepted: dictionaries-common-dev_0.24.10_all.deb to pool/main/d/dictionaries-common/dictionaries-common-dev_0.24.10_all.deb dictionaries-common_0.24.10.dsc to pool/main/d/dictionaries-common/dictionaries-common_0.24.10.dsc dictionaries-common_0.24.10.tar.gz to pool/main/d/dictionaries-common/dictionaries-common_0.24.10.tar.gz dictionaries-common_0.24.10_all.deb to pool/main/d/dictionaries-common/dictionaries-common_0.24.10_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libsigc++-2.0 2.0.10-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 11:26:44 -0500 Source: libsigc++-2.0 Binary: libsigc++-2.0-0 libsigc++-2.0-doc libsigc++-2.0-dev Architecture: source all i386 Version: 2.0.10-1 Distribution: unstable Urgency: low Maintainer: Daniel Burrows [EMAIL PROTECTED] Changed-By: Daniel Burrows [EMAIL PROTECTED] Description: libsigc++-2.0-0 - type-safe Signal Framework for C++ - runtime libsigc++-2.0-dev - type-safe Signal Framework for C++ - development files libsigc++-2.0-doc - type-safe Signal Framework for C++ - reference documentation Changes: libsigc++-2.0 (2.0.10-1) unstable; urgency=low . * New upstream release Files: 2b4a6e8059ff12ea16834aacfa59df03 655 devel optional libsigc++-2.0_2.0.10-1.dsc 1c66ca1edafb378324e91c01b02929a6 2206826 devel optional libsigc++-2.0_2.0.10.orig.tar.gz 5d2f455ad3a59fbfb15cec3a2305eb7b 5244 devel optional libsigc++-2.0_2.0.10-1.diff.gz af062182bdb4f9e0f86f97865698637c 30450 libs optional libsigc++-2.0-0_2.0.10-1_i386.deb 0d24e02f8b4d6677718db77b6fba380f 132038 libdevel optional libsigc++-2.0-dev_2.0.10-1_i386.deb bf41a9ac06aae12976a343d706b52d34 1469570 doc optional libsigc++-2.0-doc_2.0.10-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCG15Qch6xsM7kSXgRAgCHAJ495DfvS37KyF4qWzE1QWkHt+T4jACgiIJz sBmT3+shXGO8vYqEJ1d1PK4= =jwNH -END PGP SIGNATURE- Accepted: libsigc++-2.0-0_2.0.10-1_i386.deb to pool/main/libs/libsigc++-2.0/libsigc++-2.0-0_2.0.10-1_i386.deb libsigc++-2.0-dev_2.0.10-1_i386.deb to pool/main/libs/libsigc++-2.0/libsigc++-2.0-dev_2.0.10-1_i386.deb libsigc++-2.0-doc_2.0.10-1_all.deb to pool/main/libs/libsigc++-2.0/libsigc++-2.0-doc_2.0.10-1_all.deb libsigc++-2.0_2.0.10-1.diff.gz to pool/main/libs/libsigc++-2.0/libsigc++-2.0_2.0.10-1.diff.gz libsigc++-2.0_2.0.10-1.dsc to pool/main/libs/libsigc++-2.0/libsigc++-2.0_2.0.10-1.dsc libsigc++-2.0_2.0.10.orig.tar.gz to pool/main/libs/libsigc++-2.0/libsigc++-2.0_2.0.10.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted egg 4.0.6+0.20041122cvs-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 23 Feb 2005 01:58:15 +0900 Source: egg Binary: egg Architecture: source all Version: 4.0.6+0.20041122cvs-2 Distribution: unstable Urgency: low Maintainer: ISHIKAWA Mutsumi [EMAIL PROTECTED] Changed-By: ISHIKAWA Mutsumi [EMAIL PROTECTED] Description: egg- Tamago Ver. 4 -- EGG Input Method Architecture for Emacsen Changes: egg (4.0.6+0.20041122cvs-2) unstable; urgency=low . * fix eggrc wnn7 entry * fix Wnn server connect error from client running on 64bit environment to server running on 32bit environment. * add Wnn8 support Files: 5668c5217eec71fcb39b39d939e7a733 598 utils extra egg_4.0.6+0.20041122cvs-2.dsc 5cad905bb39a11d830e9898949dcf496 16000 utils extra egg_4.0.6+0.20041122cvs-2.diff.gz a25ac092f13485dfefb54e557681b5dc 160486 utils extra egg_4.0.6+0.20041122cvs-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iEYEARECAAYFAkIbZdkACgkQfi8w7uypT6iTWgCdHam6OmyluFcQ5OqJQyVc64+3 7fkAnRtNhmaYHB3heAcTXUlwZnKLaqwL =DFlI -END PGP SIGNATURE- Accepted: egg_4.0.6+0.20041122cvs-2.diff.gz to pool/main/e/egg/egg_4.0.6+0.20041122cvs-2.diff.gz egg_4.0.6+0.20041122cvs-2.dsc to pool/main/e/egg/egg_4.0.6+0.20041122cvs-2.dsc egg_4.0.6+0.20041122cvs-2_all.deb to pool/main/e/egg/egg_4.0.6+0.20041122cvs-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kbd-chooser 1.10 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 11:57:11 -0500 Source: kbd-chooser Binary: kbd-chooser Architecture: source i386 Version: 1.10 Distribution: unstable Urgency: high Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Joey Hess [EMAIL PROTECTED] Description: kbd-chooser - Detect a keyboard and select layout (udeb) Closes: 296264 Changes: kbd-chooser (1.10) unstable; urgency=high . * Joey Hess - Patch from Eugeniy Meshcheryako to do the same for Ukrainian keymap as was earlier done for other non-unicode, non-latin-1 languages in version 1.05. Closes: #296264 Files: 2f6a84575de0a5d9e52fa7c97a5a9010 785 debian-installer optional kbd-chooser_1.10.dsc 51af966aa366ded5292b3ed38edd92e1 67837 debian-installer optional kbd-chooser_1.10.tar.gz 43ef67ed6298242ac1c53543090e8b0b 36108 debian-installer optional kbd-chooser_1.10_i386.udeb package-type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCG2Yy2tp5zXiKP0wRAvM6AKDIPxlHnuSLUiIOMowgbF1urqTKhgCgn0h8 6T8l4PMLdSpq4YOk2hjlA6g= =9ouW -END PGP SIGNATURE- Accepted: kbd-chooser_1.10.dsc to pool/main/k/kbd-chooser/kbd-chooser_1.10.dsc kbd-chooser_1.10.tar.gz to pool/main/k/kbd-chooser/kbd-chooser_1.10.tar.gz kbd-chooser_1.10_i386.udeb to pool/main/k/kbd-chooser/kbd-chooser_1.10_i386.udeb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cl-uffi 1.4.32-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 10:10:03 -0700 Source: cl-uffi Binary: cl-uffi-tests cl-uffi Architecture: source all i386 Version: 1.4.32-1 Distribution: unstable Urgency: low Maintainer: Kevin M. Rosenberg [EMAIL PROTECTED] Changed-By: Kevin M. Rosenberg [EMAIL PROTECTED] Description: cl-uffi- Universal Foreign Function Library for Common Lisp cl-uffi-tests - Regression tests for UFFI Common Lisp Library Changes: cl-uffi (1.4.32-1) unstable; urgency=low . * New upstream Files: 64afc97cdadbbed03a6e5735d8da40b6 636 devel optional cl-uffi_1.4.32-1.dsc 8dbd5813e04a6ce6700cbb27a3993f05 141274 devel optional cl-uffi_1.4.32.orig.tar.gz 3393edff697143c065c2d6865f62a0e6 7401 devel optional cl-uffi_1.4.32-1.diff.gz 3dc203806b907fa16867594ee7758fcd 111392 devel optional cl-uffi_1.4.32-1_all.deb ea217ecc92dc001ce5b3d882e7d7d96a 23740 devel optional cl-uffi-tests_1.4.32-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCG29nES7N8sSjgj4RAgzuAJ9c/Ti6zuS3ZuO7Ry2PXhHIZd0DkwCfdnPN mGNEMit25m00gYLKn/z/4VI= =kfz/ -END PGP SIGNATURE- Accepted: cl-uffi-tests_1.4.32-1_i386.deb to pool/main/c/cl-uffi/cl-uffi-tests_1.4.32-1_i386.deb cl-uffi_1.4.32-1.diff.gz to pool/main/c/cl-uffi/cl-uffi_1.4.32-1.diff.gz cl-uffi_1.4.32-1.dsc to pool/main/c/cl-uffi/cl-uffi_1.4.32-1.dsc cl-uffi_1.4.32-1_all.deb to pool/main/c/cl-uffi/cl-uffi_1.4.32-1_all.deb cl-uffi_1.4.32.orig.tar.gz to pool/main/c/cl-uffi/cl-uffi_1.4.32.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tellico 0.13.3-1 (all source ia64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 15 Feb 2005 19:22:45 + Source: tellico Binary: bookcase tellico Architecture: source ia64 all Version: 0.13.3-1 Distribution: unstable Urgency: low Maintainer: Regis Boudin [EMAIL PROTECTED] Changed-By: Regis Boudin [EMAIL PROTECTED] Description: bookcase - collection manager for books, videos, music (dummy package) tellico- collection manager for books, videos, music Changes: tellico (0.13.3-1) unstable; urgency=low . * New upstream release, mainly for a configure problem with FreeBSD * Include the fix for RIS importer from upstream website Files: 20ba1a0610dd6d1168dcf007817b7bf7 726 kde optional tellico_0.13.3-1.dsc d886062a9e0accb00b1085bfc9daef23 2365007 kde optional tellico_0.13.3.orig.tar.gz 74796c137ec85dc4c864a90608f4432f 6169 kde optional tellico_0.13.3-1.diff.gz e1165ad83b31970ed71aaf747eff6785 12482 kde optional bookcase_0.13.3-1_all.deb 3b5835d21286b4a8ac6e7a73979089dc 1774488 kde optional tellico_0.13.3-1_ia64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCG2ss6C9Gf0Oh4wgRAqW5AKCztXcpT3H9QWwLtRY7YBXmzWzvLgCgpWd6 zgdexfrFceT9oxzIjS5QrRg= =UpnT -END PGP SIGNATURE- Accepted: bookcase_0.13.3-1_all.deb to pool/main/t/tellico/bookcase_0.13.3-1_all.deb tellico_0.13.3-1.diff.gz to pool/main/t/tellico/tellico_0.13.3-1.diff.gz tellico_0.13.3-1.dsc to pool/main/t/tellico/tellico_0.13.3-1.dsc tellico_0.13.3-1_ia64.deb to pool/main/t/tellico/tellico_0.13.3-1_ia64.deb tellico_0.13.3.orig.tar.gz to pool/main/t/tellico/tellico_0.13.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kernel-image-2.4.27-arm 2.4.27-2 (arm source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 13:42:01 + Source: kernel-image-2.4.27-arm Binary: kernel-headers-2.4.27 kernel-build-2.4.27 kernel-image-2.4.27-bast kernel-image-2.4.27-riscstation kernel-image-2.4.27-riscpc kernel-image-2.4.27-netwinder kernel-image-2.4.27-lart Architecture: source arm Version: 2.4.27-2 Distribution: unstable Urgency: low Maintainer: Vincent Sanders [EMAIL PROTECTED] Changed-By: Vincent Sanders [EMAIL PROTECTED] Description: kernel-build-2.4.27 - Headers for building modules for Linux 2.4.27 kernel-headers-2.4.27 - Header files related to Linux kernel version 2.4.27 kernel-image-2.4.27-bast - Linux kernel image for version 2.4.27 for Bast. kernel-image-2.4.27-lart - Linux kernel image for version 2.4.27 for LART. kernel-image-2.4.27-netwinder - Linux kernel image for version 2.4.27 for Netwinder. kernel-image-2.4.27-riscpc - Linux kernel image for version 2.4.27 for RiscPC. kernel-image-2.4.27-riscstation - Linux kernel image for version 2.4.27 for Riscstations. Changes: kernel-image-2.4.27-arm (2.4.27-2) unstable; urgency=low . * Rebuild to avoid bug #296443 Files: 3ea7d3f902c0c7c09dcef95f1f447348 804 devel optional kernel-image-2.4.27-arm_2.4.27-2.dsc 1435fd8f53eecd8c062494d9dd4b4bc8 32072 devel optional kernel-image-2.4.27-arm_2.4.27-2.tar.gz 78acaf1e5893c868960a1588224382e5 4656612 devel optional kernel-headers-2.4.27_2.4.27-2_arm.deb 0c2507946b67d66cb1fb95a04ed799c3 1630018 base optional kernel-image-2.4.27-bast_2.4.27-2_arm.deb cef3695b3f810df1c1f46c514a45 1018590 base optional kernel-image-2.4.27-lart_2.4.27-2_arm.deb 4c95a99d40697ca4ad914c17ce6f3bd9 7087982 base optional kernel-image-2.4.27-netwinder_2.4.27-2_arm.deb 263c334cc8447558e89bedf66d681912 3048212 base optional kernel-image-2.4.27-riscpc_2.4.27-2_arm.deb 7beb4418ddcf55d1db51faf6860cb088 3546670 base optional kernel-image-2.4.27-riscstation_2.4.27-2_arm.deb ffa2bcd3cff1621f928ce6d6d8c34f0f 462868 devel optional kernel-build-2.4.27_2.4.27-2_arm.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCG2R+iUwwPOvjHvURAqu3AJ9bOV4JvoOXK2/wHB/VTPY79BqE4wCeMwtb 5LFLmdsmG4Auh5vwdm0oFKQ= =IVWq -END PGP SIGNATURE- Accepted: kernel-build-2.4.27_2.4.27-2_arm.deb to pool/main/k/kernel-image-2.4.27-arm/kernel-build-2.4.27_2.4.27-2_arm.deb kernel-headers-2.4.27_2.4.27-2_arm.deb to pool/main/k/kernel-image-2.4.27-arm/kernel-headers-2.4.27_2.4.27-2_arm.deb kernel-image-2.4.27-arm_2.4.27-2.dsc to pool/main/k/kernel-image-2.4.27-arm/kernel-image-2.4.27-arm_2.4.27-2.dsc kernel-image-2.4.27-arm_2.4.27-2.tar.gz to pool/main/k/kernel-image-2.4.27-arm/kernel-image-2.4.27-arm_2.4.27-2.tar.gz kernel-image-2.4.27-bast_2.4.27-2_arm.deb to pool/main/k/kernel-image-2.4.27-arm/kernel-image-2.4.27-bast_2.4.27-2_arm.deb kernel-image-2.4.27-lart_2.4.27-2_arm.deb to pool/main/k/kernel-image-2.4.27-arm/kernel-image-2.4.27-lart_2.4.27-2_arm.deb kernel-image-2.4.27-netwinder_2.4.27-2_arm.deb to pool/main/k/kernel-image-2.4.27-arm/kernel-image-2.4.27-netwinder_2.4.27-2_arm.deb kernel-image-2.4.27-riscpc_2.4.27-2_arm.deb to pool/main/k/kernel-image-2.4.27-arm/kernel-image-2.4.27-riscpc_2.4.27-2_arm.deb kernel-image-2.4.27-riscstation_2.4.27-2_arm.deb to pool/main/k/kernel-image-2.4.27-arm/kernel-image-2.4.27-riscstation_2.4.27-2_arm.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted g-wrap 1.9.4-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 18:47:08 +0100 Source: g-wrap Binary: g-wrap guile-g-wrap libgwrap-runtime0 libgwrap-runtime0-dev Architecture: source i386 Version: 1.9.4-2 Distribution: unstable Urgency: low Maintainer: Andreas Rottmann [EMAIL PROTECTED] Changed-By: Andreas Rottmann [EMAIL PROTECTED] Description: g-wrap - scripting interface generator for C guile-g-wrap - scripting interface generator for C - Guile runtime libgwrap-runtime0 - scripting interface generator for C - runtime libgwrap-runtime0-dev - scripting interface generator for C - runtime Changes: g-wrap (1.9.4-2) unstable; urgency=low . * Applied upstream bugfix [EMAIL PROTECTED]/g-wrap--dev--0--patch-9. * debian/rules: Thighten shlib dependency info due to the bugfix. Files: 9b7979e56134b6b5c841d3bdcb8fe01d 748 interpreters optional g-wrap_1.9.4-2.dsc 7ace1ffeaacec5eac6e5de4f781ce84f 2999 interpreters optional g-wrap_1.9.4-2.diff.gz c0382c4a155a740f95d0d267886f415a 36974 interpreters optional g-wrap_1.9.4-2_i386.deb f3b436211470a8be7a1fe71b8f134a56 24864 libs optional libgwrap-runtime0-dev_1.9.4-2_i386.deb 843dabcba2916d4c69202446734d9d2f 21468 libs optional libgwrap-runtime0_1.9.4-2_i386.deb d7929b14d6d49ca17a6013b9ec402189 17844 interpreters optional guile-g-wrap_1.9.4-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCG3Tx+S/PxQH9W2IRAp0oAJ98gLkmSRg3E7pyMgfIgy8Ar0+dcwCZAQj4 91uMhMaiadul/qJVO6NbpDM= =y4Fc -END PGP SIGNATURE- Accepted: g-wrap_1.9.4-2.diff.gz to pool/main/g/g-wrap/g-wrap_1.9.4-2.diff.gz g-wrap_1.9.4-2.dsc to pool/main/g/g-wrap/g-wrap_1.9.4-2.dsc g-wrap_1.9.4-2_i386.deb to pool/main/g/g-wrap/g-wrap_1.9.4-2_i386.deb guile-g-wrap_1.9.4-2_i386.deb to pool/main/g/g-wrap/guile-g-wrap_1.9.4-2_i386.deb libgwrap-runtime0-dev_1.9.4-2_i386.deb to pool/main/g/g-wrap/libgwrap-runtime0-dev_1.9.4-2_i386.deb libgwrap-runtime0_1.9.4-2_i386.deb to pool/main/g/g-wrap/libgwrap-runtime0_1.9.4-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted linux-kernel-di-arm 1.0 (arm source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 18:42:27 + Source: linux-kernel-di-arm Binary: fat-modules-2.4.27-netwinder-di scsi-common-modules-2.4.27-netwinder-di nic-shared-modules-2.4.27-netwinder-di kernel-image-2.4.27-netwinder-di scsi-core-modules-2.4.27-netwinder-di scsi-extra-modules-2.4.27-netwinder-di kernel-image-2.4.27-riscstation-di kernel-image-2.4.27-riscpc-di socket-modules-2.4.27-netwinder-di socket-modules-2.4.27-bast-di socket-modules-2.4.27-riscpc-di loop-modules-2.4.27-riscpc-di nic-modules-2.4.27-netwinder-di scsi-modules-2.4.27-netwinder-di cdrom-core-modules-2.4.27-netwinder-di md-modules-2.4.27-netwinder-di socket-modules-2.4.27-lart-di socket-modules-2.4.27-riscstation-di kernel-image-2.4.27-lart-di isa-pnp-modules-2.4.27-netwinder-di fat-modules-2.4.27-riscstation-di loop-modules-2.4.27-netwinder-di fat-modules-2.4.27-riscpc-di loop-modules-2.4.27-bast-di nic-extra-modules-2.4.27-netwinder-di usb-modules-2.4.27-netwinder-di cdrom-core-modules-2.4.27-bast-di kernel-image-2.4.27-bast-di Architecture: source arm Version: 1.0 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Martin Michlmayr [EMAIL PROTECTED] Description: cdrom-core-modules-2.4.27-bast-di - CDROM support (udeb) cdrom-core-modules-2.4.27-netwinder-di - CDROM support (udeb) fat-modules-2.4.27-netwinder-di - FAT filesystem support (udeb) fat-modules-2.4.27-riscpc-di - FAT filesystem support (udeb) fat-modules-2.4.27-riscstation-di - FAT filesystem support (udeb) isa-pnp-modules-2.4.27-netwinder-di - isa-pnp drivers (udeb) kernel-image-2.4.27-bast-di - Linux kernel binary image for the Debian installer (udeb) kernel-image-2.4.27-lart-di - Linux kernel binary image for the Debian installer (udeb) kernel-image-2.4.27-netwinder-di - Linux kernel binary image for the Debian installer (udeb) kernel-image-2.4.27-riscpc-di - Linux kernel binary image for the Debian installer (udeb) kernel-image-2.4.27-riscstation-di - Linux kernel binary image for the Debian installer (udeb) loop-modules-2.4.27-bast-di - Loopback filesystem support (udeb) loop-modules-2.4.27-netwinder-di - Loopback filesystem support (udeb) loop-modules-2.4.27-riscpc-di - Loopback filesystem support (udeb) md-modules-2.4.27-netwinder-di - RAID and LVM support (udeb) nic-extra-modules-2.4.27-netwinder-di - Rare NIC drivers (udeb) nic-modules-2.4.27-netwinder-di - Common NIC drivers (udeb) nic-shared-modules-2.4.27-netwinder-di - Shared NIC drivers (udeb) scsi-common-modules-2.4.27-netwinder-di - Very common SCSI drivers (udeb) scsi-core-modules-2.4.27-netwinder-di - Core SCSI subsystem (udeb) scsi-extra-modules-2.4.27-netwinder-di - Uncommon SCSI drivers (udeb) scsi-modules-2.4.27-netwinder-di - SCSI drivers (udeb) socket-modules-2.4.27-bast-di - Socket drivers (udeb) socket-modules-2.4.27-lart-di - Socket drivers (udeb) socket-modules-2.4.27-netwinder-di - Socket drivers (udeb) socket-modules-2.4.27-riscpc-di - Socket drivers (udeb) socket-modules-2.4.27-riscstation-di - Socket drivers (udeb) usb-modules-2.4.27-netwinder-di - USB support (udeb) Changes: linux-kernel-di-arm (1.0) unstable; urgency=low . * Martin Michlmayr - Rebuilt with kernel 2.4.27-2 (for various security fixes from kernel-source 2.4.27-8). - Gratuitous version number bump. Files: 0c48441d9cd526e57a5360ae79982001 1783 debian-installer optional linux-kernel-di-arm_1.0.dsc 296fa60584db387315ac43b02e422622 15012 debian-installer optional linux-kernel-di-arm_1.0.tar.gz 34022dd911d33750a44bf0c35995897d 1062114 debian-installer extra kernel-image-2.4.27-netwinder-di_1.0_arm.udeb 535c0c154a93eb56f342a40f83ae1b90 80660 debian-installer standard nic-modules-2.4.27-netwinder-di_1.0_arm.udeb 79d597eea989fce333db5a96d81d4bd4 196550 debian-installer standard nic-extra-modules-2.4.27-netwinder-di_1.0_arm.udeb 2d5366cb65f4a10b779dad8f784e00ab 11402 debian-installer standard nic-shared-modules-2.4.27-netwinder-di_1.0_arm.udeb 3da0f3a3948d9fd71881f92be08a67d9 23828 debian-installer standard isa-pnp-modules-2.4.27-netwinder-di_1.0_arm.udeb 32bc0cf6030280ca7849f41e0571df65 21358 debian-installer extra socket-modules-2.4.27-netwinder-di_1.0_arm.udeb 214424d654232538aa7f771373f8c26b 42890 debian-installer standard cdrom-core-modules-2.4.27-netwinder-di_1.0_arm.udeb 40056b53f53db5cffc5cef82e2f6883a 50722 debian-installer standard scsi-core-modules-2.4.27-netwinder-di_1.0_arm.udeb 6015202b974afce535334f723d42aa82 408204 debian-installer standard scsi-modules-2.4.27-netwinder-di_1.0_arm.udeb 355b7ff0ed749ffcd8914c3d7a02cf6f 91926 debian-installer standard scsi-common-modules-2.4.27-netwinder-di_1.0_arm.udeb f5187a734f171e748d4545e78a438b08 181996 debian-installer standard scsi-extra-modules-2.4.27-netwinder-di_1.0_arm.udeb e5d92fe925650051a0f4521124de3f19 8616 debian-installer standard
Accepted pnet 0.6.12-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Feb 2005 23:54:05 +1300 Source: pnet Binary: pnet-interpreter pnet-dev pnet pnet-compiler pnet-ctools Architecture: source i386 Version: 0.6.12-3 Distribution: unstable Urgency: low Maintainer: Andrew Mitchell [EMAIL PROTECTED] Changed-By: Andrew Mitchell [EMAIL PROTECTED] Description: pnet - DotGNU C# compiler, runtime, (dis)assembler pnet-compiler - DotGNU Portable.NET C# compiler tools pnet-ctools - Development tools for compiling C to IL bytecode pnet-dev - Development package for DotGNU Portable.NET pnet-interpreter - DotGNU C# compiler, runtime, (dis)assembler Closes: 293726 Changes: pnet (0.6.12-3) unstable; urgency=low . * Fix FTBFS with gcc 4.0 (Closes: #293726) * Change Build-Depends to use libreadline5-dev * Thanks to Andreas Jochens for patches. Files: 65a3cbfeb064bc9d9cba6b97a28b7c73 668 devel optional pnet_0.6.12-3.dsc 83436ad7ea48c794e6174daf4fcd6174 2086079 devel optional pnet_0.6.12-3.diff.gz 7c2739860ec170f6d5498c1337b0942c 81038 devel optional pnet_0.6.12-3_i386.deb 92077e88ad43813546bae02da59e9975 4328172 devel optional pnet-compiler_0.6.12-3_i386.deb 774b9b769dab9b6021d8a545aaac3893 490752 devel optional pnet-interpreter_0.6.12-3_i386.deb e388aa756e86893b2a606413d33ac2f8 138148 devel optional pnet-ctools_0.6.12-3_i386.deb 2216abfaf23812eca14935e25aeacb10 1045424 devel optional pnet-dev_0.6.12-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCG3sY3cp5nGFDTdYRAhwIAKCUrQXqL+GZ5OCPW/Q4Eapz86zPZQCbBhTu b80CkPXWxL3T2K+N7v1+Lwc= =gDbh -END PGP SIGNATURE- Accepted: pnet-compiler_0.6.12-3_i386.deb to pool/main/p/pnet/pnet-compiler_0.6.12-3_i386.deb pnet-ctools_0.6.12-3_i386.deb to pool/main/p/pnet/pnet-ctools_0.6.12-3_i386.deb pnet-dev_0.6.12-3_i386.deb to pool/main/p/pnet/pnet-dev_0.6.12-3_i386.deb pnet-interpreter_0.6.12-3_i386.deb to pool/main/p/pnet/pnet-interpreter_0.6.12-3_i386.deb pnet_0.6.12-3.diff.gz to pool/main/p/pnet/pnet_0.6.12-3.diff.gz pnet_0.6.12-3.dsc to pool/main/p/pnet/pnet_0.6.12-3.dsc pnet_0.6.12-3_i386.deb to pool/main/p/pnet/pnet_0.6.12-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted quik-installer 0.0.10 (powerpc source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 18:58:22 + Source: quik-installer Binary: quik-installer Architecture: source powerpc Version: 0.0.10 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Colin Watson [EMAIL PROTECTED] Description: quik-installer - Install quik on a hard disk (udeb) Changes: quik-installer (0.0.10) unstable; urgency=low . * Matt Kraai - Fix the spelling of file system. * Colin Watson - Issue scarier warning (non_powermac_warning renamed to non_oldworld_warning) on non-OldWorld systems. - Default quik-installer/oldworld_warning answer to true, since it's been explicitly requested and is appropriate for this type of machine (part of #295996). * Updated translations: - Catalan (ca.po) by Guillem Jover - Gallegan (gl.po) by Jacobo Tarrio - Hebrew (he.po) by Lior Kaplan - Italian (it.po) by Stefano Canepa - Ukrainian (uk.po) by Eugeniy Meshcheryakov Files: 874a3e2e5f05bbf38f20cbaa54debf55 610 debian-installer standard quik-installer_0.0.10.dsc 8d38d920b18a151a6ae330245fa0954f 62558 debian-installer standard quik-installer_0.0.10.tar.gz 364433ec53326d5a6256be35a2899e2b 52146 debian-installer standard quik-installer_0.0.10_powerpc.udeb package-type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCG4GT9t0zAhD6TNERAiXMAJ90GJX1CQb/QIYHSYVOdgs7rBieKwCcD9FW gOUiZYCyRuUs5DGEDeUNvuU= =ZHvW -END PGP SIGNATURE- Accepted: quik-installer_0.0.10.dsc to pool/main/q/quik-installer/quik-installer_0.0.10.dsc quik-installer_0.0.10.tar.gz to pool/main/q/quik-installer/quik-installer_0.0.10.tar.gz quik-installer_0.0.10_powerpc.udeb to pool/main/q/quik-installer/quik-installer_0.0.10_powerpc.udeb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted radvd 1:0.7.3-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 19:47:02 +0100 Source: radvd Binary: radvd Architecture: source i386 Version: 1:0.7.3-1 Distribution: unstable Urgency: low Maintainer: Andreas Rottmann [EMAIL PROTECTED] Changed-By: Andreas Rottmann [EMAIL PROTECTED] Description: radvd - Router Advertisement Daemon Changes: radvd (1:0.7.3-1) unstable; urgency=low . * New upstream release. * Upload to unstable. Files: bfa8a8bcb355b8df705fa653155bab4d 592 net optional radvd_0.7.3-1.dsc 56ce3f8cbf5966a0d531c21813320423 102615 net optional radvd_0.7.3.orig.tar.gz e56de67d3f4c3a8ee1252d5d0efc2092 37360 net optional radvd_0.7.3-1.diff.gz 3bd77524a7b4c2c5eded2674406a06c5 54748 net optional radvd_0.7.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCG4GR+S/PxQH9W2IRAsBqAKCD+4K4sOrQs4UxxxnLWRZfVdwm5QCeMNol ACAmvV3oADj8p/OZp9Zz/7U= =eBEf -END PGP SIGNATURE- Accepted: radvd_0.7.3-1.diff.gz to pool/main/r/radvd/radvd_0.7.3-1.diff.gz radvd_0.7.3-1.dsc to pool/main/r/radvd/radvd_0.7.3-1.dsc radvd_0.7.3-1_i386.deb to pool/main/r/radvd/radvd_0.7.3-1_i386.deb radvd_0.7.3.orig.tar.gz to pool/main/r/radvd/radvd_0.7.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libcgicc 3.2.3-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 15:11:52 + Source: libcgicc Binary: libcgicc1-dev libcgicc1 Architecture: source i386 Version: 3.2.3-1 Distribution: unstable Urgency: low Maintainer: Chris Butler [EMAIL PROTECTED] Changed-By: Chris Butler [EMAIL PROTECTED] Description: libcgicc1 - A C++ class library for writing CGI applications libcgicc1-dev - A C++ class library for writing CGI applications Closes: 260429 Changes: libcgicc (3.2.3-1) unstable; urgency=low . * New upstream version - form_urldecode now checks length of %-encoded strings (closes: #260429) * debian/control: Bumped Standards-Version to 3.6.1 Files: 0f5fd042c722846fb029718aababcf45 582 libs optional libcgicc_3.2.3-1.dsc 57f290cbaea871bc2ccb004d27b1257e 718154 libs optional libcgicc_3.2.3.orig.tar.gz 80b9c3423952b9a007287978d6e2626d 331390 libs optional libcgicc_3.2.3-1.diff.gz 186588869c09de82a1388e93e9dd3617 325046 libdevel optional libcgicc1-dev_3.2.3-1_i386.deb a1cff6fae65bd0dffd7df945ee740d5e 71352 libs optional libcgicc1_3.2.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCG3VNDzQFd9CXomERAioGAJ9vI2FDl2G0czojOtKTwja+jIoi6QCgsjSS 7KAIULKiBvg29oqi9tfhlrw= =FHc7 -END PGP SIGNATURE- Accepted: libcgicc1-dev_3.2.3-1_i386.deb to pool/main/libc/libcgicc/libcgicc1-dev_3.2.3-1_i386.deb libcgicc1_3.2.3-1_i386.deb to pool/main/libc/libcgicc/libcgicc1_3.2.3-1_i386.deb libcgicc_3.2.3-1.diff.gz to pool/main/libc/libcgicc/libcgicc_3.2.3-1.diff.gz libcgicc_3.2.3-1.dsc to pool/main/libc/libcgicc/libcgicc_3.2.3-1.dsc libcgicc_3.2.3.orig.tar.gz to pool/main/libc/libcgicc/libcgicc_3.2.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xchm 0.9.8-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 20:57:24 +0100 Source: xchm Binary: xchm Architecture: source i386 Version: 0.9.8-2 Distribution: unstable Urgency: low Maintainer: Julien LEMOINE [EMAIL PROTECTED] Changed-By: Julien Lemoine [EMAIL PROTECTED] Description: xchm - Compiled HTML Help (CHM) file viewer for X Closes: 241302 Changes: xchm (0.9.8-2) unstable; urgency=low . * Build xchm with wxwindows 2.5 (linked with gtk 2.0) (Closes: #241302) Files: baa3e91392884ddf6dbd5bfe94245e4a 644 x11 optional xchm_0.9.8-2.dsc c1e6898159cfde2fc093b24c60b64222 44353 x11 optional xchm_0.9.8-2.diff.gz 164d5b2b63939c6ebd6b82274a7df7e9 209710 x11 optional xchm_0.9.8-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCG4+5c29c8N2YKnURAtDCAJwM/bwCKaK/PdHBXv6I3NOXAoERQQCePQvc N14mWVyAoMdGZDH7La6Jhtc= =OnZU -END PGP SIGNATURE- Accepted: xchm_0.9.8-2.diff.gz to pool/main/x/xchm/xchm_0.9.8-2.diff.gz xchm_0.9.8-2.dsc to pool/main/x/xchm/xchm_0.9.8-2.dsc xchm_0.9.8-2_i386.deb to pool/main/x/xchm/xchm_0.9.8-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xchm 0.9.8-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 20:44:53 +0100 Source: xchm Binary: xchm Architecture: source i386 Version: 0.9.8-1 Distribution: unstable Urgency: low Maintainer: Julien LEMOINE [EMAIL PROTECTED] Changed-By: Julien Lemoine [EMAIL PROTECTED] Description: xchm - Compiled HTML Help (CHM) file viewer for X Changes: xchm (0.9.8-1) unstable; urgency=low . * New upstream release Files: 20ae3441455a81f2056981a3f3db9a22 651 x11 optional xchm_0.9.8-1.dsc a7ef5845a5a594bef8546846f2bdbaa7 325722 x11 optional xchm_0.9.8.orig.tar.gz ee3a9e095e5f322d503a33afea9a4a92 15129 x11 optional xchm_0.9.8-1.diff.gz 422b6d90580f73ee287f721459efdc5f 202582 x11 optional xchm_0.9.8-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCG4xUc29c8N2YKnURAjdrAKCpbChyjzp7454rG1UF/jGO0XTLeACdFEj8 kSTNWfGZkqn5KJxgNs3QjV8= =Xs74 -END PGP SIGNATURE- Accepted: xchm_0.9.8-1.diff.gz to pool/main/x/xchm/xchm_0.9.8-1.diff.gz xchm_0.9.8-1.dsc to pool/main/x/xchm/xchm_0.9.8-1.dsc xchm_0.9.8-1_i386.deb to pool/main/x/xchm/xchm_0.9.8-1_i386.deb xchm_0.9.8.orig.tar.gz to pool/main/x/xchm/xchm_0.9.8.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted horde2 2.2.7-7 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 21:29:57 +0100 Source: horde2 Binary: horde2 Architecture: source all Version: 2.2.7-7 Distribution: unstable Urgency: low Maintainer: Ola Lundqvist [EMAIL PROTECTED] Changed-By: Ola Lundqvist [EMAIL PROTECTED] Description: horde2 - The Horde Web Application Suite Closes: 296342 Changes: horde2 (2.2.7-7) unstable; urgency=low . * Added support for php5 in apache config, closes: #296342. Files: b4a96b53830e0624c8826f79df6275ed 563 web optional horde2_2.2.7-7.dsc b6b43ccc0189b1d5ae6b447d07421054 37812 web optional horde2_2.2.7-7.diff.gz 01ba96d33b85f3537874112cbf078c22 512926 web optional horde2_2.2.7-7_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCG5bVGKGxzw/lPdkRArKvAKCs2tC3xEd3ezbSm5ZEU0oQpgGDUACgonfU z4ft17r4FG01HVRdX3l0lEg= =I/s4 -END PGP SIGNATURE- Accepted: horde2_2.2.7-7.diff.gz to pool/main/h/horde2/horde2_2.2.7-7.diff.gz horde2_2.2.7-7.dsc to pool/main/h/horde2/horde2_2.2.7-7.dsc horde2_2.2.7-7_all.deb to pool/main/h/horde2/horde2_2.2.7-7_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted acl2 2.9.1-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 18:34:32 + Source: acl2 Binary: acl2-books-certs acl2-doc acl2 acl2-infix-source acl2-infix acl2-source acl2-books-source acl2-books acl2-emacs Architecture: source all i386 Version: 2.9.1-1 Distribution: unstable Urgency: high Maintainer: Camm Maguire [EMAIL PROTECTED] Changed-By: Camm Maguire [EMAIL PROTECTED] Description: acl2 - A Computational Logic for Applicative Common Lisp: main binary acl2-books - A Computational Logic for Applicative Common Lisp: compiled libra acl2-books-certs - A Computational Logic for Applicative Common Lisp: library certif acl2-books-source - A Computational Logic for Applicative Common Lisp: library source acl2-doc - A Computational Logic for Applicative Common Lisp: documentation acl2-emacs - A Computational Logic for Applicative Common Lisp: emacs interfac acl2-infix - A Computational Logic for Applicative Common Lisp: infix interfac acl2-infix-source - A Computational Logic for Applicative Common Lisp: infix source acl2-source - A Computational Logic for Applicative Common Lisp: source files Closes: 284780 Changes: acl2 (2.9.1-1) unstable; urgency=high . * New upstream release * Bug fix: acl2: :system dir is wrong, thanks to Patrick Calhoun (Closes: #284780). Apologies, had inadvertently reverted previous fix. Now include a GNUmakefile patch setting ACL2_BOOKS_DIR. Files: 886e81c9e6ee339b6309c9f1ff3a48f9 800 math optional acl2_2.9.1-1.dsc 27e65ac3afdd869c4f813f75d4f2324c 5244150 math optional acl2_2.9.1.orig.tar.gz d29b4e039ef3ad6e033a3491ed07a42d 18985 math optional acl2_2.9.1-1.diff.gz 081c8ab0617ae963bc0bbbaac6c6d3ee 2059494 math optional acl2-source_2.9.1-1_all.deb 237b60dceca1812f434a03b525e82e48 48990 math optional acl2-emacs_2.9.1-1_all.deb f1ab579352606a498462f66bca72ca24 84460 math optional acl2-infix-source_2.9.1-1_all.deb 9a4e9d8fdba4874d10e453b8361ca06a 1255418 math optional acl2-books-source_2.9.1-1_all.deb bec99753843b475d6c76f839cec337bb 308256 math optional acl2-books-certs_2.9.1-1_all.deb 0fe9a84b53328ad968ae351a7676fb2e 1800072 doc optional acl2-doc_2.9.1-1_all.deb b67bd4edb7cf2948bc790ac9073f698c 13905244 math optional acl2_2.9.1-1_i386.deb e15b97e07c053c8e09428cb9946b4b71 181316 math optional acl2-infix_2.9.1-1_i386.deb caf49eea13c3071becadbdf9820c639c 857122 math optional acl2-books_2.9.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCG5J0czG1wFfwRdwRAqHrAKCj5jhvElWmCrIJVEvW3O5hPATd4ACfcORK VjOj4Y8Bd7riELwwtvs5kLE= =bA1p -END PGP SIGNATURE- Accepted: acl2-books-certs_2.9.1-1_all.deb to pool/main/a/acl2/acl2-books-certs_2.9.1-1_all.deb acl2-books-source_2.9.1-1_all.deb to pool/main/a/acl2/acl2-books-source_2.9.1-1_all.deb acl2-books_2.9.1-1_i386.deb to pool/main/a/acl2/acl2-books_2.9.1-1_i386.deb acl2-doc_2.9.1-1_all.deb to pool/main/a/acl2/acl2-doc_2.9.1-1_all.deb acl2-emacs_2.9.1-1_all.deb to pool/main/a/acl2/acl2-emacs_2.9.1-1_all.deb acl2-infix-source_2.9.1-1_all.deb to pool/main/a/acl2/acl2-infix-source_2.9.1-1_all.deb acl2-infix_2.9.1-1_i386.deb to pool/main/a/acl2/acl2-infix_2.9.1-1_i386.deb acl2-source_2.9.1-1_all.deb to pool/main/a/acl2/acl2-source_2.9.1-1_all.deb acl2_2.9.1-1.diff.gz to pool/main/a/acl2/acl2_2.9.1-1.diff.gz acl2_2.9.1-1.dsc to pool/main/a/acl2/acl2_2.9.1-1.dsc acl2_2.9.1-1_i386.deb to pool/main/a/acl2/acl2_2.9.1-1_i386.deb acl2_2.9.1.orig.tar.gz to pool/main/a/acl2/acl2_2.9.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mailreader 2.3.29-10 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 19:34:25 +0100 Source: mailreader Binary: mailreader Architecture: source all Version: 2.3.29-10 Distribution: unstable Urgency: low Maintainer: Maurizio Lemmo (Tannoiser) [EMAIL PROTECTED] Changed-By: Maurizio Lemmo (Tannoiser) [EMAIL PROTECTED] Description: mailreader - Simple, but powerful WWW mail reader system Closes: 275011 296141 Changes: mailreader (2.3.29-10) unstable; urgency=low . * debian/po/de.po: update German translation by debconf template provider from Jens Nachtigall [EMAIL PROTECTED] (closes: #275011) * debian/po/cs.po: update Czech translation by debconf template provider from Lukas Oliva [EMAIL PROTECTED] (closes: #296141) * debian/rules: switch to dh_installman, because dh_installmanpages is deprecated. Files: 9d6aa68ce78aeb9b79b1b8b73f114514 631 web optional mailreader_2.3.29-10.dsc 95c440e8591f2ec9781036e15984bab9 46608 web optional mailreader_2.3.29-10.diff.gz 2a9c79f2cb1658ef7f1207b48169d221 355302 web optional mailreader_2.3.29-10_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCG5iB9LSwzHl+v6sRAu4xAJsEXYLfpnm4olIsZua5Hh7NVjKcLACffL35 dBvzw6mGcG/TtnLMXgP2xD0= =iSei -END PGP SIGNATURE- Accepted: mailreader_2.3.29-10.diff.gz to pool/main/m/mailreader/mailreader_2.3.29-10.diff.gz mailreader_2.3.29-10.dsc to pool/main/m/mailreader/mailreader_2.3.29-10.dsc mailreader_2.3.29-10_all.deb to pool/main/m/mailreader/mailreader_2.3.29-10_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted wzdftpd 0.5.0-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 15 Feb 2005 13:17:44 +0100 Source: wzdftpd Binary: wzdftpd-mod-perl wzdftpd-back-mysql wzdftpd-dev wzdftpd wzdftpd-mod-tcl Architecture: source i386 Version: 0.5.0-1 Distribution: unstable Urgency: low Maintainer: Pierre Chifflier [EMAIL PROTECTED] Changed-By: Pierre Chifflier [EMAIL PROTECTED] Description: wzdftpd- A portable, modular, not user-friendly ftp server wzdftpd-back-mysql - MySQL backend for wzdftpd wzdftpd-dev - Development files for wzdftpd wzdftpd-mod-perl - Perl module for wzdftpd wzdftpd-mod-tcl - TCL module for wzdftpd Changes: wzdftpd (0.5.0-1) unstable; urgency=low . * New upstream version Files: abf6ffb2b62f3bd065edc1ee70aa494a 753 net optional wzdftpd_0.5.0-1.dsc b8da91483230490cb7148e9be286e35e 806802 net optional wzdftpd_0.5.0.orig.tar.gz 663ba5c6305ce6211c64d9e94d8e6e99 6194 net optional wzdftpd_0.5.0-1.diff.gz 90af0a2a42087fa40fb76f6c41fcb643 272440 net optional wzdftpd_0.5.0-1_i386.deb dafc1f8f8490b87bcd41d444cd889c08 27818 net optional wzdftpd-back-mysql_0.5.0-1_i386.deb a3f1ab4729c7d712da86030cb73a0987 28352 net optional wzdftpd-mod-tcl_0.5.0-1_i386.deb 235a895a2d0e985ffd0e843a26d9df4a 43468 net optional wzdftpd-mod-perl_0.5.0-1_i386.deb 535dc9d188244b041a09de658a70a660 197666 libdevel optional wzdftpd-dev_0.5.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCG3wQw3ao2vG823MRAhUFAJ0YcLDJs/NCNWR8/6XCpIlo1cR7KACgiTW4 KimTS/z/3G0gFlNRrGspJu8= =1d5x -END PGP SIGNATURE- Accepted: wzdftpd-back-mysql_0.5.0-1_i386.deb to pool/main/w/wzdftpd/wzdftpd-back-mysql_0.5.0-1_i386.deb wzdftpd-dev_0.5.0-1_i386.deb to pool/main/w/wzdftpd/wzdftpd-dev_0.5.0-1_i386.deb wzdftpd-mod-perl_0.5.0-1_i386.deb to pool/main/w/wzdftpd/wzdftpd-mod-perl_0.5.0-1_i386.deb wzdftpd-mod-tcl_0.5.0-1_i386.deb to pool/main/w/wzdftpd/wzdftpd-mod-tcl_0.5.0-1_i386.deb wzdftpd_0.5.0-1.diff.gz to pool/main/w/wzdftpd/wzdftpd_0.5.0-1.diff.gz wzdftpd_0.5.0-1.dsc to pool/main/w/wzdftpd/wzdftpd_0.5.0-1.dsc wzdftpd_0.5.0-1_i386.deb to pool/main/w/wzdftpd/wzdftpd_0.5.0-1_i386.deb wzdftpd_0.5.0.orig.tar.gz to pool/main/w/wzdftpd/wzdftpd_0.5.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xmail 1.21-2 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 10 Feb 2005 22:20:55 +0200 Source: xmail Binary: xmail xmail-doc Architecture: source i386 all Version: 1.21-2 Distribution: unstable Urgency: low Maintainer: Radu Spineanu [EMAIL PROTECTED] Changed-By: Radu Spineanu [EMAIL PROTECTED] Description: xmail - advanced, fast and reliable ESMTP/POP3 mail server xmail-doc - documentation for xmail Closes: 293380 Changes: xmail (1.21-2) unstable; urgency=low . * Added patch for xmail to detect symlinks and treat them accordingly (closes: #293380) * Fixed a problem in postinst when upgrading from some old versions Files: 10180aa24d2cb642a5776bb6cc06e603 645 mail extra xmail_1.21-2.dsc fb20cb6875fd7e0b4509f6cc536eac80 27038 mail extra xmail_1.21-2.diff.gz 25abf9f246bf113181c63264b2000775 164446 mail extra xmail-doc_1.21-2_all.deb 3725d6d90789cfa38ad74d6e43cc5e73 215362 mail extra xmail_1.21-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCG5B2pFNRmenyx0cRAgMiAJ9OCTeA+4Obj2KFGzZe6n6gRX/O5ACg5lmR Hlep8ArKQYG0rLW8Lzxk2Rw= =ajNx -END PGP SIGNATURE- Accepted: xmail-doc_1.21-2_all.deb to pool/main/x/xmail/xmail-doc_1.21-2_all.deb xmail_1.21-2.diff.gz to pool/main/x/xmail/xmail_1.21-2.diff.gz xmail_1.21-2.dsc to pool/main/x/xmail/xmail_1.21-2.dsc xmail_1.21-2_i386.deb to pool/main/x/xmail/xmail_1.21-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted snort 2.3.0-5 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 21:36:40 +0100 Source: snort Binary: snort-mysql snort-doc snort-rules-default snort-common snort-pgsql snort Architecture: source i386 all Version: 2.3.0-5 Distribution: unstable Urgency: low Maintainer: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] Changed-By: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] Description: snort - Flexible Network Intrusion Detection System snort-common - Flexible Network Intrusion Detection System [common files] snort-doc - Documentation for the Snort IDS [documentation] snort-mysql - Flexible Network Intrusion Detection System [MySQL] snort-pgsql - Flexible Network Intrusion Detection System [PostgreSQL] snort-rules-default - Flexible Network Intrusion Detection System ruleset Closes: 193299 247603 Changes: snort (2.3.0-5) unstable; urgency=low . * Upload of the experimental package to unstable Even though I don't get to fix #205683 and friends (and I would like to, before the release) This release Closes #283816, #241995, #289405, #247603 * Do not rotate log files if empty (Closes: #193299) * Added dutch translation (Closes: #247603) * Added yet another TODO item Files: da76600df1e6bcd6a9b3bb89f945ab9f 971 net optional snort_2.3.0-5.dsc 5263121b751a7f5e13aab9b685017b1f 229965 net optional snort_2.3.0-5.diff.gz 66b232550b9c161f039e5781f3c64b99 88614 net optional snort-common_2.3.0-5_all.deb 2045f6df4d7d3e1cf6e808b0d0d78991 1100290 doc optional snort-doc_2.3.0-5_all.deb 51768548dc170bb04fcac8810cf8d8b2 216652 net optional snort-rules-default_2.3.0-5_all.deb d81dbee219dfdd0aa09656016aafd1aa 393390 net optional snort_2.3.0-5_i386.deb ba183c8e2686b92300da04362145116a 397076 net extra snort-mysql_2.3.0-5_i386.deb 1372a3c3d86388939c9aa9b73f6381fb 397020 net optional snort-pgsql_2.3.0-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iQCVAwUBQhuci/tEPvakNq0lAQKPAgQAsHqJQ20SapTXj0J1HUwtWILndEDT3kGK tIgq3rQoT/GqElY+WYrt9HmzqLaqhWQJHsu9HgPqMuI2bXtsR6lPtmAjkDHNB3pb ZBUD/AqK36v+rQKypdFkIK4hcgWF4F187ChTd/fk+/gl0rcr3t2+1n9n0xeuVlee bPStRLEnUhY= =EyRF -END PGP SIGNATURE- Accepted: snort-common_2.3.0-5_all.deb to pool/main/s/snort/snort-common_2.3.0-5_all.deb snort-doc_2.3.0-5_all.deb to pool/main/s/snort/snort-doc_2.3.0-5_all.deb snort-mysql_2.3.0-5_i386.deb to pool/main/s/snort/snort-mysql_2.3.0-5_i386.deb snort-pgsql_2.3.0-5_i386.deb to pool/main/s/snort/snort-pgsql_2.3.0-5_i386.deb snort-rules-default_2.3.0-5_all.deb to pool/main/s/snort/snort-rules-default_2.3.0-5_all.deb snort_2.3.0-5.diff.gz to pool/main/s/snort/snort_2.3.0-5.diff.gz snort_2.3.0-5.dsc to pool/main/s/snort/snort_2.3.0-5.dsc snort_2.3.0-5_i386.deb to pool/main/s/snort/snort_2.3.0-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted clips-doc 6.23-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 22:06:01 +0100 Source: clips-doc Binary: clips-doc Architecture: source all Version: 6.23-1 Distribution: unstable Urgency: low Maintainer: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] Changed-By: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] Description: clips-doc - C Language Integrated Production System Documentation Closes: 286711 Changes: clips-doc (6.23-1) unstable; urgency=low . * Updated to latest documentation (Closes: #286711) bpg.pdf - CLIPS 6.23 Basic Programming Guide apg.pdf - CLIPS 6.23 Advanced Programming Guide ig.pdf - CLIPS 6.23 Interfaces Guide usrguide.pdf - CLIPS 6.20 User's Guide * Included new documentation: arch5-1.pdf - CLIPS 5.1 Architecture Manual * Bump to a version equivalent to the included documentation. * Adjusted debian/rules as this is a binary: all package Files: 0c8d1958fe9b7bd83205c5518b7ff682 697 doc optional clips-doc_6.23-1.dsc 89a7a001794d08d63d467b63a20db04b 5913919 doc optional clips-doc_6.23.orig.tar.gz 2629cd2b5a509e5d072f154e62858bb6 2080 doc optional clips-doc_6.23-1.diff.gz 3302f8a11f70cc42e806bc6125b9e00b 5914896 doc optional clips-doc_6.23-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iQCVAwUBQhuhhftEPvakNq0lAQJyUwQAsvGbnsyu1qf6Yz6TxzxnkIBU+l/xBgEI v1c5f+VmSaFlbW79PY2Be2CUdx2lnpIgQFj5tTGeOd3+aIiMFredh5UlH0M3nkYm iUArWAoZhgQu+eDIN+ARqRX3oMwNzZaOBIXXGCUO5mhQPFFq5DHnN+ZExjaVapVj Po+ZbW5hARE= =Hg+b -END PGP SIGNATURE- Accepted: clips-doc_6.23-1.diff.gz to pool/main/c/clips-doc/clips-doc_6.23-1.diff.gz clips-doc_6.23-1.dsc to pool/main/c/clips-doc/clips-doc_6.23-1.dsc clips-doc_6.23-1_all.deb to pool/main/c/clips-doc/clips-doc_6.23-1_all.deb clips-doc_6.23.orig.tar.gz to pool/main/c/clips-doc/clips-doc_6.23.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tabextensions 1.13.2005022101-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 22:11:18 +0100 Source: tabextensions Binary: mozilla-tabextensions Architecture: source all Version: 1.13.2005022101-1 Distribution: unstable Urgency: low Maintainer: Mike Hommey [EMAIL PROTECTED] Changed-By: Mike Hommey [EMAIL PROTECTED] Description: mozilla-tabextensions - Tabbed browsing extensions for Mozilla Changes: tabextensions (1.13.2005022101-1) unstable; urgency=low . * New upstream release. * chrome/locale/de-AT: Updated german localization. Files: 4338ae421fab34fb376811873894 649 web optional tabextensions_1.13.2005022101-1.dsc 5de3f9742752bdc7364d9cf39d490a8f 259178 web optional tabextensions_1.13.2005022101.orig.tar.gz c8d787bf5a3c4dd46cf883d2833e2385 72029 web optional tabextensions_1.13.2005022101-1.diff.gz 05b41a14fe27178fec79edcabc6b422b 407184 web optional mozilla-tabextensions_1.13.2005022101-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCG6Bx3kvaLFT9KlgRAmjvAKCOydS9R3Yzs72NK2Gk5TLxiN+D4QCfZyGf ik0dyxcd0NF1UxPViTGMQ7M= =Se+F -END PGP SIGNATURE- Accepted: mozilla-tabextensions_1.13.2005022101-1_all.deb to pool/main/t/tabextensions/mozilla-tabextensions_1.13.2005022101-1_all.deb tabextensions_1.13.2005022101-1.diff.gz to pool/main/t/tabextensions/tabextensions_1.13.2005022101-1.diff.gz tabextensions_1.13.2005022101-1.dsc to pool/main/t/tabextensions/tabextensions_1.13.2005022101-1.dsc tabextensions_1.13.2005022101.orig.tar.gz to pool/main/t/tabextensions/tabextensions_1.13.2005022101.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sgb 1:20030623-3 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 22 Feb 2005 21:42:10 + Source: sgb Binary: sgb-doc sgb sgb-src Architecture: source i386 all Version: 1:20030623-3 Distribution: unstable Urgency: low Maintainer: Julian Gilbey [EMAIL PROTECTED] Changed-By: Julian Gilbey [EMAIL PROTECTED] Description: sgb- The Stanford GraphBase: combinatorial data and algorithms sgb-doc- Documentation for the Stanford GraphBase sgb-src- Transitional package - can be removed Closes: 283980 Changes: sgb (1:20030623-3) unstable; urgency=low . * Correct manpage (/usr/doc - /usr/share/doc) (closes: #283980) Files: e989a9217b5eb1f32c992dc1ff9dde3a 626 non-free/math extra sgb_20030623-3.dsc 123a7af2ccbd7d8ca73e99dcfdb10001 21710 non-free/math extra sgb_20030623-3.diff.gz a107052f58481f0c221d87960ab140a2 291912 non-free/doc extra sgb-doc_20030623-3_all.deb 606dd878b559f7b505ae4c6a428b8f04 668 non-free/math extra sgb-src_20030623-3_all.deb d4f63a4e8c8452d259885802366aaabf 371526 non-free/math extra sgb_20030623-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCG6fADU59w/205FkRArqeAJ9K2q5eLuLwOPSg2Tk2SBVFSlzBggCaA5/8 Bb9Jwg+Yw0QvWJFFMzcBDFQ= =A+Kn -END PGP SIGNATURE- Accepted: sgb-doc_20030623-3_all.deb to pool/non-free/s/sgb/sgb-doc_20030623-3_all.deb sgb-src_20030623-3_all.deb to pool/non-free/s/sgb/sgb-src_20030623-3_all.deb sgb_20030623-3.diff.gz to pool/non-free/s/sgb/sgb_20030623-3.diff.gz sgb_20030623-3.dsc to pool/non-free/s/sgb/sgb_20030623-3.dsc sgb_20030623-3_i386.deb to pool/non-free/s/sgb/sgb_20030623-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
