Re: Marking BTS spam
Hallo! Du (Blars Blarson) hast geschrieben: The lists.debian.org spam button doesn't have much immediate effect. correct, but we are working on it. Cord -- http://lists.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On binary compatibility
On Thu, 23 Feb 2006, Michael Gilbert wrote: First of all, I think it is useful to analyze Ubuntu's motivation -- releasing well-integrated bleeding-edge software. The easiest way to accomplish this goal is by branching from sid. This means that Ubuntu libraries differ from the stable Debian release. Hence, Debian stable (and sid/testing) packages are incompatible with the Ubuntu libraries; Most packages from sid and Ubuntu are compatible. thus creating the need for duplicate packaging work by both the Ubuntu and Debian communities. And in several cases, the work done by Ubuntu is reused by Debian and vice-versa. There's some duplicate work done but the idea is to reduce it and not to augment it (see reasoning below). The solution would be to convince Ubuntu to branch from stable instead of sid. The problem is that this creates a lot of work for Ubuntu Understand that Ubuntu is doing work on packages based on our sid packages. This means that the changes they do can (sometimes) be applied back to our sid packages where we *do* our work. In this way Ubuntu helps Debian. Their work would be almost useless if they did it on our stable version, since stable doesn't evolve in Debian. undertaking. Maybe a solution would be to force the sid GNOME release (and hence the upstream GNOME) to use the Debian stable GTK. This can't work. While we can discuss with upstream, we can't force anything. And any upstream has tons of good reasons to use newer libs... that's how we improve free software ! Obviously this would have some major political issues. How can we Indeed. backport support for newer hardware, which may involve backporting newer kernels or backporting support for newer hardware into the stable kernel. Which also means updating lots of utilities (udev, anyone?) and in fact your stable wouldn't be stable any more ... One final open-ended question is: which consumes more resources? Duplicate packaging or backporting? Backporting is a packaging work ... a special kind of it but backporting is not always straightforward and can't always be done without upgrading other softwares. So the answer is it depends. In the end, I doubt that your proposal could work. You said in turn it means more work for Ubuntu, it means more work for Debian and it requires to force upstream to use older libs. That's simply not possible. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On binary compatibility
Michael Gilbert wrote: I've read a lot about the binary incompatibility concern between Debian and Ubuntu. It is a design decision of ubuntu to ensure source code compatibility only. Binary compatibility to debian/stable is not a release goal. I think that Ubuntu's motivation to provide the latest software is reasonable; however, I think that Debian may be able to help to support that goal while making it possible to maintain binary compatibility. If you want to ensure binary compatibilty across distributions, I think a reasonable approach would be to work on lsb conformity on both distributions. The solution would be to convince Ubuntu to branch from stable instead of sid. It also means making backports.org an official Debian archive. This would be great, but, if backports.org get official, how do you cope with security updates withouth increasing the load of the security team seriously? The only way that this would work is if there are Debian folks willing to spend the time to work on backports of their packages. Many developers rather spend time developing debian/unstable. Developing on stable releases is not that much fun. And there would need to be coordination with Ubuntu to determine which packages require backporting, and which can be kept as is. Please note that debian and Ubuntu have completely different release cycles, different release goals and different workflows. Short: This wont work. Well, anyway, these are my thoughts. While I understand your motivation, your proposal is not feasible. If you want to ensure binary compatibility, better work on lsb support. Greetings, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
lists.d.o Spam (was: Marking BTS spam)
Hallo! Du (Nico Golde) hast geschrieben: At the moment the spam-report.pl script uses: input type=hidden name=listname value=debian-devel / input type=hidden name=msg value=msg00065.html / input type=hidden name=date value=2005/09 / To identify the message, this wouldn't work with a MUA so the idea came to my mind was to identify the Mail with the message-ID. Paskal Hakim asked what happens if someone fakes the message-ID in the old thread about this topic. Well this could happen, so someone has another idea? i took the logfile from the reporting script and checked some 'nominated' Files. As it turns out the top scorer for this year is: http://lists.debian.org/debian-project/2006/01/msg00035.html on all logged data two non-spam postings on d-spanish-users were also top20 nominated. So it looks like a not so good idea to automatically use that data, it can be used as fingerpoint where to look but not more. We have two uses for that reporting. 1. Removing identified spam from the Archive. 2. Enhancing the filters. on 2: we would need a whole spam-mail including all headers so we can find charakteristika to filter on, so i now take all nominated postings, and try to find patterns with some black shell-magic. The idea of having a reporting address is good, i'll will announce one in the next days and then lets see what happens. However: there will be some really black .procmail-magic that pulls out everything that doesn't look appropriate (multi nomination of a posting, uncomplete headers and stuff). More info when it is in place. Cord -- http://lists.debian.org signature.asc Description: Digital signature
Packaing Xen 3.0 etc for Debian
Ralph, I am a Debian Maintainer who is seriously considering getting Xen into Debian and Ubuntu. I have been installing xen-unstable.hg from source on my AMD 64 and have been impressed with its relative stability. I am prepared to sponsor your packages into Debian if we can get them cleaned up. Other things I am looking at are special Xen source trees. We would need the Debian security team to give us access to a patch repository for all the Linux security patches. The trick is to get the security fixes split out from all the other updates that come in the point releases for the current vanila kernel.org tree. Patching Xen against the standard Debian kernel tree may be asking for problems, so it is better to work off a vanilla kernel.org tarball and xen-unstable.hg What are your thoughts? Regards, Matthew Grant -- Matthew Grant [EMAIL PROTECTED] Matthew's UNIX Box signature.asc Description: This is a digitally signed message part
Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 11:02:57PM +1300, Matthew Grant wrote: I am a Debian Maintainer who is seriously considering getting Xen into Debian and Ubuntu. I have been installing xen-unstable.hg from source on my AMD 64 and have been impressed with its relative stability. I am prepared to sponsor your packages into Debian if we can get them cleaned up. Other things I am looking at are special Xen source trees. We would need the Debian security team to give us access to a patch repository for all the Linux security patches. What does this mean, exactly? The Debian security team doesn't maintain any such patch repository, so I think any strategy that depends on them implementing this for you is doomed to failure. The trick is to get the security fixes split out from all the other updates that come in the point releases for the current vanila kernel.org tree. Patching Xen against the standard Debian kernel tree may be asking for problems, so it is better to work off a vanilla kernel.org tarball and xen-unstable.hg Patching Xen against something *other* than the standard Debian kernel tree is asking for problems, because it means builds of an additional source package for every security update, plus no guarantee that a given security patch will apply cleanly to both trees, even *without* taking the Xen patch itself into consideration. Bastian Blank, a member of the Debian kernel team, is looking at integrating XenoLinux builds into the official linux-2.6 package. I think that's a much better option, and would strongly encourage anyone interested in Xen packaging to coordinate with the kernel team on this. (Yes, I'm aware there's a pkg-xen maintenance team on alioth as well; but AFAICT the maintainer of the current xen package is not a member of that packaging group, and there's no mention of xen on the wnpp bug page -- what's up with that?) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Packaing Xen 3.0 etc for Debian
* Matthew Grant wrote: We would need the Debian security team to give us access to a patch repository for all the Linux security patches. Those patches are in the kernel svn repository. http://svn.debian.org/wsvn/kernel/dists/sarge-security/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/ Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems found by piuparts
Don Armstrong [EMAIL PROTECTED] writes: On Thu, 23 Feb 2006, Frank Küster wrote: Don Armstrong [EMAIL PROTECTED] wrote: On Wed, 22 Feb 2006, Frank Küster wrote: Adeodato Simó [EMAIL PROTECTED] wrote: Correct, so one would put in foo.postrm: rmdir --ignore-fail-on-non-empty /usr/local/lib/foo That's not sufficient, because /usr/local may be mounted ro, and therefore the command may fail even if the directory is empty. rmdir --ignore-fail-on-non-empty /usr/local/lib/foo || true So you're suggesting that it's better to fail silently instead of failing loudly? Yes, please read Policy 9.1.2. Hrm, right... it just seems totally wrong to me for the package to create the directories and then not fail if removing them fails, since presumably the removal could fail for reasons unrelated to /usr/local being r/o. [Perhaps the ideal solution to resolve both of these issues is to have the script complain bitterly if it can't remove the directories and they exist, but not fail.] Don Armstrong I think the same applies to creating the dir. It should try but not fail if creating it fails. As for complaining bitterly: That is either anyoing because it is interactive or gets lost in all the output because it isn't. Damned if you do, damned if you don't. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 11:02:57PM +1300, Matthew Grant wrote: I am a Debian Maintainer who is seriously considering getting Xen into Debian and Ubuntu. The debian kernel team will maintain xen images with the linux-2.6 source. I currently prepare both xen 3.0 and unstable packages, which can be hopefully uploaded today. Maintainer will be the kernel team, as there are heavy dependencies between xen and the kernel. I am prepared to sponsor your packages into Debian if we can get them cleaned up. Please don't. Bastian -- Sometimes a man will tell his bartender things he'll never tell his doctor. -- Dr. Phillip Boyce, The Menagerie (The Cage), stardate unknown. signature.asc Description: Digital signature
Re: Packaing Xen 3.0 etc for Debian
Am Freitag, 24. Februar 2006 11:02 schrieb Matthew Grant: Ralph, Hi Matthew, I am a Debian Maintainer who is seriously considering getting Xen into Debian and Ubuntu. I have been installing xen-unstable.hg from source on my AMD 64 and have been impressed with its relative stability. I am prepared to sponsor your packages into Debian if we can get them cleaned up. There is already a project on alioth, called pkg-xen, which exactly tries to do this. We started with my package and have it (more or less) debian-policy compatible now, but some minor things are still to do (afaik). We are already three debian developers/maintainers + two external guys (I am one of them) and have made some real process. If you like you can join this project and help us getting xen3 into debian. Other things I am looking at are special Xen source trees. We would need the Debian security team to give us access to a patch repository for all the Linux security patches. The trick is to get the security fixes split out from all the other updates that come in the point releases for the current vanila kernel.org tree. Patching Xen against the standard Debian kernel tree may be asking for problems, so it is better to work off a vanilla kernel.org tarball and xen-unstable.hg this is for example also a topic already discussed on the pkg-xen-devel list. We will supply a patch for a vanilla 2.6.12 (at first) and might also provide binary kernel-images in future (most likely if xen gets merged in the main linux tree). If the xen project releases the next stable version with 2.6.16 we will switch to this version too. What are your thoughts? My thoughts? Join the alioth-project and help us if you want. We are open to new people that wants to help, so you are very welcome. Regards, Matthew Grant regards, Ralph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lists.d.o Spam (was: Marking BTS spam)
Hallo! Du (Cord Beermann) hast geschrieben: The idea of having a reporting address is good, i'll will announce one in the next days and then lets see what happens. ok, here it is: (alpha release, lets see what happens and if it is useful.) If you get spam via our lists, BOUNCE[1] it to [EMAIL PROTECTED] * Incomplete mails[2] will be discarded, * mis-use (report of non-spam, mass-reporting of one spam, automatic forwarding based on some automatism (scores of Anti-Spamtools or something)) will be blacklisted. The reported mails will be used to enhance our Spamassassin and procmail-filters. The mails will be stored non-public. [1] Bounce as in mutt b. I don't know if and how this can be done in thunderbird, or M$ LookOut. If it possible someone may explain it in a follow up. Forwarding is NOT ok at this time, those mails will be discarded. [2] I want complete mails. this means: ALL Headers and the body. If your system adds its own headers, or overwrites our Spamassassin-Headers it's ok, Cord -- http://lists.debian.org signature.asc Description: Digital signature
Re: lists.d.o Spam (was: Marking BTS spam)
Hi, * Cord Beermann [EMAIL PROTECTED] [2006-02-24 14:31]: Hallo! Du (Cord Beermann) hast geschrieben: The idea of having a reporting address is good, i'll will announce one in the next days and then lets see what happens. ok, here it is: (alpha release, lets see what happens and if it is useful.) If you get spam via our lists, BOUNCE[1] it to [EMAIL PROTECTED] Nice, thanks! Regards Nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org Forget about that mouse with 3/4/5 buttons - gimme a keyboard with 103/104/105 keys! pgpu5kyM293NZ.pgp Description: PGP signature
./configure in debian/rules
Dear developers, In a number of packages (e.g., busybox, dash and many more) the debian/rules Makefile calls ./configure without --host argument. This makes the life quite difficult for cross-compilation - for every such package I need to add --host=$(DEB_HOST_GNU_TYPE) to every configure invocation in debian/rules. Is there a workaround that avoids touching debian/rules? What is the preferred way to solve this problem with dpkg-buildpackage? TIA, Pjotr Kourzanov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
Bastian Blank wrote: Hi! The debian kernel team will maintain xen images with the linux-2.6 source. I currently prepare both xen 3.0 and unstable packages, which can be hopefully uploaded today. Maintainer will be the kernel team, as there are heavy dependencies between xen and the kernel. This is great! In the meantime we are working on uploading xen 3.0 to unstable, and our packages I think are almost ready too! We planned to contact the kernel team after the upload to see how to coordinate, but it's nice to know that the kernel part is being taken care of! :) Our packages don't contain any kernel (we wouldn't have uploaded them without asking the kernel team, of course) but we plan on shipping just the xen patch for a kernel.org kernel, just in case someone preffers running a non-debian kernel: is that OK, or should we remove that from our sources? Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 04:22:23PM +0100, Guido Trotter wrote: This is great! In the meantime we are working on uploading xen 3.0 to unstable, and our packages I think are almost ready too! This is insufficient. Either maintain both 3.0 and unstable or none. In the meantime, the kernel team will maintain both. Bastian -- Extreme feminine beauty is always disturbing. -- Spock, The Cloud Minders, stardate 5818.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
debian zeroconf group?
[Ccing maintainers of mdns stuff, please followup to debian-devel] With avahi in unstable we seem to have a fairly capable set of zeroconf/mdns tools in Debian now, albeit with some holes. There are for example some things like mod_dnssd that are not packaged yet and some interesting patches that aren't applied to some apps. And adding mdns to /etc/nsswitch.conf is still being worked out. I would like to investigate the possibility of adding a task to tasksel that fully sets up a system to prticipate in a zeroconf network. That would mean, you pick this task and you can resolve mdns names; if you installed a desktop, the desktop supports mdns; if you installed a web server or ssh server those services are published via mdns etc. There is still some integration work to do before that's possible, but it's my goal. I think a team to work on this stuff would be useful. Right now there seems to be no coordinated effort to put everything together and fill in the holes, just various people working on their own peices. While that scattershot approach has worked ok so far, getting everyone together integrating stuff could improve things a lot. If people agree let me know and I can do the standard alioth dance. -- see shy jo, who is primarily interested in zeroconf for his home network, and as a way to improve the ad-hoc networks that he seems to encounter more and more frequently at places like DebConf and family gatherings signature.asc Description: Digital signature
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, 24 Feb 2006 at 03:30:55 -0800, Steve Langasek wrote: Hi! Bastian Blank, a member of the Debian kernel team, is looking at integrating XenoLinux builds into the official linux-2.6 package. I think that's a much better option, and would strongly encourage anyone interested in Xen packaging to coordinate with the kernel team on this. We will, of course, thanks! Here is an explanation why ha haven't yet! (Yes, I'm aware there's a pkg-xen maintenance team on alioth as well; but AFAICT the maintainer of the current xen package is not a member of that packaging group, and there's no mention of xen on the wnpp bug page -- what's up with that?) The current Debian Xen package is very old, and also has some policy compliance problems. We (as in: a lot of people who tried) haven't received any answer by the current Xen maintainer about xen status for a long time (as documented in debian bugs #342249 and #271051) so Jeremy Bouse ([EMAIL PROTECTED]) has set up a project on alioth and invited people who were interested or maintained unofficial packages to join, which some people (5 of them, as Ralph said) did. After that we've been working on preparing a clean release of Xen 3.0 for sid. We probably should have reported to wnpp and -devel before, sorry! Anyway Jeremy was the one who was going to do so, and he planning to do this soon (AFAIK). We had planned to contact the kernel team, but hadn't yet, as we wanted before to have a working hypervisor in sid (even if that meant that users needed to roll their own kernels) and then see if the kernel team was interested in helping us integrating xen better. (We also had planned contacting the glibc team, at that time, asking them if it could be possible to have a non-segmented glibc in debian for us, but that too was to be done later) Everything that the pkg-xen team did and planned till now can be seen in the public alioth mailing list archives. http://lists.alioth.debian.org/pipermail/pkg-xen-devel/ and http://lists.alioth.debian.org/pipermail/pkg-xen-changes/ ! Of course anyone interested in Xen is welcome to join! :) Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Honesty in Debian (was Re: Amendment to GR on GFDL, and the changes to the Social Contract
Hello Sven, Sorry for the late reponse, but I am currently Off-Line. Am 2006-02-13 15:54:23, schrieb Sven Luther: Like the mips binary which is part of the tg3 (or some other of those) driver and uploaded to to the mips core on the card in question ? Does that mean that we will also distribute binary only drivers for broadcom wifi chips in main ? I think, between this two passages are very big differences. The first one load a BLOB/Firmware into a Hardware which runs ON the Hardware and not in the OS. The later one, runs the BLOB/firmware inside the OS, where we can have influence. In the last years I have created some Hardware myself and I am using CPU's 386EX und 486/5x86. I am using SRAM/NVRAM to store OS, which is written entirely in ASM. Now this software ca not run in the hostsystem of the hardware I have created. So what now? Why should I distribute the Sourcecode? - What are your interests? If someone buy my hardware, he get a userspace tool to upload the Firmare and run the hardware. And now it is non-free? Another hardware is the Maxim/Dallas One-Wire technologie. I have recently bought all sensores and put it into a serial line driven network. I have coded kernel modules (2.4/2.6) which write into /proc/driver/onewire/serno and I controll the One-Wire Hardware form the OS. Here we have the influence, whether we provide the sourcecode or not. - main or non-free. I think, the discusion about Firmware which IS required on some external hardware only (and does not run in the OS) is beside not to call it ridiculous. Note: I have made Debian-Packages for the Firmware BLOBs of my Hardware so $USER can upload it easyly to the Hardware. And now again: Why do you want the Source-Code of a perfectly working Hardware which you can not modify? Friendly, Sven Luther Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 04:37:56PM +0100, Bastian Blank wrote: This is insufficient. Either maintain both 3.0 and unstable or none. In the meantime, the kernel team will maintain both. As far as I understand, you will just maintain Xen kernel images. (for dom0 only ?). We just have to duplicate our packages to add a -unstable release. I don't think this is a great deal, at the point we are, we can do it. -- Julien Danjou .''`. Debian Developer : :' : http://julien.danjou.info `. `' http://people.debian.org/~acid `- 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD signature.asc Description: Digital signature
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 04:37:56PM +0100, Bastian Blank wrote: Hi, This is great! In the meantime we are working on uploading xen 3.0 to unstable, and our packages I think are almost ready too! This is insufficient. Either maintain both 3.0 and unstable or none. In the meantime, the kernel team will maintain both. I think we have no problem packaging the unstable hypervisor too, as the kernel team provides support for it, after the stable one is in debian! Why don't you join the xen team list, so we can work together on that (contacting the kernel team when all of them are needed). I think having some people both on the kernel and the xen team will be better, of course! On the other hand Xen is not the kernel, so isn't it better if there is a team for it, even if strongly connected with the kernel one? Actually I'm sorry I had mis-read your statement... I thought you were talking just about the kernel while you referred to the hypervisor too! That's why my sentence might have appeared a bit out of context, sorry! So... what do you think we can do now? Can we join our efforts on xen or you strongly think it should be left to the kernel team, and we should just close the alioth project? Thanks! :) Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 04:54:24PM +0100, Julien Danjou wrote: Hi, As far as I understand, you will just maintain Xen kernel images. (for dom0 only ?). Actually I think he meant the hypervisors too... Anyway I also think that if the kernel team is going to maintain the kernel images there should be some made for unprivileged domains too! :) We just have to duplicate our packages to add a -unstable release. I don't think this is a great deal, at the point we are, we can do it. Yeah, I think so too... But I'm also for making xen 3.0 enter unstable first, and uploading the unstable branch a bit later! Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 04:54:24PM +0100, Julien Danjou wrote: As far as I understand, you will just maintain Xen kernel images. (for dom0 only ?). No. The kernel team will maintain xen (in variants 3.0 and unstable). Bastian -- Vulcans worship peace above all. -- McCoy, Return to Tomorrow, stardate 4768.3
Re: ./configure in debian/rules
Pjotr Kourzanov [EMAIL PROTECTED] wrote: Dear developers, In a number of packages (e.g., busybox, dash and many more) the debian/rules Makefile calls ./configure without --host argument. This makes the life quite difficult for cross-compilation - for every such package I need to add --host=$(DEB_HOST_GNU_TYPE) to every configure invocation in debian/rules. Were can I read up on how and why I should do this? AFAIR, the policy mentions this variable in the section about debian/rules, but does not make their use mandatory. Is there a workaround that avoids touching debian/rules? What is the preferred way to solve this problem with dpkg-buildpackage? Educate your developer collegues? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: debian zeroconf group?
On Fri, Feb 24, 2006 at 10:38:24AM -0500, Joey Hess wrote: [Ccing maintainers of mdns stuff, please followup to debian-devel] With avahi in unstable we seem to have a fairly capable set of zeroconf/mdns tools in Debian now, albeit with some holes. There are for example some things like mod_dnssd that are not packaged yet and some interesting patches that aren't applied to some apps. And adding mdns to /etc/nsswitch.conf is still being worked out. Mod_dnssd is in NEW currently, so that should resolve itself pretty soon. Having mdns in /etc/nsswitch would be great. I would like to investigate the possibility of adding a task to tasksel that fully sets up a system to prticipate in a zeroconf network. That would mean, you pick this task and you can resolve mdns names; if you installed a desktop, the desktop supports mdns; if you installed a web server or ssh server those services are published via mdns etc. There is still some integration work to do before that's possible, but it's my goal. Sound great. I think a team to work on this stuff would be useful. Right now there seems to be no coordinated effort to put everything together and fill in the holes, just various people working on their own peices. While that scattershot approach has worked ok so far, getting everyone together integrating stuff could improve things a lot. If people agree let me know and I can do the standard alioth dance. Sounds good. We've been doing avahi and mod-dnssd in pkg-utopia on alioth, but i've no problems with switching them to a another (better suited?) project or work together in pkg-utopia. Sjoerd -- Life is the childhood of our immortality. -- Goethe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian zeroconf group?
Joey Hess wrote: If people agree let me know and I can do the standard alioth dance. I would be interested in participating in such a group. Regards, Frederic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian zeroconf group?
Frederic Peters a écrit : Joey Hess wrote: If people agree let me know and I can do the standard alioth dance. I would be interested in participating in such a group. I'm interested too. Regards, -- Jérémie signature.asc Description: OpenPGP digital signature
Re: debian zeroconf group?
On 2/24/06, Sjoerd Simons [EMAIL PROTECTED] wrote: On Fri, Feb 24, 2006 at 10:38:24AM -0500, Joey Hess wrote: [Ccing maintainers of mdns stuff, please followup to debian-devel] With avahi in unstable we seem to have a fairly capable set of zeroconf/mdns tools in Debian now, albeit with some holes. There are for example some things like mod_dnssd that are not packaged yet and some interesting patches that aren't applied to some apps. And adding mdns to /etc/nsswitch.conf is still being worked out. Mod_dnssd is in NEW currently, so that should resolve itself pretty soon. Having mdns in /etc/nsswitch would be great. I would like to investigate the possibility of adding a task to tasksel that fully sets up a system to prticipate in a zeroconf network. That would mean, you pick this task and you can resolve mdns names; if you installed a desktop, the desktop supports mdns; if you installed a web server or ssh server those services are published via mdns etc. There is still some integration work to do before that's possible, but it's my goal. About ssh, ssh doesn't have a built-in support for zeroconf, but uses avahi.service(5) to indirectly publish its zeroconf service. Maybe this file ssh.service should be installed by the openssh-server package. Other packages could do the same: ntp for example. Sound great. I think a team to work on this stuff would be useful. Right now there seems to be no coordinated effort to put everything together and fill in the holes, just various people working on their own peices. While that scattershot approach has worked ok so far, getting everyone together integrating stuff could improve things a lot. If people agree let me know and I can do the standard alioth dance. Sounds good. We've been doing avahi and mod-dnssd in pkg-utopia on alioth, but i've no problems with switching them to a another (better suited?) project or work together in pkg-utopia. Sjoerd -- Life is the childhood of our immortality. -- Goethe -- Sebastien Estienne
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 05:05:33PM +0100, Bastian Blank wrote: No. The kernel team will maintain xen (in variants 3.0 and unstable). Okay, I misunderstood. You will maintain userland tools too ? Is you work is already finished and available somewhere ? Right, I am juste a little disapointed. :) -- Julien Danjou .''`. Debian Developer : :' : http://julien.danjou.info `. `' http://people.debian.org/~acid `- 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD signature.asc Description: Digital signature
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Friday, 24 February 2006 16:56, Guido Trotter wrote: So... what do you think we can do now? Can we join our efforts on xen or you strongly think it should be left to the kernel team, and we should just close the alioth project? Well, if the kernel team answers left to the kernel team and you close the alioth project, I guess you can always move into the kernel team ;) Best regards -- Isaac Clerencia at Warp Networks, http://www.warp.es Work: [EMAIL PROTECTED] | Debian: [EMAIL PROTECTED] pgpSFfecmzk4p.pgp Description: PGP signature
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 05:20:17PM +0100, Isaac Clerencia wrote: Hi, Well, if the kernel team answers left to the kernel team and you close the alioth project, I guess you can always move into the kernel team ;) Yes, we could, of course... But on the other hand I believe that the xen hypervisor and userspace tools are actually different from the linux kernel (as they support multiple kernels and operating systems), even though the linux kernel patch has its right place inside the kernel itself... I agree that we should have probably have publicized more about our intent to work on xen, but at least it was spread all other the BTS in the xen package! And on the other hand we didn't know about Bastian's effort (which was not in the bts under either wnpp or xen), or we wouldn't have started our work without asking him! Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Friday, 24 February 2006 17:34, Guido Trotter wrote: Yes, we could, of course... But on the other hand I believe that the xen hypervisor and userspace tools are actually different from the linux kernel (as they support multiple kernels and operating systems), even though the linux kernel patch has its right place inside the kernel itself... I agree. I just would like to ask that, please, don't disband just because of disagreement with the kernel team, but try to cooperate anyway. Best regards -- Isaac Clerencia at Warp Networks, http://www.warp.es Work: [EMAIL PROTECTED] | Debian: [EMAIL PROTECTED] pgpX3C7JavGuf.pgp Description: PGP signature
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, 24 Feb 2006, Bastian Blank wrote: On Fri, Feb 24, 2006 at 04:54:24PM +0100, Julien Danjou wrote: As far as I understand, you will just maintain Xen kernel images. (for dom0 only ?). No. The kernel team will maintain xen (in variants 3.0 and unstable). Bastian, as far as I know, you are the *only* person on the kernel team interested in maintaining xen (at least I haven't heard others talking about it). I imagine that it is fairly complicated package, and there is already a whole team of people dedicated to packaging it. Definitely, it would be more productive to just include xen kernel images into linux-2.6 and play nicely with the xen team to make sure that it runs smoothly. Telling them to take a hike at this point just because you are on the kernel team appears a lot like hijacking of the xen package to me. Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ./configure in debian/rules
Frank Küster: Were can I read up on how and why I should do this? /usr/share/doc/autotools-dev/README.Debian.gz -- Pelle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 05:41:53PM +0100, Isaac Clerencia wrote: Hi, I agree. I just would like to ask that, please, don't disband just because of disagreement with the kernel team, but try to cooperate anyway. I don't think we want to! And I hope there is no disagreement (we still don't know)! The reason I think xen would be better served having its own committed team, repository, etc, is that it would be easier for anyone interested in xen to follow just mailing lists dedicated to it and its repository commits, rather than having to closely follow all the linux kernel work, mailing list, etc! Of course I also think it's great to have some people on both, so to have a close coordination between the xen and kernel releases. Also the xen team would need to coordinate with the glibc team (for the segmentation issues) and one day with the d-i team too, in order to try making a Debian/GNU/Xen/Linux (or whatever that should be called) installable directly on a system! Even upstream considers the linux kernel patch, the hypervisor and the tools separate, has separate mailing lists for them, and a separate mercurial repository for linux, even if for now they distribute the linux patch together with xen, until xen is merged into Linus' tree (or at least so Ian Pratt has said). If we can have the xen patch included in the debian kernel, thus pre-dating kernel.org inclusion that's really a good thing! Thanks! Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ./configure in debian/rules
Frank Küster [EMAIL PROTECTED] writes: Were can I read up on how and why I should do this? AFAIR, the policy /usr/share/doc/autotools-dev/README.Debian.gz has advice on how to run configure scripts sanely. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian zeroconf group?
Hi, Joey Hess wrote: With avahi in unstable we seem to have a fairly capable set of zeroconf/mdns tools in Debian now, albeit with some holes. There are for example some things like mod_dnssd that are not packaged yet and some interesting patches that aren't applied to some apps. And adding mdns to /etc/nsswitch.conf is still being worked out. One thing I desperately wish for is for a big flip switch to turn it off, even if I have KDE or GNOME installed, both on a packaging system level (for example, by having a package disable-zeroconf that helps me avoid installation) as well as on a enable/disable level, where I could tell my laptop to not talk to the weirdos hanging out in the airport lounge. Simon signature.asc Description: OpenPGP digital signature
Re: lists.d.o Spam (was: Marking BTS spam)
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: on 2: we would need a whole spam-mail including all headers so we can find charakteristika to filter on, so i now take all nominated postings, and try to find patterns with some black shell-magic. Is sa-learn --spam considered black shell magic? Of course you need to sa-learn --ham on some non-spam too. That's what I do with nominated messages to the BTS, and messages with a certain range of spamassassin scores. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 04:56:35PM +0100, Guido Trotter wrote: On the other hand Xen is not the kernel, so isn't it better if there is a team for it, even if strongly connected with the kernel one? It is a sort of kernel. And no, I don't think it is better. Just to say, how connected xen to linux is: For example: There are three kernel trees of xen: - from xen-3.0-testing, 2.6.12 - from linux-2.6-xen, 2.6.16-rc4 - from linux-2.6-merge, 2.6.16-rc3 All of them have different needs from xen. The kernels from xen-3.0-testing and linux-2.6-merge works with a 3.0 and unstable hypervisor. The 3.0 utils only works on the kernel from xen-3.0-testing. The unstable utils with the other. But with both hypervisors. So... what do you think we can do now? Can we join our efforts on xen or you strongly think it should be left to the kernel team, and we should just close the alioth project? I won't reject the help of volunteers but I strongly think that the kernel team needs to have its hands on them. Bastian -- Peace was the way. -- Kirk, The City on the Edge of Forever, stardate unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 06:06:22PM +0100, Bastian Blank wrote: I won't reject the help of volunteers but I strongly think that the kernel team needs to have its hands on them. How many members of the kernel team are planning to do active work on Xen, kernel and userspace? Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 06:06:22PM +0100, Bastian Blank wrote: Hi, It is a sort of kernel. Yeah, it's a sort of kernel, but it's not the linux kernel... And it seems the kernel team is about the linux kernel, not just any kernel, isn't it? Just to say, how connected xen to linux is: For example: There are three kernel trees of xen: - from xen-3.0-testing, 2.6.12 - from linux-2.6-xen, 2.6.16-rc4 - from linux-2.6-merge, 2.6.16-rc3 All of them have different needs from xen. The kernels from xen-3.0-testing and linux-2.6-merge works with a 3.0 and unstable hypervisor. The 3.0 utils only works on the kernel from xen-3.0-testing. The unstable utils with the other. But with both hypervisors. That's I think because xen is still young, and is starting just now its distribution integration, and probably will happen a lot less when it will be integrated with Linux (Linus' tree) and the development of xenolinux will proceed at a different pace than the hypervisor. Then probably it will just be that any xen version will have a minimum linux version needed, just as now a lot of other stuff does, and there will be nothing special in it, except the fact that it needs a kernel compiled for the appropriate subarch). I won't reject the help of volunteers but I strongly think that the kernel team needs to have its hands on them. What do other people in the kernel team think? If the majority of them agree fine, otherwise are you sure it's not counterproductive to force xen in the kernel team hands if most of them don't want to touch it, and on the other hand to risk driving away other people who just cannot follow the whole linux business but could work on the xen hypervisor and tools, help coordinate with xen's upstream, debian glibc and d-i, etc! Especially if you and other people who would do both can still do it! :) Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ./configure in debian/rules
Per Olofsson [EMAIL PROTECTED] wrote: Frank Küster: Were can I read up on how and why I should do this? /usr/share/doc/autotools-dev/README.Debian.gz Thanks - but I think this should be documented at a more visible place. If it's not the policy, developer's reference. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: On Thu, Feb 23, 2006 at 01:30:25PM -0800, Thomas Bushnell BSG wrote: Help me out then. You seemed to suggest that not putting ndiswrapper in main would be to ignore rules that are very clearly laid out in the SC and DFSG. I suggested that the CTTE overriding the developer's judgement in this instance would be an abuse of power, since the DFSG and SC (not to mention policy) clearly spell out the requirements for main, and ndiswrapper clearly meets them. I think this is clearly incorrect. The DFSG and the SC do not say anything about the requirements for main that I can see. And it is the *job* of the tech-ctte to resolve disputes. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Fri, Feb 24, 2006 at 09:56:46AM -0800, Thomas Bushnell BSG wrote: I think this is clearly incorrect. The DFSG and the SC do not say anything about the requirements for main that I can see. And it is the *job* of the tech-ctte to resolve disputes. I don't enjoy speaking with you, and I'm going to stop now. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: On Fri, Feb 24, 2006 at 09:56:46AM -0800, Thomas Bushnell BSG wrote: I think this is clearly incorrect. The DFSG and the SC do not say anything about the requirements for main that I can see. And it is the *job* of the tech-ctte to resolve disputes. I don't enjoy speaking with you, and I'm going to stop now. Um, ok, whatever. So, for the record: The DFSG and the SC don't say anything about the requirements for main; the tech-ctte exists to resolve disputes such as this; and I have no particular stake one way or the other about where ndiswrapper lands. It seems to me to be a quintessentially technical issue, to which some people have attached a status thing, so that if it lands in contrib, it is being somehow demeaned or shortchanged. (And then, some people have gone further, and figure that if their software is being demeaned, then they are being demeaned too.) ndiswrapper seems to me like a useful tool; our standards for main/contrib distinctions are not crystal clear, and call for the exercise of judgment. In the first instance, that judgment is the maintainer's to make, but it is the ftpmasters' job to review it and make their own independent determination about where it belongs in the archive. If there is a dispute, tech-ctte is there to settle it. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Honesty in Debian (was Re: Amendment to GR on GFDL, and the changes to the Social Contract
Michelle Konzack [EMAIL PROTECTED] writes: The first one load a BLOB/Firmware into a Hardware which runs ON the Hardware and not in the OS. The OS *all* runs ON the Hardware. But Debian's determination is about what we distribute. We don't distribute non-free things as part of Debian main. This is true whatever the name of the processor, whatever the role of the software in the system, and so forth. It is a rule that we apply *equally* to drivers with downloadable firmware and drivers where the code is burned in to the chip: in both cases we do not distribute the code unless it is free software. Saying that the downloadable case is really just like the burned-in case is incorrect: they are the same *except* for the following two features: first, in the downloadable case there is the possibility of free software being used, and second, in the downloadable case we are being asked to violate our principles and distribute the non-free software as part of Debian. Why should I distribute the Sourcecode? - What are your interests? If someone buy my hardware, he get a userspace tool to upload the Firmare and run the hardware. And now it is non-free? Yes. Freedom refers to liberty, not price. Do they get a userspace tool to modify the code if they wish? Do other hardware vendors get to see your code so that they (and you) can participate cooperatively in the steady improvement of the software? And now again: Why do you want the Source-Code of a perfectly working Hardware which you can not modify? Because we want to be able to learn from and modify the program. Another way to put it: Why do you want us to distribute your software for you? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#98549: Obtained DIplomas in 2 Weeks zoe8C
Lazy to attend exam or classes? We have Diplomas, Degrees, Masters' or Doctorate to choose from any field of your interest. Only 2 weeks require to delivers the prestigious non-accredited universities paper to your doorstep. Do not hesitate to give us a call today! 1-484-693-8861 n7b -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian zeroconf group?
Hello, On Fri, Feb 24, 2006 at 10:38:24AM -0500, Joey Hess wrote: [Ccing maintainers of mdns stuff, please followup to debian-devel] With avahi in unstable we seem to have a fairly capable set of zeroconf/mdns tools in Debian now, albeit with some holes. There are for example some things like mod_dnssd that are not packaged yet and some interesting patches that aren't applied to some apps. And adding mdns to /etc/nsswitch.conf is still being worked out. I would like to investigate the possibility of adding a task to tasksel that fully sets up a system to prticipate in a zeroconf network. That would mean, you pick this task and you can resolve mdns names; if you installed a desktop, the desktop supports mdns; if you installed a web server or ssh server those services are published via mdns etc. There is still some integration work to do before that's possible, but it's my goal. I think a team to work on this stuff would be useful. Right now there seems to be no coordinated effort to put everything together and fill in the holes, just various people working on their own peices. While that scattershot approach has worked ok so far, getting everyone together integrating stuff could improve things a lot. If people agree let me know and I can do the standard alioth dance. I agree with the principle. I think zeroconf is a great thing for debian. I think the basic service that should be enabled : - printing with cups (apple has a patch for this), - instant messenger with gaim (there is a bonjour plugin for GAIM, but it doesn't seem to work great), - sharing data (maybe with gnome-vfs...) I really would like to see : - ssmtp with automatic realy to a real smtp (the smtp publish itself with zeroconf/mdns) - sane with hal+bonjour (ie when a scanner is plugged, there is a net backend which is published) - proxy configuration... Unfortunately i don't have enough time to give some help for this. But i really think it should be a great idea to have it in debian. Kind regard Sylvain Le Gall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ./configure in debian/rules
On Fri, 24 Feb 2006, Frank Küster wrote: Per Olofsson [EMAIL PROTECTED] wrote: Frank Küster: Were can I read up on how and why I should do this? /usr/share/doc/autotools-dev/README.Debian.gz Thanks - but I think this should be documented at a more visible place. If it's not the policy, developer's reference. Policy has nothing to do with it. The developer's reference already tells you about that in appendix A.6.2. -- 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: Problems found by piuparts
On 2/20/06, Lars Wirzenius [EMAIL PROTECTED] wrote: In the past six months, I've filed about 260 bug reports based on what piuparts has found. About 40% of those have been fixed so far. Below is a summary of the common problems, hopefully the list will help everyone to find and especially avoid problems in their own packages. (...) Hi Lars, I think some of these problems can be detected by lintian, adding some more checks there. It could bring more visibility to so common errors. Comments ? -- stratus
Re: Problems found by piuparts
[Gustavo Franco] I think some of these problems can be detected by lintian, adding some more checks there. It could bring more visibility to so common errors. Comments ? A better way to phrase Comments? would be: Here is a proof-of- concept patch to lintian to demonstrate which of these issues can be detected. Comments? signature.asc Description: Digital signature
Re: Problems found by piuparts
On 2/24/06, Peter Samuelson [EMAIL PROTECTED] wrote: [Gustavo Franco] I think some of these problems can be detected by lintian, adding some more checks there. It could bring more visibility to so common errors. Comments ? A better way to phrase Comments? would be: Here is a proof-of- concept patch to lintian to demonstrate which of these issues can be detected. Comments? I won't waste my time writing a patch without hear Lars' and lintian maintainers opinions first. I still act as a member of the Debian community that we used to be, and last time i see you wasn't a lintian maintainer. You can get away with your rudeness and came up with a patch before me, because it seems that you just don't care about *comments*. Thanks, -- stratus
Re: Problems found by piuparts
Gustavo Franco [EMAIL PROTECTED] writes: On 2/20/06, Lars Wirzenius [EMAIL PROTECTED] wrote: In the past six months, I've filed about 260 bug reports based on what piuparts has found. About 40% of those have been fixed so far. Below is a summary of the common problems, hopefully the list will help everyone to find and especially avoid problems in their own packages. (...) Hi Lars, I think some of these problems can be detected by lintian, adding some more checks there. It could bring more visibility to so common errors. Comments ? Most of those look semi-difficult to do in lintian because most of them require fairly deep parsing of maintainer scripts. lintian can get a long way by cheating with simple heuristics, but that approach can be somewhat unreliable and prone to false positives. Certainly it's possible, and I expect the lintian maintainers would welcome patches, but I don't think it's that straightforward. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ./configure in debian/rules
Frank Küster [EMAIL PROTECTED] writes: Pjotr Kourzanov [EMAIL PROTECTED] wrote: In a number of packages (e.g., busybox, dash and many more) the debian/rules Makefile calls ./configure without --host argument. This makes the life quite difficult for cross-compilation - for every such package I need to add --host=$(DEB_HOST_GNU_TYPE) to every configure invocation in debian/rules. Were can I read up on how and why I should do this? AFAIR, the policy mentions this variable in the section about debian/rules, but does not make their use mandatory. Hm, I've only been doing this in packages that use AC_CANONICAL_HOST. Is there benefit to doing this even with packages that don't care at all about the system type and don't even include config.guess and config.sub in the source package? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, 24 Feb 2006 18:04:03 +0100 Guido Trotter [EMAIL PROTECTED] wrote: The reason I think xen would be better served having its own committed team, repository, etc, is that it would be easier for anyone interested in xen to follow just mailing lists dedicated to it and its repository commits, rather than having to closely follow all the linux kernel work, mailing list, etc! Of course I also think it's great to have some people on both, so to have a close coordination between the xen and kernel releases. Well said. This is also the reasoning behind a separate project for yaird (not all interested in that perl-based ramdisk generator is interested in other aspects of kernel maintainance). Similarly I suggest group-maintaining initramfs-tools separately (not all have interest in dealing with udev). Greetings, - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm pgpjrKgJEKYkn.pgp Description: PGP signature
Re: Problems found by piuparts
On 2/24/06, Russ Allbery [EMAIL PROTECTED] wrote: Gustavo Franco [EMAIL PROTECTED] writes: On 2/20/06, Lars Wirzenius [EMAIL PROTECTED] wrote: In the past six months, I've filed about 260 bug reports based on what piuparts has found. About 40% of those have been fixed so far. Below is a summary of the common problems, hopefully the list will help everyone to find and especially avoid problems in their own packages. (...) Hi Lars, I think some of these problems can be detected by lintian, adding some more checks there. It could bring more visibility to so common errors. Comments ? Most of those look semi-difficult to do in lintian because most of them require fairly deep parsing of maintainer scripts. lintian can get a long way by cheating with simple heuristics, but that approach can be somewhat unreliable and prone to false positives. Certainly it's possible, and I expect the lintian maintainers would welcome patches, but I don't think it's that straightforward. Hi Russ, What i thought in a first look to the Lars' list. I think that the best thing would include piuparts as a infrastructural test (oficially as a part of our archive code), or due to restrict admin time to do that, opt for something like piuparts.debian.org as we have lintian.d.o. I would be glad to help with a web interface to show the piuparts html results in a organized way, but i don't have enough resources to test every package, but i'm sure that somebody will step in at least for i386 architecture. Since Lars already did the check (for i386 only, i think), maybe we just need to bring more organization/visibility to the results and keep them updated, right? Hope that helps, -- stratus
Re: ./configure in debian/rules
On Fri, 24 Feb 2006, Russ Allbery wrote: Frank Küster [EMAIL PROTECTED] writes: Pjotr Kourzanov [EMAIL PROTECTED] wrote: In a number of packages (e.g., busybox, dash and many more) the debian/rules Makefile calls ./configure without --host argument. This makes the life quite difficult for cross-compilation - for every such package I need to add --host=$(DEB_HOST_GNU_TYPE) to every configure invocation in debian/rules. Were can I read up on how and why I should do this? AFAIR, the policy mentions this variable in the section about debian/rules, but does not make their use mandatory. Hm, I've only been doing this in packages that use AC_CANONICAL_HOST. Is there benefit to doing this even with packages that don't care at all about the system type and don't even include config.guess and config.sub in the source package? If config.sub is not needed, I am almost sure that --host is not needed. Nor is --build, or --target. They are not supposed to be able to work without config.sub to canonize them. But do read autotools-dev README.Debian about these three, the way to correctly use them changed from autoconf 2.13 to autoconf 2.5x. Come to think of it, adding a note about when they are required is in line with autotools-dev README's objectives. I will do so. -- 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: ./configure in debian/rules
On Fri, 24 Feb 2006, Henrique de Moraes Holschuh wrote: If config.sub is not needed, I am almost sure that --host is not needed. Nor is --build, or --target. They are not supposed to be able to work without config.sub to canonize them. Very well, I have verified this now to be _wrong_. Autoconf always support cross-compiling, therefore it always has use for --host, --build and --target. However, unless AC_CANONICAL_* is used, you'd better supply the full, canonized arch string or things like the cross-compiler name and libs will be very wrong indeed. Fortunately, nowadays dpkg-architecture is not hideously broken anymore and we get the proper canonical arch name from DEB_HOST_GNU_TYPE and DEB_BUILD_GNU_TYPE, so that's suitable to be directly fed to configure even without AC_CANONICAL_*. If a package does NOT call AC_CANONICAL_* (directly or indirectly. libtool always call this, for example), I suppose not setting --host and --build shouldn't be a problem. But that's because we don't take cross-compiling seriously in Debian for most packages. If we start doing so, that will change. Please just add the recommended --host and --build makefile snippet and feed that to configure in *all* packages. It is better in the long run, and for many packages that is enough to have it cross-compile correctly. -- 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]
Bug#354267: ITP: libghc6-newbinary-dev -- Binary IO Module for ghc
Package: wnpp Severity: wishlist Owner: Charles Stevenson [EMAIL PROTECTED] * Package name: libghc6-newbinary-dev Version : x.y.z Upstream Author : Name [EMAIL PROTECTED] * URL : http://www.example.org/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Description : Binary IO Module for ghc Provides fast bitwise and bytewise IO for files and memory. Designed to emulate the Binary module for nhc. . Website: http://www.n-heptane.com/nhlab/ Jeremy Shaw already has a basic debian/ directory of this package, from which I will be starting. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.4-corezion Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354268: ITP: libghc6-crypto-dev -- GHC 6 libraries for the Haskell Cryptographic Library
Package: wnpp Severity: wishlist Owner: Charles Stevenson [EMAIL PROTECTED] * Package name: libghc6-crypto-dev Version : x.y.z Upstream Author : Name [EMAIL PROTECTED] * URL : http://www.example.org/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Description : GHC 6 libraries for the Haskell Cryptographic Library The Haskell Cryptographic Library collects together existing Haskell cryptographic functions into one cabalized package, together with HUnit tests, QuickCheck property tests, examples showing how to interwork with other cryptographic implementations and examples showing how to handle other ASN.1 definitions. . This package contains the libraries compiled for GHC 6. . Website: http://www.haskell.org/crypto/ Dominic Steinitz the upstream author has been sent a work-in-progress of the debian/ directory. Also e-mailed debian-haskell and Isaac Jones for review. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.4-corezion Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354269: ITP: libghc6-http-dev -- GHC 6 libraries for the Haskell HTTP client library
Package: wnpp Severity: wishlist Owner: Charles Stevenson [EMAIL PROTECTED] * Package name: libghc6-http-dev Version : x.y.z Upstream Author : Name [EMAIL PROTECTED] * URL : http://www.example.org/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Description : GHC 6 libraries for the Haskell HTTP client library HTTP is a set of Haskell client libraries for HTTP/1.0 and HTTP/1.1. . This package contains the libraries compiled for GHC 6. Ganesh Sittampalam already has a basic debian/ directory of this package, from which I will be starting. I also sent a work-in- -progress to debian-haskell and Isaac Jones for review. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.4-corezion Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#354269: ITP: libghc6-http-dev -- GHC 6 libraries for the Haskell HTTP client library
On Fri, Feb 24, 2006 at 02:09:14PM -0800, Charles Stevenson wrote: * Package name: libghc6-http-dev This already exists in unstable. See http://packages.qa.debian.org/h/haskell-http.html Also, libghc6-http-dev is not an appropriate source package. And finaly, I am concerned that you don't intend to build Hugs versions for these Haskell packages you are ITPing. libhugs-http exists in unstable already, so there is no technical reason to avoid it. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354271: ITP: gwydion-dylan -- The Gwydion Dylan Runtime Environment
Package: wnpp Severity: wishlist Owner: Charles Stevenson [EMAIL PROTECTED] * Package name: gwydion-dylan Version : x.y.z Upstream Author : Name [EMAIL PROTECTED] * URL : http://www.gwydiondylan.org/ * License : CMU Description : The Gwydion Dylan Runtime Environment This package contains the libraries and other files needed to run programs compiled with the Gwydion Dylan compiler (d2c). . At some point in the (hopefully near) future, this package will contain the Gwydion Dylan Listener, which will allow interactive exploration of the language. . For more information, see the Gwydion Dylan maintainers' web page at http://www.gwydiondylan.org/. Upstream requested assistance getting the package back into the pool. It was in Debian previously for several years. Could use some assistance on ensuring this conforms to policy. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.4-corezion Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ./configure in debian/rules
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: Please just add the recommended --host and --build makefile snippet and feed that to configure in *all* packages. It is better in the long run, and for many packages that is enough to have it cross-compile correctly. Okay, will do. This would be a great lintian check, although tricky to write because people pass makefile variables and the like to configure. A good first pass might be to just assume everything is fine if there's some makefile variable on the configure invocation line. (That check may also lose if the package has a script that the user runs called configure but the script isn't an Autoconf script, but I'm not sure if that happens for any of our packages.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354272: ITP: gwydion-dylan-dev -- Gwydion Dylan Development Tools
Package: wnpp Severity: wishlist Owner: Charles Stevenson [EMAIL PROTECTED] * Package name: gwydion-dylan-dev Version : 2.4.1 Upstream Author : Gwydion Dylan Hackers * URL : http://www.gwydiondylan.org/ * License : CMU Description : Gwydion Dylan Development Tools CMU's Gwydion Dylan provides d2c, a Dylan-to-C batch compiler. It produces fairly efficient output but requires strange incantations to compile even simple programs. Tools for interfacing with C are included. (The Mindy bytecode interpreter is available as a separate package.) If you're really excited about writing Dylan programs for Linux--and don't mind the inconveniences of d2c--these are the tools to use. If you prefer a mature development environment, try another language. . This package contains the tools necessary to recompile d2c. They include a LISP to Dylan translator, a parser generator, and various tools for maintaining the build tree. This package also contains a few general-purpose development utilities written in Dylan. Orphaned for too long and disappeared. Upstream requested my help to bring the package up to snuff and get it back into the pool. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.4-corezion Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354273: ITP: mindy -- A Dylan interpreter.
Package: wnpp Severity: wishlist Owner: Charles Stevenson [EMAIL PROTECTED] * Package name: mindy Version : 2.4.1 Upstream Author : Gwydion Dylan Hackers * URL : http://www.gwydiondylan.org/ * License : CMU Description : A Dylan interpreter. Mindy is a Dylan bytecode interpreter, originally written as part of CMU's Gwydion Dylan project. It compiles faster than d2c and includes much better debugging tools. Unfortunately, Mindy makes no attempt to run fast. . Documentation for Mindy can be found in the main gwydion-dylan package, or on the web at http://www.gwydiondylan.org/. Orphaned for too long and dropped out of the pool. Upstream requested my assistance to get this back into the pool. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.4-corezion Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354304: ITP: libalgorithm-c3-perl -- A module for merging hierarchies using the C3 algorithm
Package: wnpp Severity: wishlist Owner: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] * Package name: libalgorithm-c3-perl Version : 0.01 Upstream Author : Stevan Little, [EMAIL PROTECTED] * URL : http://mirrors.kernel.org/cpan/modules/by-module/Algorithm/Algorithm-C3-0.01.tar.gz * License : Perl: GPL/Artistic Description : A module for merging hierarchies using the C3 algorithm C3 is the name of an algorithm which aims to provide a sane method resolution order under multiple inheritence. It was first introduced in the langauge Dylan, and then later adopted as the preferred MRO (Method Resolution Order) for the new-style classes in Python 2.3. Most recently it has been adopted as the 'canonical' MRO for Perl 6 classes, and the default MRO for Parrot objects as well. NOTE: this module is excluded from Class::C3 as separate module and is needed to upload new version of libclass-c3-perl and libdbix-class-perl modules. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 06:32:10PM +0100, Guido Trotter wrote: On Fri, Feb 24, 2006 at 06:06:22PM +0100, Bastian Blank wrote: It is a sort of kernel. Yeah, it's a sort of kernel, but it's not the linux kernel... And it seems the kernel team is about the linux kernel, not just any kernel, isn't it? The dom0 kernel is a Linux kernel built for the Xen hypervisor target. If Debian is to provide a complete packaged environment for Xen, which is certainly the goal I'm interested in (and Bastian as well, by the looks of it), that means packaging (at least) a dom0 kernel; and the only way to do that which would make the cut for stable is if it's kept synchronized with the main linux-2.6 package. I think the only reasonable way to do that is within the kernel team, which means people interested in helping with this part should consider joining the kernel team. For the userspace tools and the hypervisor, clearly there's no reason why these need to be part of the kernel team repo as long as they aren't going to be part of the same linux-2.6 source package. As Bastian points out, though, there does still need to be close coordination between the hypervisor/userspace tools and the XenoLinux build, because we don't yet have mix-and-match compatibility. My feeling is that it still makes sense to maintain the hypervisor and userspace tools in a separate pkg-xen group, and just coordinate between the kernel and xen teams for this; but that should be sorted out among those doing the work. I certainly can't see any benefits in terms of source management to having them in the same svn repo with the kernel, anyway. Just to say, how connected xen to linux is: For example: There are three kernel trees of xen: - from xen-3.0-testing, 2.6.12 - from linux-2.6-xen, 2.6.16-rc4 - from linux-2.6-merge, 2.6.16-rc3 All of them have different needs from xen. And are any of them applicable as patches to today's 2.6.15 linux-2.6 tree? The kernels from xen-3.0-testing and linux-2.6-merge works with a 3.0 and unstable hypervisor. The 3.0 utils only works on the kernel from xen-3.0-testing. The unstable utils with the other. But with both hypervisors. That's I think because xen is still young, and is starting just now its distribution integration, and probably will happen a lot less when it will be integrated with Linux (Linus' tree) and the development of xenolinux will proceed at a different pace than the hypervisor. Then probably it will just be that any xen version will have a minimum linux version needed, just as now a lot of other stuff does, and there will be nothing special in it, except the fact that it needs a kernel compiled for the appropriate subarch). In the meantime, to the extent this is an issue it probably means that some of this stuff isn't ready for inclusion in etch. I don't see a point in uploading two versions of xen to unstable, certainly, if they aren't both going to work with the provided kernels. What do other people in the kernel team think? If the majority of them agree fine, otherwise are you sure it's not counterproductive to force xen in the kernel team hands if most of them don't want to touch it, and on the other hand to risk driving away other people who just cannot follow the whole linux business but could work on the xen hypervisor and tools, help coordinate with xen's upstream, debian glibc and d-i, etc! Especially if you and other people who would do both can still do it! :) As an erstwhile contributor to the kernel team who's also interested in Xen packaging, you have my answer above... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 04:22:23PM +0100, Guido Trotter wrote: The debian kernel team will maintain xen images with the linux-2.6 source. I currently prepare both xen 3.0 and unstable packages, which can be hopefully uploaded today. Maintainer will be the kernel team, as there are heavy dependencies between xen and the kernel. This is great! In the meantime we are working on uploading xen 3.0 to unstable, and our packages I think are almost ready too! We planned to contact the kernel team after the upload to see how to coordinate, but it's nice to know that the kernel part is being taken care of! :) Our packages don't contain any kernel (we wouldn't have uploaded them without asking the kernel team, of course) but we plan on shipping just the xen patch for a kernel.org kernel, just in case someone preffers running a non-debian kernel: is that OK, or should we remove that from our sources? FWIW, the policy on kernel patches for sarge was that if it didn't apply to the kernel sources we shipped, it didn't need to be included as a package in stable. We're obviously not shipping a 2.6.12 kernel for etch, so I wouldn't bother uploading that part... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 05:34:44PM -0800, Steve Langasek wrote: Hi, Yeah, it's a sort of kernel, but it's not the linux kernel... And it seems the kernel team is about the linux kernel, not just any kernel, isn't it? The dom0 kernel is a Linux kernel built for the Xen hypervisor target. If Debian is to provide a complete packaged environment for Xen, which is certainly the goal I'm interested in (and Bastian as well, by the looks of it), that means packaging (at least) a dom0 kernel; and the only way to do that which would make the cut for stable is if it's kept synchronized with the main linux-2.6 package. I think the only reasonable way to do that is within the kernel team, which means people interested in helping with this part should consider joining the kernel team. Yes, we absolutely agree about this! We also would have liked for the patch to be integrated in the kernel team's work and from the xen kernel to be built and maintained by the kernel team (of course we hadn't contacted them yet, so we didn't know before if they were interested or if that would have been possible, so it's great to know that such intrest exists!). Of course I agree that anyone interested in Linux+Xen kernel work should join the kernel team! For the userspace tools and the hypervisor, clearly there's no reason why these need to be part of the kernel team repo as long as they aren't going to be part of the same linux-2.6 source package. As Bastian points out, though, there does still need to be close coordination between the hypervisor/userspace tools and the XenoLinux build, because we don't yet have mix-and-match compatibility. I absolutely agree... That's why I'm kindly asking Bastian to join us and to be on both teams, so he and other people interested in doing both can act as a bridge. My feeling is that it still makes sense to maintain the hypervisor and userspace tools in a separate pkg-xen group, and just coordinate between the kernel and xen teams for this; but that should be sorted out among those doing the work. I certainly can't see any benefits in terms of source management to having them in the same svn repo with the kernel, anyway. Thanks for your comments! And are any of them applicable as patches to today's 2.6.15 linux-2.6 tree? I haven't tried, for now... Bastian, have you? What are the results? That's I think because xen is still young, and is starting just now its distribution integration, and probably will happen a lot less when it will be integrated with Linux (Linus' tree) and the development of xenolinux will proceed at a different pace than the hypervisor. Then probably it will just be that any xen version will have a minimum linux version needed, just as now a lot of other stuff does, and there will be nothing special in it, except the fact that it needs a kernel compiled for the appropriate subarch). In the meantime, to the extent this is an issue it probably means that some of this stuff isn't ready for inclusion in etch. I don't see a point in uploading two versions of xen to unstable, certainly, if they aren't both going to work with the provided kernels. Of course I agree with you that until the kernel team (together with the interested people on the xen team) is able to produce working kernels for at least one version of Xen (and possibly the stable one) it's better for us not to push for its inclusion. We are planning to maintain unofficial packages for sarge (for people that want to use Xen right now) and can do that for etch too, if things don't sort out before release. It would be nice anyway to have some more support for Xen in etch (perhaps non segmented glibcs) even if xen itself is not included! Thanks! Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 05:40:04PM -0800, Steve Langasek wrote: Hi, FWIW, the policy on kernel patches for sarge was that if it didn't apply to the kernel sources we shipped, it didn't need to be included as a package in stable. We're obviously not shipping a 2.6.12 kernel for etch, so I wouldn't bother uploading that part... And if they do they can probably be integrated anyway! Ok then, we can probably withraw the patch! Even though that can make things a bit harder for those not running debian kernels since xen is not yet integrated in there... Thanks! Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sysstat 6.1.1-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 23 Feb 2006 21:59:28 +0100 Source: sysstat Binary: isag sysstat Architecture: source i386 all Version: 6.1.1-1 Distribution: unstable Urgency: low Maintainer: Robert Luberda [EMAIL PROTECTED] Changed-By: Robert Luberda [EMAIL PROTECTED] Description: isag - Interactive System Activity Grapher for sysstat sysstat- sar, iostat and mpstat - system performance tools for Linux Changes: sysstat (6.1.1-1) unstable; urgency=low . * New upstream version (development): + daily data files format has changed again. Files: b3732271fba253fad9ecf5341b8d0d67 578 admin optional sysstat_6.1.1-1.dsc 5f4eba52dc145ef48292088a0f8fb4f5 151704 admin optional sysstat_6.1.1.orig.tar.gz 828678abc82a9f82e8d313e5a376005a 23871 admin optional sysstat_6.1.1-1.diff.gz 4802d82e48ec5a9da8506bffbd7f8f9d 22320 admin optional isag_6.1.1-1_all.deb a55075ce66586c9af0874e74434ea8b6 153790 admin optional sysstat_6.1.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/iTbThh1cJ0wnDsRAkjoAJ9XI5TKOdD1bpJkOdQ3uX71DstNawCfW5vt 3IOkR2jM5fJT7YK/Of+vw6c= =gX2j -END PGP SIGNATURE- Accepted: isag_6.1.1-1_all.deb to pool/main/s/sysstat/isag_6.1.1-1_all.deb sysstat_6.1.1-1.diff.gz to pool/main/s/sysstat/sysstat_6.1.1-1.diff.gz sysstat_6.1.1-1.dsc to pool/main/s/sysstat/sysstat_6.1.1-1.dsc sysstat_6.1.1-1_i386.deb to pool/main/s/sysstat/sysstat_6.1.1-1_i386.deb sysstat_6.1.1.orig.tar.gz to pool/main/s/sysstat/sysstat_6.1.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dbs 0.38 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 23 Feb 2006 22:07:22 +0100 Source: dbs Binary: dbs Architecture: source all Version: 0.38 Distribution: unstable Urgency: low Maintainer: Robert Luberda [EMAIL PROTECTED] Changed-By: Robert Luberda [EMAIL PROTECTED] Description: dbs- Allows Debian source packages with multiple patches Closes: 248484 324986 Changes: dbs (0.38) unstable; urgency=low . * Mention dbs(7) in README.Debian (closes: #248484). * dbs-edit-patch: handle -T and -P options with getopt (closes: #324986). However setting appropriate variables in debian/vars is much more comfortable then using the options. * dbs-edit-patch.1: + use plain text format for the page instead of the XML one + document the new options. * dbs.7: minor formatting fixes. * sys-build.mk: Unexport CDPATH ENV (just like I did in dbs-build.mk). * dbs-build.mk: Remove deprecated `-3' option from diff call in the i make_patch target. * dbs-split: Check for existence of debian/compat file if DH_COMPAT variable is not defined. * debian/rules: preserve timestamp of installed files. * debian/control: remove build-dependency on xmlto. * Reorganise a source tree a bit, move man pages and examples to separate subdirectories, remove unneeded dbs.sgml lib.compat files. Files: f616a9ed6e825fc22751af8a5a225c57 478 devel optional dbs_0.38.dsc 06cb5bf1d0eda47235231909a37aade7 64639 devel optional dbs_0.38.tar.gz ddc18d5521477e2a7007e3e387d9897b 23500 devel optional dbs_0.38_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/iQuThh1cJ0wnDsRAlIvAJ900BYIhqu6CMK1lstmqzcqRS08xgCfYmXb Pe0oqS2lCFicM9Hte6qo898= =ZuDV -END PGP SIGNATURE- Accepted: dbs_0.38.dsc to pool/main/d/dbs/dbs_0.38.dsc dbs_0.38.tar.gz to pool/main/d/dbs/dbs_0.38.tar.gz dbs_0.38_all.deb to pool/main/d/dbs/dbs_0.38_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted linux-kernel-di-ia64-2.6 1.6 (ia64 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 24 Feb 2006 00:42:20 -0700 Source: linux-kernel-di-ia64-2.6 Binary: usb-modules-2.6.15-1-itanium-smp-di nic-modules-2.6.15-1-itanium-smp-di usb-storage-modules-2.6.15-1-itanium-smp-di firmware-modules-2.6.15-1-itanium-smp-di jfs-modules-2.6.15-1-itanium-smp-di ext3-modules-2.6.15-1-itanium-smp-di scsi-core-modules-2.6.15-1-itanium-smp-di ufs-modules-2.6.15-1-itanium-smp-di xfs-modules-2.6.15-1-itanium-smp-di crc-modules-2.6.15-1-itanium-smp-di plip-modules-2.6.15-1-itanium-smp-di fb-modules-2.6.15-1-itanium-smp-di kernel-image-2.6.15-1-itanium-smp-di irda-modules-2.6.15-1-itanium-smp-di parport-modules-2.6.15-1-itanium-smp-di nic-usb-modules-2.6.15-1-itanium-smp-di nic-shared-modules-2.6.15-1-itanium-smp-di scsi-modules-2.6.15-1-itanium-smp-di ntfs-modules-2.6.15-1-itanium-smp-di reiserfs-modules-2.6.15-1-itanium-smp-di fat-modules-2.6.15-1-itanium-smp-di input-modules-2.6.15-1-itanium-smp-di mouse-modules-2.6.15-1-itanium-smp-di acpi-modules-2.6.15-1-itanium-smp-di firewire-core-modules-2.6.15-1-itanium-smp-di loop-modules-2.6.15-1-itanium-smp-di ppp-modules-2.6.15-1-itanium-smp-di md-modules-2.6.15-1-itanium-smp-di pcmcia-modules-2.6.15-1-itanium-smp-di sata-modules-2.6.15-1-itanium-smp-di scsi-common-modules-2.6.15-1-itanium-smp-di ide-modules-2.6.15-1-itanium-smp-di ide-core-modules-2.6.15-1-itanium-smp-di ipv6-modules-2.6.15-1-itanium-smp-di serial-modules-2.6.15-1-itanium-smp-di cdrom-core-modules-2.6.15-1-itanium-smp-di Architecture: source ia64 Version: 1.6 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: dann frazier [EMAIL PROTECTED] Description: acpi-modules-2.6.15-1-itanium-smp-di - ACPI support modules (udeb) cdrom-core-modules-2.6.15-1-itanium-smp-di - CDROM support (udeb) crc-modules-2.6.15-1-itanium-smp-di - CRC modules (udeb) ext3-modules-2.6.15-1-itanium-smp-di - EXT3 filesystem support (udeb) fat-modules-2.6.15-1-itanium-smp-di - FAT filesystem support (udeb) fb-modules-2.6.15-1-itanium-smp-di - Frame buffer support (udeb) firewire-core-modules-2.6.15-1-itanium-smp-di - Core FireWire drivers (udeb) firmware-modules-2.6.15-1-itanium-smp-di - Firmware request modules (udeb) ide-core-modules-2.6.15-1-itanium-smp-di - IDE support (udeb) ide-modules-2.6.15-1-itanium-smp-di - IDE drivers (udeb) input-modules-2.6.15-1-itanium-smp-di - Input devices support (udeb) ipv6-modules-2.6.15-1-itanium-smp-di - IPv6 driver (udeb) irda-modules-2.6.15-1-itanium-smp-di - Infrared devices support (udeb) jfs-modules-2.6.15-1-itanium-smp-di - JFS filesystem support (udeb) kernel-image-2.6.15-1-itanium-smp-di - Linux kernel binary image for the Debian installer (udeb) loop-modules-2.6.15-1-itanium-smp-di - Loopback filesystem support (udeb) md-modules-2.6.15-1-itanium-smp-di - RAID and LVM support (udeb) mouse-modules-2.6.15-1-itanium-smp-di - Mouse support (udeb) nic-modules-2.6.15-1-itanium-smp-di - Common NIC drivers (udeb) nic-shared-modules-2.6.15-1-itanium-smp-di - Shared NIC drivers (udeb) nic-usb-modules-2.6.15-1-itanium-smp-di - USB NIC drivers (udeb) ntfs-modules-2.6.15-1-itanium-smp-di - NTFS filesystem support (udeb) parport-modules-2.6.15-1-itanium-smp-di - Parallel port support (udeb) pcmcia-modules-2.6.15-1-itanium-smp-di - Common PCMCIA drivers (udeb) plip-modules-2.6.15-1-itanium-smp-di - PLIP drivers (udeb) ppp-modules-2.6.15-1-itanium-smp-di - PPP drivers (udeb) reiserfs-modules-2.6.15-1-itanium-smp-di - Reiser filesystem support (udeb) sata-modules-2.6.15-1-itanium-smp-di - SATA drivers (udeb) scsi-common-modules-2.6.15-1-itanium-smp-di - Very common SCSI drivers (udeb) scsi-core-modules-2.6.15-1-itanium-smp-di - Core SCSI subsystem (udeb) scsi-modules-2.6.15-1-itanium-smp-di - SCSI drivers (udeb) serial-modules-2.6.15-1-itanium-smp-di - Serial drivers (udeb) ufs-modules-2.6.15-1-itanium-smp-di - UFS filesystem support (udeb) usb-modules-2.6.15-1-itanium-smp-di - USB support (udeb) usb-storage-modules-2.6.15-1-itanium-smp-di - USB storage support (udeb) xfs-modules-2.6.15-1-itanium-smp-di - XFS filesystem support (udeb) Changes: linux-kernel-di-ia64-2.6 (1.6) unstable; urgency=low . * Updated to 2.6.15 (2.6.15-7) Files: d0ccd877fa74e870926183e6cba7af22 2015 debian-installer optional linux-kernel-di-ia64-2.6_1.6.dsc 5e7b1f576cf15267449c99b2fb1cad30 6752 debian-installer optional linux-kernel-di-ia64-2.6_1.6.tar.gz e3c3d477a9423cd44f18c4b66853ebf0 2758112 debian-installer extra kernel-image-2.6.15-1-itanium-smp-di_1.6_ia64.udeb 4edd8fb8e1af7ca25f47f844da4d3705 1862596 debian-installer standard nic-modules-2.6.15-1-itanium-smp-di_1.6_ia64.udeb 09ab79e9038526d1fcc82cf10bcc6d95 17106 debian-installer standard nic-shared-modules-2.6.15-1-itanium-smp-di_1.6_ia64.udeb 876062f3f99219a96bd7b673c1a62067 37930 debian-installer optional serial-modules-2.6.15-1-itanium-smp-di_1.6_ia64.udeb
Accepted openrpg 1.6.3-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 19 Jan 2006 14:29:13 +0100 Source: openrpg Binary: openrpg Architecture: source all Version: 1.6.3-1 Distribution: unstable Urgency: low Maintainer: Isaac Clerencia [EMAIL PROTECTED] Changed-By: Isaac Clerencia [EMAIL PROTECTED] Description: openrpg- client/server application to play RPG over the Internet Changes: openrpg (1.6.3-1) unstable; urgency=low . * New upstream version * Switch patch management to quilt * Depend on libwxgtk2.6-python in addition to 2.4 version Files: d4b11020221598c564cb5d0e41b6ef24 620 games optional openrpg_1.6.3-1.dsc baf453f3791bc13cb4b2d49f799a5be4 747871 games optional openrpg_1.6.3.orig.tar.gz 54246b4c74347abef2f277e5a0252272 4982 games optional openrpg_1.6.3-1.diff.gz 7319d1530fff80193c4dbbe360b6eaef 745502 games optional openrpg_1.6.3-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Signed by Isaac Clerencia [EMAIL PROTECTED] iD8DBQFD/sOgQET2GFTmct4RAmXLAJ9yiB5VzqO5cUggG9/4WssNFOq31wCgkH/+ TPJd1wey1k/fr0rpkcwDgi0= =bnzr -END PGP SIGNATURE- Accepted: openrpg_1.6.3-1.diff.gz to pool/main/o/openrpg/openrpg_1.6.3-1.diff.gz openrpg_1.6.3-1.dsc to pool/main/o/openrpg/openrpg_1.6.3-1.dsc openrpg_1.6.3-1_all.deb to pool/main/o/openrpg/openrpg_1.6.3-1_all.deb openrpg_1.6.3.orig.tar.gz to pool/main/o/openrpg/openrpg_1.6.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted glark 1.7.7-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 24 Feb 2006 09:30:51 +0100 Source: glark Binary: glark Architecture: source all Version: 1.7.7-1 Distribution: unstable Urgency: low Maintainer: Michael Ablassmeier [EMAIL PROTECTED] Changed-By: Michael Ablassmeier [EMAIL PROTECTED] Description: glark - pattern matching tool similar to grep Changes: glark (1.7.7-1) unstable; urgency=low . * New upstream release Files: 2f39e09721e999f1713c0817a3619566 587 utils optional glark_1.7.7-1.dsc 7eab18d91f562b9284b8de27b3933ae9 34788 utils optional glark_1.7.7.orig.tar.gz f99820676da23f6136a65ba15c33e16f 2432 utils optional glark_1.7.7-1.diff.gz ccaaa3ea12332b4132ae8eaa94bfc549 34684 utils optional glark_1.7.7-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/sSbEFV7g4B8rCURApybAJ0RI3Y1H2cSHkOmq//fzQjSZdp/cwCggKnn robsoBJUGZNHz8FwVnSvrns= =Ve6E -END PGP SIGNATURE- Accepted: glark_1.7.7-1.diff.gz to pool/main/g/glark/glark_1.7.7-1.diff.gz glark_1.7.7-1.dsc to pool/main/g/glark/glark_1.7.7-1.dsc glark_1.7.7-1_all.deb to pool/main/g/glark/glark_1.7.7-1_all.deb glark_1.7.7.orig.tar.gz to pool/main/g/glark/glark_1.7.7.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted workrave 1.8.2-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 24 Feb 2006 09:21:00 +0100 Source: workrave Binary: workrave Architecture: source i386 Version: 1.8.2-1 Distribution: unstable Urgency: low Maintainer: Michael Piefel [EMAIL PROTECTED] Changed-By: Michael Piefel [EMAIL PROTECTED] Description: workrave - RSI prevention tool Closes: 353950 Changes: workrave (1.8.2-1) unstable; urgency=low . * New upstream (closes: #353950) Files: f7f3431ca438ee9677daa14bd90bbeb6 678 gnome optional workrave_1.8.2-1.dsc 0d4799ed3a250b1990e1ba0225348e8d 1563111 gnome optional workrave_1.8.2.orig.tar.gz 4e03264aed6d4ba7601650d305b1236d 4678 gnome optional workrave_1.8.2-1.diff.gz 8f05b3210df2981a90faa211db67ff6b 806456 gnome optional workrave_1.8.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/skV5GwONXmN2VwRAseAAKCC0nBID5ORRO7JmdHCrbOL74s2OwCfdHxY YoHsNhKJYm0CS7xFAbTh4RA= =kZxp -END PGP SIGNATURE- Accepted: workrave_1.8.2-1.diff.gz to pool/main/w/workrave/workrave_1.8.2-1.diff.gz workrave_1.8.2-1.dsc to pool/main/w/workrave/workrave_1.8.2-1.dsc workrave_1.8.2-1_i386.deb to pool/main/w/workrave/workrave_1.8.2-1_i386.deb workrave_1.8.2.orig.tar.gz to pool/main/w/workrave/workrave_1.8.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libhttp-request-ascgi-perl 0.5-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 23 Jan 2006 10:52:34 +0100 Source: libhttp-request-ascgi-perl Binary: libhttp-request-ascgi-perl Architecture: source all Version: 0.5-1 Distribution: unstable Urgency: low Maintainer: Debian Catalyst Maintainers [EMAIL PROTECTED] Changed-By: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] Description: libhttp-request-ascgi-perl - Setup a CGI enviroment from a HTTP::Request Changes: libhttp-request-ascgi-perl (0.5-1) unstable; urgency=low . * New upstream release * debian/control - Narrowed dependency from libwww-perl to (= 5.805) Files: 24be6fe53bbaca7dad770d45ac36ba83 818 perl optional libhttp-request-ascgi-perl_0.5-1.dsc e1f5d332969d072a19d9649ed7d77f59 6145 perl optional libhttp-request-ascgi-perl_0.5.orig.tar.gz fd045d33a90c9ed9a7b3dbbe32b58169 2027 perl optional libhttp-request-ascgi-perl_0.5-1.diff.gz 14e096a0b0066c8ed54c76a3a73e99c5 9628 perl optional libhttp-request-ascgi-perl_0.5-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/soM+NMfSd6w7DERAhMTAJ9MKEUOXlQCs7SWkEoAp86tx/RkWQCeI7Kb ICcpHEvRm1WJGZ0ZDQ+BB4o= =La3b -END PGP SIGNATURE- Accepted: libhttp-request-ascgi-perl_0.5-1.diff.gz to pool/main/libh/libhttp-request-ascgi-perl/libhttp-request-ascgi-perl_0.5-1.diff.gz libhttp-request-ascgi-perl_0.5-1.dsc to pool/main/libh/libhttp-request-ascgi-perl/libhttp-request-ascgi-perl_0.5-1.dsc libhttp-request-ascgi-perl_0.5-1_all.deb to pool/main/libh/libhttp-request-ascgi-perl/libhttp-request-ascgi-perl_0.5-1_all.deb libhttp-request-ascgi-perl_0.5.orig.tar.gz to pool/main/libh/libhttp-request-ascgi-perl/libhttp-request-ascgi-perl_0.5.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted shorewall 3.0.5-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 24 Feb 2006 09:59:08 +0100 Source: shorewall Binary: shorewall Architecture: source all Version: 3.0.5-1 Distribution: unstable Urgency: low Maintainer: Lorenzo Martignoni [EMAIL PROTECTED] Changed-By: Lorenzo Martignoni [EMAIL PROTECTED] Description: shorewall - Shoreline Firewall (Shorewall), a high-level tool for configuring Closes: 347578 348242 Changes: shorewall (3.0.5-1) unstable; urgency=low . * New upstream release * Updated the package description in debian/control (revised by upstream author) * Added debconf swedish translations (Closes: #347578) * The postrm script has been updated in order to remove /etc/shorewall/tcstart if it is an empty file, as it is not marked as a 'conffiles'. This file was created by the postinst script in order to avoid problems during upgrades from 2.4.X to 3.0.X (Closes: #348242) Files: 99471f6608ee411c9d7274d6566bbbfe 605 net optional shorewall_3.0.5-1.dsc 0644a910af6dfc43970360f34eeb4819 192819 net optional shorewall_3.0.5.orig.tar.gz 86fc827594af3e9b26da079f4f9fc720 42516 net optional shorewall_3.0.5-1.diff.gz f8d43321afe27f9308fc17dfc8eac2cc 221732 net optional shorewall_3.0.5-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/szZbFctcIsUOXURArlYAKCNWEXcVEUiV0+8EdJXXFTSp5WAuQCdFZUX Bh0mvVAWheC9vtIS3bO1KBA= =Zyff -END PGP SIGNATURE- Accepted: shorewall_3.0.5-1.diff.gz to pool/main/s/shorewall/shorewall_3.0.5-1.diff.gz shorewall_3.0.5-1.dsc to pool/main/s/shorewall/shorewall_3.0.5-1.dsc shorewall_3.0.5-1_all.deb to pool/main/s/shorewall/shorewall_3.0.5-1_all.deb shorewall_3.0.5.orig.tar.gz to pool/main/s/shorewall/shorewall_3.0.5.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted nut 2.0.3-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 24 Feb 2006 10:05:25 +0100 Source: nut Binary: nut nut-usb nut-dev nut-snmp nut-cgi Architecture: source i386 Version: 2.0.3-2 Distribution: unstable Urgency: low Maintainer: Arnaud Quette [EMAIL PROTECTED] Changed-By: Arnaud Quette [EMAIL PROTECTED] Description: nut- The core system of the nut - Network UPS Tools nut-cgi- A web interface sub system for the nut - Network UPS Tools nut-dev- Development files for the nut - Network UPS Tools nut-snmp - A meta SNMP Driver subsystem for the nut - Network UPS Tools nut-usb- USB Drivers subsystem for the nut - Network UPS Tools Closes: 319395 Changes: nut (2.0.3-2) unstable; urgency=low . * debian/nut.init: fix the creation of the PID directory, as /var is now volative. This bug has been identified in Ubuntu (Launchpad #6679) * debian/nut-cgi.postrm: suppress the deletion of the nut user as it's not needed (closes: #319395) * debian/nut-cgi.preinst: suppress that file as we do not need to check and create the nut user and group for nut-cgi * debian/nut-cgi.postinst: enhanced to ensure the /etc/nut directory and nut-cgi configuration files are readable by others * debian/nut-cgi.README.Debian: improve the documentation about configuration files permissions Files: 46612bc984085c952a6bec64ecc3e6bf 769 admin optional nut_2.0.3-2.dsc 991e55d91e04b452237b8d371dcbc64f 43534 admin optional nut_2.0.3-2.diff.gz 402a380a018464002633fcf17eea6a3b 972906 admin optional nut_2.0.3-2_i386.deb e8719e6e09338fde42c854258eb40998 98242 admin optional nut-cgi_2.0.3-2_i386.deb 817ae4df7f8c28e5dc0273863f223e80 79182 admin optional nut-snmp_2.0.3-2_i386.deb 92293029fff2c234917bc7d316a40f3e 180364 admin optional nut-usb_2.0.3-2_i386.deb a080f1654466d8c5a49c475f7dd10aee 84692 admin optional nut-dev_2.0.3-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/svF22QUyiBN3xsRAmqbAJ493XU/GXYRFdunl4by1EMxLrXnRACbBmeZ fZWzx3Q61vbdgMHEvFamgDk= =H0aj -END PGP SIGNATURE- Accepted: nut-cgi_2.0.3-2_i386.deb to pool/main/n/nut/nut-cgi_2.0.3-2_i386.deb nut-dev_2.0.3-2_i386.deb to pool/main/n/nut/nut-dev_2.0.3-2_i386.deb nut-snmp_2.0.3-2_i386.deb to pool/main/n/nut/nut-snmp_2.0.3-2_i386.deb nut-usb_2.0.3-2_i386.deb to pool/main/n/nut/nut-usb_2.0.3-2_i386.deb nut_2.0.3-2.diff.gz to pool/main/n/nut/nut_2.0.3-2.diff.gz nut_2.0.3-2.dsc to pool/main/n/nut/nut_2.0.3-2.dsc nut_2.0.3-2_i386.deb to pool/main/n/nut/nut_2.0.3-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted shorewall-doc 3.0.5 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 24 Feb 2006 10:11:27 +0100 Source: shorewall-doc Binary: shorewall-doc Architecture: source all Version: 3.0.5 Distribution: unstable Urgency: low Maintainer: Lorenzo Martignoni [EMAIL PROTECTED] Changed-By: Lorenzo Martignoni [EMAIL PROTECTED] Description: shorewall-doc - documentation for Shorewall firewall Changes: shorewall-doc (3.0.5) unstable; urgency=low . * New upstream release Files: 66ff33277208359096dd90cea95c2b1d 525 net optional shorewall-doc_3.0.5.dsc 91afa597a2822068b13a7c554e67a960 3346201 net optional shorewall-doc_3.0.5.tar.gz f339ed9977ce7885e837481eb528dd27 3347638 net optional shorewall-doc_3.0.5_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/s8fbFctcIsUOXURAggPAJ9elmh2BGLToEC66Y4sf+NLjz6LaACgrjgM l8a7sxipJFYaVZlYQiwk/y4= =Ftmh -END PGP SIGNATURE- Accepted: shorewall-doc_3.0.5.dsc to pool/main/s/shorewall-doc/shorewall-doc_3.0.5.dsc shorewall-doc_3.0.5.tar.gz to pool/main/s/shorewall-doc/shorewall-doc_3.0.5.tar.gz shorewall-doc_3.0.5_all.deb to pool/main/s/shorewall-doc/shorewall-doc_3.0.5_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libcatalyst-perl 5.65-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 23 Feb 2006 11:14:20 +0100 Source: libcatalyst-perl Binary: libcatalyst-perl Architecture: source all Version: 5.65-1 Distribution: unstable Urgency: low Maintainer: Debian Catalyst Maintainers [EMAIL PROTECTED] Changed-By: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] Description: libcatalyst-perl - The Elegant MVC Web Application Framework Changes: libcatalyst-perl (5.65-1) unstable; urgency=low . * New upstream release * debian/control - Narrowed dependency from libhttp-request-ascgi-perl to (= 0.5) Files: c1e542cd3739badce7020d081bdcc174 1413 perl optional libcatalyst-perl_5.65-1.dsc 925a79c7ac9d182870015e3a8af7f908 199356 perl optional libcatalyst-perl_5.65.orig.tar.gz 0afff812a60befc841d86ad96a2b4e2b 3174 perl optional libcatalyst-perl_5.65-1.diff.gz 6f79f006c65a88310deeeb26e7b6a38f 311810 perl optional libcatalyst-perl_5.65-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/sww+NMfSd6w7DERArZSAJ93bXjydrSRuJyWUh0IEc+VUQLSSQCeJI4H 6k975pygaewbjNfBCuwR3XU= =gur+ -END PGP SIGNATURE- Accepted: libcatalyst-perl_5.65-1.diff.gz to pool/main/libc/libcatalyst-perl/libcatalyst-perl_5.65-1.diff.gz libcatalyst-perl_5.65-1.dsc to pool/main/libc/libcatalyst-perl/libcatalyst-perl_5.65-1.dsc libcatalyst-perl_5.65-1_all.deb to pool/main/libc/libcatalyst-perl/libcatalyst-perl_5.65-1_all.deb libcatalyst-perl_5.65.orig.tar.gz to pool/main/libc/libcatalyst-perl/libcatalyst-perl_5.65.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted linux-kernel-di-powerpc-2.6 1.10 (source powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 24 Feb 2006 09:29:13 + Source: linux-kernel-di-powerpc-2.6 Binary: hfs-modules-2.6.15-1-powerpc-miboot-di scsi-core-modules-2.6.15-1-powerpc-di cdrom-core-modules-2.6.15-1-powerpc-miboot-di pcmcia-storage-modules-2.6.15-1-powerpc64-di nic-extra-modules-2.6.15-1-powerpc-di usb-modules-2.6.15-1-powerpc64-di usb-storage-modules-2.6.15-1-powerpc64-di serial-modules-2.6.15-1-powerpc-di loop-modules-2.6.15-1-powerpc64-di nic-shared-modules-2.6.15-1-powerpc-di nic-modules-2.6.15-1-powerpc64-di md-modules-2.6.15-1-powerpc-miboot-di nic-shared-modules-2.6.15-1-powerpc-miboot-di firewire-core-modules-2.6.15-1-powerpc64-di hfs-modules-2.6.15-1-powerpc-di scsi-modules-2.6.15-1-powerpc-miboot-di hypervisor-modules-2.6.15-1-powerpc64-di irda-modules-2.6.15-1-powerpc-miboot-di fat-modules-2.6.15-1-powerpc-miboot-di input-modules-2.6.15-1-powerpc-di fat-modules-2.6.15-1-powerpc64-di ide-modules-2.6.15-1-powerpc-miboot-di ext2-modules-2.6.15-1-powerpc64-di floppy-modules-2.6.15-1-powerpc64-di ppp-modules-2.6.15-1-powerpc64-di ide-modules-2.6.15-1-powerpc64-di usb-modules-2.6.15-1-powerpc-di kernel-image-2.6.15-1-powerpc-miboot-di pcmcia-modules-2.6.15-1-powerpc-miboot-di affs-modules-2.6.15-1-powerpc-miboot-di fs-common-modules-2.6.15-1-powerpc-di ufs-modules-2.6.15-1-powerpc-miboot-di ipv6-modules-2.6.15-1-powerpc-di xfs-modules-2.6.15-1-powerpc-miboot-di md-modules-2.6.15-1-powerpc64-di scsi-core-modules-2.6.15-1-powerpc64-di firmware-modules-2.6.15-1-powerpc64-di mouse-modules-2.6.15-1-powerpc-di ipv6-modules-2.6.15-1-powerpc64-di jfs-modules-2.6.15-1-powerpc-di floppy-modules-2.6.15-1-powerpc-miboot-di scsi-common-modules-2.6.15-1-powerpc-miboot-di floppy-modules-2.6.15-1-powerpc-di firmware-modules-2.6.15-1-powerpc-miboot-di kernel-image-2.6.15-1-powerpc-di usb-storage-modules-2.6.15-1-powerpc-miboot-di nic-pcmcia-modules-2.6.15-1-powerpc-miboot-di scsi-extra-modules-2.6.15-1-powerpc-miboot-di reiserfs-modules-2.6.15-1-powerpc64-di cdrom-core-modules-2.6.15-1-powerpc64-di loop-modules-2.6.15-1-powerpc-miboot-di jfs-modules-2.6.15-1-powerpc64-di scsi-common-modules-2.6.15-1-powerpc-di serial-modules-2.6.15-1-powerpc64-di ppp-modules-2.6.15-1-powerpc-di pcmcia-modules-2.6.15-1-powerpc64-di xfs-modules-2.6.15-1-powerpc-di hfs-modules-2.6.15-1-powerpc64-di affs-modules-2.6.15-1-powerpc-di firewire-core-modules-2.6.15-1-powerpc-miboot-di input-modules-2.6.15-1-powerpc64-di scsi-common-modules-2.6.15-1-powerpc64-di nic-shared-modules-2.6.15-1-powerpc64-di firewire-core-modules-2.6.15-1-powerpc-di usb-storage-modules-2.6.15-1-powerpc-di nic-extra-modules-2.6.15-1-powerpc64-di fs-common-modules-2.6.15-1-powerpc64-di fat-modules-2.6.15-1-powerpc-di sata-modules-2.6.15-1-powerpc64-di scsi-modules-2.6.15-1-powerpc64-di pcmcia-storage-modules-2.6.15-1-powerpc-miboot-di scsi-modules-2.6.15-1-powerpc-di ext2-modules-2.6.15-1-powerpc-di loop-modules-2.6.15-1-powerpc-di irda-modules-2.6.15-1-powerpc64-di md-modules-2.6.15-1-powerpc-di usb-modules-2.6.15-1-powerpc-miboot-di ext3-modules-2.6.15-1-powerpc-di nic-extra-modules-2.6.15-1-powerpc-miboot-di nic-modules-2.6.15-1-powerpc-miboot-di reiserfs-modules-2.6.15-1-powerpc-di scsi-core-modules-2.6.15-1-powerpc-miboot-di xfs-modules-2.6.15-1-powerpc64-di fs-common-modules-2.6.15-1-powerpc-miboot-di irda-modules-2.6.15-1-powerpc-di ext3-modules-2.6.15-1-powerpc64-di jfs-modules-2.6.15-1-powerpc-miboot-di nic-pcmcia-modules-2.6.15-1-powerpc-di ide-modules-2.6.15-1-powerpc-di ppp-modules-2.6.15-1-powerpc-miboot-di ufs-modules-2.6.15-1-powerpc-di ext2-modules-2.6.15-1-powerpc-miboot-di nic-pcmcia-modules-2.6.15-1-powerpc64-di cdrom-core-modules-2.6.15-1-powerpc-di scsi-extra-modules-2.6.15-1-powerpc-di pcmcia-modules-2.6.15-1-powerpc-di kernel-image-2.6.15-1-powerpc64-di nic-modules-2.6.15-1-powerpc-di ufs-modules-2.6.15-1-powerpc64-di serial-modules-2.6.15-1-powerpc-miboot-di ipv6-modules-2.6.15-1-powerpc-miboot-di affs-modules-2.6.15-1-powerpc64-di sata-modules-2.6.15-1-powerpc-di scsi-extra-modules-2.6.15-1-powerpc64-di reiserfs-modules-2.6.15-1-powerpc-miboot-di pcmcia-storage-modules-2.6.15-1-powerpc-di input-modules-2.6.15-1-powerpc-miboot-di ext3-modules-2.6.15-1-powerpc-miboot-di sata-modules-2.6.15-1-powerpc-miboot-di mouse-modules-2.6.15-1-powerpc-miboot-di firmware-modules-2.6.15-1-powerpc-di mouse-modules-2.6.15-1-powerpc64-di Architecture: source powerpc Version: 1.10 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Colin Watson [EMAIL PROTECTED] Description: affs-modules-2.6.15-1-powerpc-di - Amiga filesystem support (udeb) affs-modules-2.6.15-1-powerpc-miboot-di - Amiga filesystem support (udeb) affs-modules-2.6.15-1-powerpc64-di - Amiga filesystem support (udeb) cdrom-core-modules-2.6.15-1-powerpc-di - CDROM support (udeb)
Accepted ttf-sazanami 0.0.1.20040629-3 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 11 Jun 2005 11:41:36 +0900 Source: ttf-sazanami Binary: ttf-sazanami-mincho ttf-sazanami-gothic Architecture: source all Version: 0.0.1.20040629-3 Distribution: unstable Urgency: low Maintainer: GOTO Masanori [EMAIL PROTECTED] Changed-By: GOTO Masanori [EMAIL PROTECTED] Description: ttf-sazanami-gothic - Sazanami Gothic Japanese TrueType font ttf-sazanami-mincho - Sazanami Mincho Japanese TrueType font Closes: 338247 348962 Changes: ttf-sazanami (0.0.1.20040629-3) unstable; urgency=low . * debian/defoma/*.hints: Change Width = Variable, and X-Spacing = c m p, for the recent xlibs-data changes. * debian/control: Suggests xserver-xorg instead of xserver-xfree86. (Closes: #338247) * debian/control: Remove dependency to xutils. (Closes: #348962) Files: 83a3d49c706bd7f02ed306be51da8708 650 x11 optional ttf-sazanami_0.0.1.20040629-3.dsc 7036fcc1b320d434195586f74494df47 10126 x11 optional ttf-sazanami_0.0.1.20040629-3.diff.gz 2462a744ad3bcb83da6665756afdf60e 5847550 x11 optional ttf-sazanami-mincho_0.0.1.20040629-3_all.deb 630ca443d3a2160d81e256568d5c172a 4589058 x11 optional ttf-sazanami-gothic_0.0.1.20040629-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/tSyqIqasIZIJsMRAhiFAJ0blUjZSLgQaqdwVMH1UtFqi0zZOgCfVl9V eyDP9UR4H1BWppbPGOFCVZ0= =Ypk5 -END PGP SIGNATURE- Accepted: ttf-sazanami-gothic_0.0.1.20040629-3_all.deb to pool/main/t/ttf-sazanami/ttf-sazanami-gothic_0.0.1.20040629-3_all.deb ttf-sazanami-mincho_0.0.1.20040629-3_all.deb to pool/main/t/ttf-sazanami/ttf-sazanami-mincho_0.0.1.20040629-3_all.deb ttf-sazanami_0.0.1.20040629-3.diff.gz to pool/main/t/ttf-sazanami/ttf-sazanami_0.0.1.20040629-3.diff.gz ttf-sazanami_0.0.1.20040629-3.dsc to pool/main/t/ttf-sazanami/ttf-sazanami_0.0.1.20040629-3.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libmail-spf-query-perl 1:1.999-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 24 Feb 2006 11:06:27 +0100 Source: libmail-spf-query-perl Binary: libmail-spf-query-perl Architecture: source all Version: 1:1.999-2 Distribution: unstable Urgency: low Maintainer: Debian Perl Group [EMAIL PROTECTED] Changed-By: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] Description: libmail-spf-query-perl - query SPF (Sender Policy Framework) to validate mail senders Changes: libmail-spf-query-perl (1:1.999-2) unstable; urgency=low . * Just increase version without changes. Full source upload. Files: e5efbe7e911e68674d6ef6b4d5d34b30 889 perl optional libmail-spf-query-perl_1.999-2.dsc 7d5e7a0141bd3160234585e78e68819e 54874 perl optional libmail-spf-query-perl_1.999.orig.tar.gz ffd3d96f576fa36fc155887b29b104a2 1261 perl optional libmail-spf-query-perl_1.999-2.diff.gz bfaf17a9787ccfe042d7f280b3f12d04 70748 perl optional libmail-spf-query-perl_1.999-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/tut+NMfSd6w7DERAnlQAJ9Zbk2VtP6qsrT2UVKkJOCDM9+U8ACgmBD+ bZfhZadxX/yZVxcUVDW1Xas= =bVpL -END PGP SIGNATURE- Accepted: libmail-spf-query-perl_1.999-2.diff.gz to pool/main/libm/libmail-spf-query-perl/libmail-spf-query-perl_1.999-2.diff.gz libmail-spf-query-perl_1.999-2.dsc to pool/main/libm/libmail-spf-query-perl/libmail-spf-query-perl_1.999-2.dsc libmail-spf-query-perl_1.999-2_all.deb to pool/main/libm/libmail-spf-query-perl/libmail-spf-query-perl_1.999-2_all.deb libmail-spf-query-perl_1.999.orig.tar.gz to pool/main/libm/libmail-spf-query-perl/libmail-spf-query-perl_1.999.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted linux-kernel-di-arm-2.6 0.4 (source arm)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 24 Feb 2006 10:02:32 + Source: linux-kernel-di-arm-2.6 Binary: cdrom-core-modules-2.6.15-1-s3c2410-di ide-modules-2.6.15-1-footbridge-di nic-modules-2.6.15-1-footbridge-di md-modules-2.6.15-1-nslu2-di kernel-image-2.6.15-1-nslu2-di crc-modules-2.6.15-1-footbridge-di nic-shared-modules-2.6.15-1-footbridge-di fat-modules-2.6.15-1-nslu2-di cdrom-core-modules-2.6.15-1-footbridge-di usb-modules-2.6.15-1-footbridge-di ext3-modules-2.6.15-1-nslu2-di fat-modules-2.6.15-1-footbridge-di usb-storage-modules-2.6.15-1-footbridge-di scsi-core-modules-2.6.15-1-footbridge-di loop-modules-2.6.15-1-footbridge-di md-modules-2.6.15-1-footbridge-di reiserfs-modules-2.6.15-1-nslu2-di reiserfs-modules-2.6.15-1-footbridge-di nic-usb-modules-2.6.15-1-nslu2-di usb-storage-modules-2.6.15-1-nslu2-di kernel-image-2.6.15-1-footbridge-di kernel-image-2.6.15-1-s3c2410-di usb-modules-2.6.15-1-nslu2-di scsi-core-modules-2.6.15-1-nslu2-di Architecture: source arm Version: 0.4 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.6.15-1-footbridge-di - CDROM support (udeb) cdrom-core-modules-2.6.15-1-s3c2410-di - CDROM support (udeb) crc-modules-2.6.15-1-footbridge-di - CRC modules (udeb) ext3-modules-2.6.15-1-nslu2-di - EXT3 filesystem support (udeb) fat-modules-2.6.15-1-footbridge-di - FAT filesystem support (udeb) fat-modules-2.6.15-1-nslu2-di - FAT filesystem support (udeb) ide-modules-2.6.15-1-footbridge-di - IDE drivers (udeb) kernel-image-2.6.15-1-footbridge-di - Linux kernel binary image for the Debian installer (udeb) kernel-image-2.6.15-1-nslu2-di - Linux kernel binary image for the Debian installer (udeb) kernel-image-2.6.15-1-s3c2410-di - Linux kernel binary image for the Debian installer (udeb) loop-modules-2.6.15-1-footbridge-di - Loopback filesystem support (udeb) md-modules-2.6.15-1-footbridge-di - RAID and LVM support (udeb) md-modules-2.6.15-1-nslu2-di - RAID and LVM support (udeb) nic-modules-2.6.15-1-footbridge-di - Common NIC drivers (udeb) nic-shared-modules-2.6.15-1-footbridge-di - Shared NIC drivers (udeb) nic-usb-modules-2.6.15-1-nslu2-di - USB NIC drivers (udeb) reiserfs-modules-2.6.15-1-footbridge-di - Reiser filesystem support (udeb) reiserfs-modules-2.6.15-1-nslu2-di - Reiser filesystem support (udeb) scsi-core-modules-2.6.15-1-footbridge-di - Core SCSI subsystem (udeb) scsi-core-modules-2.6.15-1-nslu2-di - Core SCSI subsystem (udeb) usb-modules-2.6.15-1-footbridge-di - USB support (udeb) usb-modules-2.6.15-1-nslu2-di - USB support (udeb) usb-storage-modules-2.6.15-1-footbridge-di - USB storage support (udeb) usb-storage-modules-2.6.15-1-nslu2-di - USB storage support (udeb) Changes: linux-kernel-di-arm-2.6 (0.4) unstable; urgency=low . [ Martin Michlmayr ] * Rebuilt with 2.6.15-7. Files: e9be0a0bfe75723edeec92a103f2bfde 1611 debian-installer optional linux-kernel-di-arm-2.6_0.4.dsc ac0a4fb1ce7ef35ed7aa1e555f94a8c9 2839 debian-installer optional linux-kernel-di-arm-2.6_0.4.tar.gz cbb86811ab8fa577f3c5d7d2e450bdac 1474108 debian-installer extra kernel-image-2.6.15-1-footbridge-di_0.4_arm.udeb 90dbb289ccb847add6f231dd685d5391 30028 debian-installer standard nic-modules-2.6.15-1-footbridge-di_0.4_arm.udeb 3171cb847f77d7a139a602d2ca76aac0 6180 debian-installer standard nic-shared-modules-2.6.15-1-footbridge-di_0.4_arm.udeb f222e8a4cf7c6a8b1854fd27cf9daf84 79706 debian-installer standard ide-modules-2.6.15-1-footbridge-di_0.4_arm.udeb 92f077833234e0797142dc7d3b5790e6 27750 debian-installer standard cdrom-core-modules-2.6.15-1-footbridge-di_0.4_arm.udeb 9b7b8dbd2b76e8b2818226ea918c2ca2 71858 debian-installer standard scsi-core-modules-2.6.15-1-footbridge-di_0.4_arm.udeb fb27025e07576b1489f7544102fc630d 9202 debian-installer standard loop-modules-2.6.15-1-footbridge-di_0.4_arm.udeb d43a927c3bdb267ae4b28126873a18c2 123044 debian-installer standard reiserfs-modules-2.6.15-1-footbridge-di_0.4_arm.udeb 6fd09a41f1b5077fa8e9203a80a0416d 34902 debian-installer extra fat-modules-2.6.15-1-footbridge-di_0.4_arm.udeb 026ba6ba2a326aef694d1fc3e0140a0e 112218 debian-installer extra md-modules-2.6.15-1-footbridge-di_0.4_arm.udeb 0ea2fc2b42eabe8bc308154c1773413f 118740 debian-installer extra usb-modules-2.6.15-1-footbridge-di_0.4_arm.udeb 02d0ee4a8438f8450cdab0bf174ed0d2 37382 debian-installer standard usb-storage-modules-2.6.15-1-footbridge-di_0.4_arm.udeb 7c7c130c325bb74611c9af984ac57280 2294 debian-installer extra crc-modules-2.6.15-1-footbridge-di_0.4_arm.udeb 7a0cf3637df7e5fc0accc64c978994e8 1142092 debian-installer extra kernel-image-2.6.15-1-nslu2-di_0.4_arm.udeb 173cad0e18b8f8b070096bd3b3614cfd 55630 debian-installer standard scsi-core-modules-2.6.15-1-nslu2-di_0.4_arm.udeb 99f9d31f321566b555f46056fbf4a263 94748 debian-installer standard
Accepted tora 1.3.21-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 13 Feb 2006 15:02:29 +0100 Source: tora Binary: tora Architecture: source i386 Version: 1.3.21-1 Distribution: unstable Urgency: low Maintainer: Michael Meskes [EMAIL PROTECTED] Changed-By: Michael Meskes [EMAIL PROTECTED] Description: tora - A graphical toolkit for database developers and administrators Changes: tora (1.3.21-1) unstable; urgency=low . * New upstream version, fixing the bug that urged me to call autogen.sh and thus making the package build again without build-depending on automake et al., closes #352513 * Added most of the debian specific patch to upstream sources. Files: 4658af9e0a28dfc4222c557187906802 700 misc optional tora_1.3.21-1.dsc 0327fe08f252b73b3e3038ef63539b4f 3140764 misc optional tora_1.3.21.orig.tar.gz ef8de64164f594bc9adb25c5c5226e31 396 misc optional tora_1.3.21-1.diff.gz a8f5782e1e2aa9de3c24bb235a34df97 5578650 misc optional tora_1.3.21-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/ts6VkEm8inxm9ERAmonAJ47PmmvmEb5NevrrOgy9xDP+V6Z8QCdFSyN qXDeIl79Xh4Owu4jLNFY0fA= =fFzU -END PGP SIGNATURE- Accepted: tora_1.3.21-1.diff.gz to pool/main/t/tora/tora_1.3.21-1.diff.gz tora_1.3.21-1.dsc to pool/main/t/tora/tora_1.3.21-1.dsc tora_1.3.21-1_i386.deb to pool/main/t/tora/tora_1.3.21-1_i386.deb tora_1.3.21.orig.tar.gz to pool/main/t/tora/tora_1.3.21.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gok 1.0.6-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 24 Feb 2006 11:10:02 +0100 Source: gok Binary: gok gok-doc Architecture: source i386 all Version: 1.0.6-1 Distribution: unstable Urgency: low Maintainer: J.H.M. Dassen (Ray) [EMAIL PROTECTED] Changed-By: J.H.M. Dassen (Ray) [EMAIL PROTECTED] Description: gok- GNOME Onscreen Keyboard gok-doc- documentation files for the GNOME Onscreen Keyboard Changes: gok (1.0.6-1) unstable; urgency=low . * New upstream release. * [debian/patches/001_gok-debian-libtool.patch] Updated. * [debian/patches/002_manual_title.patch] Dropped; fixed upstream. * [debian/patches/002_fixes-from-cvs.patch] Added. Selected fixes from upstream CVS, including one needed to be able to build with sid's libwnck. * [debian/watch] Updated. Files: ab2586fd8292a669ca80b82faad83bfe 1979 gnome optional gok_1.0.6-1.dsc f648b90a1653baf1999337736cc9a3c2 1861334 gnome optional gok_1.0.6.orig.tar.gz 282feb4e2776917dc9886c2f110e2660 108738 gnome optional gok_1.0.6-1.diff.gz 53708ab141ecaecbc8de4d04eb5d1301 188760 doc optional gok-doc_1.0.6-1_all.deb a7241d834e6f3a0ba3a137b620d829f5 1394788 gnome optional gok_1.0.6-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/uA4IwmOUm50p9ERAhdwAKC3Ya/LUdwWHTbT/wXyBCeFDCVvfwCgpCV7 nipFmGQgwFDDjoj14cIoa4I= =wECz -END PGP SIGNATURE- Accepted: gok-doc_1.0.6-1_all.deb to pool/main/g/gok/gok-doc_1.0.6-1_all.deb gok_1.0.6-1.diff.gz to pool/main/g/gok/gok_1.0.6-1.diff.gz gok_1.0.6-1.dsc to pool/main/g/gok/gok_1.0.6-1.dsc gok_1.0.6-1_i386.deb to pool/main/g/gok/gok_1.0.6-1_i386.deb gok_1.0.6.orig.tar.gz to pool/main/g/gok/gok_1.0.6.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xdaliclock 2.23-1 (source i386)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Fri, 24 Feb 2006 11:48:26 +0100
Source: xdaliclock
Binary: xdaliclock
Architecture: source i386
Version: 2.23-1
Distribution: unstable
Urgency: low
Maintainer: Florian Ernst [EMAIL PROTECTED]
Changed-By: Florian Ernst [EMAIL PROTECTED]
Description:
xdaliclock - Melting digital clock
Closes: 342434 346805 353390
Changes:
xdaliclock (2.23-1) unstable; urgency=low
.
* New maintainer (Closes: #353390)
+ minor packaging tweaking, including auto-update of config.{sub,guess}
+ fix changelog weirdness
+ update debhelper compatibility level and Standards-Version
* New upstream release
* Remove patch from 2.18-9 as it seems to cause problems, this will
supposedly fix #246572: xdaliclock freezes randomly
* Acknowledge previous NMU via -v2.20-1
.
xdaliclock (2.20-1.1) unstable; urgency=low
.
* Non-maintainer upload for xlibs-dev transition.
* Update debian/control to not build-depend on xlibs-dev. (Closes: #346805)
* Update config.{sub,guess} to fix FTBFS on k*BSD. (Closes: #342434)
Files:
7a3f19bc7358d003a780a6081ae864e9 625 x11 optional xdaliclock_2.23-1.dsc
b17f48eb2bddb8ca0a3dea57495e5381 651122 x11 optional
xdaliclock_2.23.orig.tar.gz
2b14504e5343d477a185b7628453b510 4090 x11 optional xdaliclock_2.23-1.diff.gz
ea5a791cdd8d5587b19050ac06d2808a 60656 x11 optional xdaliclock_2.23-1_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD/udJs3U+TVFLPnwRAkSiAJ9Em6tO+C+DNMDfHhvEjXRXFhhR9QCggmeJ
4+z0OC1ctGaUCZeMRinwK54=
=C7lS
-END PGP SIGNATURE-
Accepted:
xdaliclock_2.23-1.diff.gz
to pool/main/x/xdaliclock/xdaliclock_2.23-1.diff.gz
xdaliclock_2.23-1.dsc
to pool/main/x/xdaliclock/xdaliclock_2.23-1.dsc
xdaliclock_2.23-1_i386.deb
to pool/main/x/xdaliclock/xdaliclock_2.23-1_i386.deb
xdaliclock_2.23.orig.tar.gz
to pool/main/x/xdaliclock/xdaliclock_2.23.orig.tar.gz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted madwifi 0.svn20060207-2 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 23 Feb 2006 19:29:42 +1000 Source: madwifi Binary: madwifi-dev madwifi-tools madwifi-source Architecture: source i386 all Version: 0.svn20060207-2 Distribution: unstable Urgency: low Maintainer: Debian madwifi team [EMAIL PROTECTED] Changed-By: Kel Modderman [EMAIL PROTECTED] Description: madwifi-dev - includes for the Multiband Atheros Driver for WiFi madwifi-source - source for the Multiband Atheros Driver for WiFi madwifi-tools - tools for the Multiband Atheros Driver for WiFi Closes: 354000 Changes: madwifi (0.svn20060207-2) unstable; urgency=low . [ Kel Modderman ] * Conditional dependency of module-assistant OR kernel-package for madwifi-source, thanks Julien Valroff. (Closes: #354000) [debian/control] * Condense previous changelog entry. [debian/changelog] Files: 5d2f5831c9dfe07fc0ff3477f34375a8 830 non-free/net optional madwifi_0.svn20060207-2.dsc 6f98e8188ae535d05f24fd5825197498 28955 non-free/net optional madwifi_0.svn20060207-2.diff.gz 240cfbad840cc8923d47907e432acb9c 2002772 non-free/net optional madwifi-source_0.svn20060207-2_all.deb ee3d32fa7d5c14c699f2e2d2d51fe100 28778 non-free/net optional madwifi-dev_0.svn20060207-2_all.deb 0ea1a0090985b8edf4838905c6de49ed 35322 non-free/net optional madwifi-tools_0.svn20060207-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/ujz4VUX8isJIMARAl96AJ9cKhi/qCS+kp2r7XEl9PMFGz4hcQCeOHB9 tfLmeil0d4cSqwfUZeYfcfo= =+KrI -END PGP SIGNATURE- Accepted: madwifi-dev_0.svn20060207-2_all.deb to pool/non-free/m/madwifi/madwifi-dev_0.svn20060207-2_all.deb madwifi-source_0.svn20060207-2_all.deb to pool/non-free/m/madwifi/madwifi-source_0.svn20060207-2_all.deb madwifi-tools_0.svn20060207-2_i386.deb to pool/non-free/m/madwifi/madwifi-tools_0.svn20060207-2_i386.deb madwifi_0.svn20060207-2.diff.gz to pool/non-free/m/madwifi/madwifi_0.svn20060207-2.diff.gz madwifi_0.svn20060207-2.dsc to pool/non-free/m/madwifi/madwifi_0.svn20060207-2.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnome-user-share 0.9-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 23 Feb 2006 19:51:20 +0100 Source: gnome-user-share Binary: gnome-user-share Architecture: source i386 Version: 0.9-3 Distribution: unstable Urgency: low Maintainer: Sebastian Dröge [EMAIL PROTECTED] Changed-By: Sebastian Dröge [EMAIL PROTECTED] Description: gnome-user-share - User level public file sharing via Apache and WebDAV Closes: 353180 Changes: gnome-user-share (0.9-3) unstable; urgency=low . * Added debian/watch * Added README to the package and patch it to include informations about avahi and improve the language a bit (02_README.diff) (Closes: #353180) * Updated to debhelper compat version 5 Files: 79d4affc6bc27b94dfa4ee89e2ba692b 811 gnome optional gnome-user-share_0.9-3.dsc 5d2f1b79a5a85af2e73ccf1aada1a671 3004 gnome optional gnome-user-share_0.9-3.diff.gz b3b40bfbb176909d7b0a50957bfce4d2 31488 gnome optional gnome-user-share_0.9-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/uiF4VUX8isJIMARAp0ZAJ0Xxp48byUbFhEbuMEZfxS1GFyKzgCeNe5h m1r21OVrYoHXvv7bFPHnDlM= =9Anp -END PGP SIGNATURE- Accepted: gnome-user-share_0.9-3.diff.gz to pool/main/g/gnome-user-share/gnome-user-share_0.9-3.diff.gz gnome-user-share_0.9-3.dsc to pool/main/g/gnome-user-share/gnome-user-share_0.9-3.dsc gnome-user-share_0.9-3_i386.deb to pool/main/g/gnome-user-share/gnome-user-share_0.9-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sphinx2 0.6-2 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 24 Feb 2006 12:08:11 +0100 Source: sphinx2 Binary: libsphinx2g0 sphinx2-hmm-6k libsphinx2-dev sphinx2-bin Architecture: source all i386 Version: 0.6-2 Distribution: unstable Urgency: low Maintainer: Isaac Clerencia [EMAIL PROTECTED] Changed-By: Isaac Clerencia [EMAIL PROTECTED] Description: libsphinx2-dev - speech recognition library - development kit libsphinx2g0 - speech recognition library sphinx2-bin - speech recognition utilities sphinx2-hmm-6k - speech recognition library - default acoustic model Closes: 345092 Changes: sphinx2 (0.6-2) unstable; urgency=low . * Fix crash when displaying usage hint, closes: #345092 * Use quilt as patch management system Files: 535a6f57836c77b055bbc46b4581ae12 690 sound optional sphinx2_0.6-2.dsc 8697299cbef6c4c232b2aa5bb534a963 3859 sound optional sphinx2_0.6-2.diff.gz ace1f01e0290d0a38cf9abc1d9ff88e3 5971996 sound optional sphinx2-hmm-6k_0.6-2_all.deb c3663dd59befc62221b6e6ec8b72a2c0 144678 sound optional sphinx2-bin_0.6-2_i386.deb 093b191b4922258bc7af7b6b3f6c148c 268202 libs optional libsphinx2g0_0.6-2_i386.deb 1fae17a22b98f92aaa2f83fee151333e 325970 devel optional libsphinx2-dev_0.6-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Signed by Isaac Clerencia [EMAIL PROTECTED] iD8DBQFD/usAQET2GFTmct4RAqX8AJ9X7AtwwHeU5j7UXrBg06OAJT7O/ACgqSVz YHyNo6e6mOfjMUdnDxQ3lvs= =Pw1J -END PGP SIGNATURE- Accepted: libsphinx2-dev_0.6-2_i386.deb to pool/main/s/sphinx2/libsphinx2-dev_0.6-2_i386.deb libsphinx2g0_0.6-2_i386.deb to pool/main/s/sphinx2/libsphinx2g0_0.6-2_i386.deb sphinx2-bin_0.6-2_i386.deb to pool/main/s/sphinx2/sphinx2-bin_0.6-2_i386.deb sphinx2-hmm-6k_0.6-2_all.deb to pool/main/s/sphinx2/sphinx2-hmm-6k_0.6-2_all.deb sphinx2_0.6-2.diff.gz to pool/main/s/sphinx2/sphinx2_0.6-2.diff.gz sphinx2_0.6-2.dsc to pool/main/s/sphinx2/sphinx2_0.6-2.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ttf-kochi-naga10 1.0.20030809-4 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 6 Feb 2006 13:12:29 +0900 Source: ttf-kochi-naga10 Binary: ttf-kochi-mincho-naga10 ttf-kochi-gothic-naga10 Architecture: source all Version: 1.0.20030809-4 Distribution: unstable Urgency: low Maintainer: GOTO Masanori [EMAIL PROTECTED] Changed-By: GOTO Masanori [EMAIL PROTECTED] Description: ttf-kochi-gothic-naga10 - Kochi Subst Gothic Japanese TrueType font with naga10 (non-free) ttf-kochi-mincho-naga10 - Kochi Subst Mincho Japanese TrueType font with naga10 (non-free) Changes: ttf-kochi-naga10 (1.0.20030809-4) unstable; urgency=low . * debian/defoma/*.hints: Change Width = Variable, and X-Spacing = c m p, for the recent xlibs-data changes. * debian/control: Suggests xserver-xorg instead of xserver-xfree86, see #338251. * debian/control: Remove dependency to xutils, see #348962. Files: 0976eefd5d2180db23383e26452653a1 663 non-free/x11 optional ttf-kochi-naga10_1.0.20030809-4.dsc 896e912031cf699e4ddf0338f879f172 7265 non-free/x11 optional ttf-kochi-naga10_1.0.20030809-4.diff.gz 97acc3d789485f37eeb0c79a063a6422 5580594 non-free/x11 optional ttf-kochi-mincho-naga10_1.0.20030809-4_all.deb 8d77651f83e24d12d64289d0ef6b1559 4771502 non-free/x11 optional ttf-kochi-gothic-naga10_1.0.20030809-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/uTjqIqasIZIJsMRAqdgAJ9XRNx0x7iqwS7YrN8nUUTqXZZlMgCgie/Q 3XhiNFq4MF5MdmTrB0+tJ9s= =m7k2 -END PGP SIGNATURE- Accepted: ttf-kochi-gothic-naga10_1.0.20030809-4_all.deb to pool/non-free/t/ttf-kochi-naga10/ttf-kochi-gothic-naga10_1.0.20030809-4_all.deb ttf-kochi-mincho-naga10_1.0.20030809-4_all.deb to pool/non-free/t/ttf-kochi-naga10/ttf-kochi-mincho-naga10_1.0.20030809-4_all.deb ttf-kochi-naga10_1.0.20030809-4.diff.gz to pool/non-free/t/ttf-kochi-naga10/ttf-kochi-naga10_1.0.20030809-4.diff.gz ttf-kochi-naga10_1.0.20030809-4.dsc to pool/non-free/t/ttf-kochi-naga10/ttf-kochi-naga10_1.0.20030809-4.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ttf-kochi 1.0.20030809-4 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 6 Feb 2006 13:12:19 +0900 Source: ttf-kochi Binary: ttf-kochi-gothic ttf-kochi-mincho Architecture: source all Version: 1.0.20030809-4 Distribution: unstable Urgency: low Maintainer: GOTO Masanori [EMAIL PROTECTED] Changed-By: GOTO Masanori [EMAIL PROTECTED] Description: ttf-kochi-gothic - Kochi Subst Gothic Japanese TrueType font without naga10 ttf-kochi-mincho - Kochi Subst Mincho Japanese TrueType font without naga10 Closes: 338251 Changes: ttf-kochi (1.0.20030809-4) unstable; urgency=low . * debian/defoma/*.hints: Change Width = Variable, and X-Spacing = c m p, for the recent xlibs-data changes. * debian/control: Suggests xserver-xorg instead of xserver-xfree86. (Closes: #338251) * debian/control: Remove dependency to xutils, see #348962. Files: c18081c59c70dd0a7c2f287465f8f082 628 x11 optional ttf-kochi_1.0.20030809-4.dsc 5d3f016843b02766df69091621687e7d 6544 x11 optional ttf-kochi_1.0.20030809-4.diff.gz 2f79432e35af3a161093d4d7d6b503db 5382052 x11 optional ttf-kochi-mincho_1.0.20030809-4_all.deb 06906f868021b638fe49bd9b0b59a9cc 4576002 x11 optional ttf-kochi-gothic_1.0.20030809-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/uUPqIqasIZIJsMRAuS9AKCb3z9URG4DOnAoMq5+PFHTnCIIgQCfUNNa vuoPXb24n3iqXuvyEqOWNLQ= =RiVl -END PGP SIGNATURE- Accepted: ttf-kochi-gothic_1.0.20030809-4_all.deb to pool/main/t/ttf-kochi/ttf-kochi-gothic_1.0.20030809-4_all.deb ttf-kochi-mincho_1.0.20030809-4_all.deb to pool/main/t/ttf-kochi/ttf-kochi-mincho_1.0.20030809-4_all.deb ttf-kochi_1.0.20030809-4.diff.gz to pool/main/t/ttf-kochi/ttf-kochi_1.0.20030809-4.diff.gz ttf-kochi_1.0.20030809-4.dsc to pool/main/t/ttf-kochi/ttf-kochi_1.0.20030809-4.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xrsh 5.92-8 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 18 Feb 2006 10:59:10 +0100 Source: xrsh Binary: xrsh Architecture: source all Version: 5.92-8 Distribution: unstable Urgency: low Maintainer: Marc 'HE' Brockschmidt [EMAIL PROTECTED] Changed-By: Harald Dunkel [EMAIL PROTECTED] Description: xrsh - remote execution of XWindow programs Changes: xrsh (5.92-8) unstable; urgency=low . * fix lintian problem Files: cc66d0e2df8a5d20e91173c91f2b974e 553 x11 optional xrsh_5.92-8.dsc e998bfb80694c007c651262d03c4898f 4376 x11 optional xrsh_5.92-8.diff.gz 7d8ad5102ea9e1c6ec72b1bc3e490b8f 19150 x11 optional xrsh_5.92-8_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/vyTmO5zOp3h7rERAq6KAKCMh2s4JZbJaXLGGpTYgogX1uHu5gCeJLLv nusKQMuTVXOzgp5/mJ11bOU= =T9Kd -END PGP SIGNATURE- Accepted: xrsh_5.92-8.diff.gz to pool/main/x/xrsh/xrsh_5.92-8.diff.gz xrsh_5.92-8.dsc to pool/main/x/xrsh/xrsh_5.92-8.dsc xrsh_5.92-8_all.deb to pool/main/x/xrsh/xrsh_5.92-8_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted rng-tools 2-unofficial-mt.10-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 24 Feb 2006 09:49:44 -0300 Source: rng-tools Binary: rng-tools Architecture: source i386 Version: 2-unofficial-mt.10-2 Distribution: unstable Urgency: low Maintainer: Henrique de Moraes Holschuh [EMAIL PROTECTED] Changed-By: Henrique de Moraes Holschuh [EMAIL PROTECTED] Description: rng-tools - Daemon to use a Hardware TRNG Closes: 354186 Changes: rng-tools (2-unofficial-mt.10-2) unstable; urgency=low . * Fix typo in initscript which caused HRNGDEVICE definitions in /etc/default/rng-tools to be ignored, thanks to Dariush Pietrzak [EMAIL PROTECTED] for noticing this (closes: #354186) Files: 13f473a23fd59126ab88af28ab0e2036 908 utils optional rng-tools_2-unofficial-mt.10-2.dsc 23ae9d14765777f335818e4ef4847a30 14121 utils optional rng-tools_2-unofficial-mt.10-2.diff.gz 72d534200da51b27be52122e519373f1 42298 utils optional rng-tools_2-unofficial-mt.10-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iQEVAwUBQ/8B04jztdzjjnrPAQLwDAf8D0N/m2QqIgzS7jmFDLfV1HQa4hQp6U5a 9BrBgcnc83lscf4w8XFSlWRbbfcXMyY4PCjhDcUCgXxuu1oLcyZEJ65+YQ54UgUF nnUS7/SVSoBZ2ijtlb9VWaSSXpQ/7QAE+HQgJCXWfHKuamZ1oSzjTKC+WzrBqvFY otuv6jGFQLq/rbgMhZ1hcjMAn5HxZFre43z/L9r3gpd49BvJxiFcynT/W5jZkm/D sbGw669Ra4cJDIEfpjvdvEBjBiSLM38s0eekk081AC4hG3IjsYnILxK7ONbLqxsI P5NyOFPUQx2bX/F0OjiHB/vgdX65+Y+8IRIYNIaUg0mVAXuLak9nRA== =0JWM -END PGP SIGNATURE- Accepted: rng-tools_2-unofficial-mt.10-2.diff.gz to pool/main/r/rng-tools/rng-tools_2-unofficial-mt.10-2.diff.gz rng-tools_2-unofficial-mt.10-2.dsc to pool/main/r/rng-tools/rng-tools_2-unofficial-mt.10-2.dsc rng-tools_2-unofficial-mt.10-2_i386.deb to pool/main/r/rng-tools/rng-tools_2-unofficial-mt.10-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dpkg-sig 0.13 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 24 Feb 2006 01:05:53 +0100 Source: dpkg-sig Binary: dpkg-sig Architecture: source all Version: 0.13 Distribution: unstable Urgency: low Maintainer: Marc 'HE' Brockschmidt [EMAIL PROTECTED] Changed-By: Marc 'HE' Brockschmidt [EMAIL PROTECTED] Description: dpkg-sig - create and verify signatures on .deb-files Closes: 342473 352723 352727 352730 Changes: dpkg-sig (0.13) unstable; urgency=low . * HE - dpkg-sig: + Fix -k option so that the maintainer name is still retrieved from the gpg key. Patch from Julian Gilbey [EMAIL PROTECTED], thanks. (Closes: #352727) + Remove --debug option (but leave code in so that manual code changes can reactivate the debug stuff). (Closes: #352723) - dpkg-sig.pod: + Update whole manpage, based on patch from Julian Gilbey [EMAIL PROTECTED]. Thanks! (Closes: #352730) - examples/README: + Replace a left-over debsigs-ng.sample/md5sums.asc by digests.asc. Thanks for the note, Julian. (Closes: #342473) - debian/control: + Updated Standards-Version to 3.6.2 + Make me Maintainer, aba Co-Maint (mostly to get dpkg-sig on my QA overview page without co-maintained packages). . - Make package lintian clean (includes overrides for empty files, they are empty for a reason). Files: dcd3d22d773c3b1e8cb4076f5b63ff54 551 devel optional dpkg-sig_0.13.dsc fc79f284bbfd169aaed03b1c1eae8527 27975 devel optional dpkg-sig_0.13.tar.gz b38e68c616e85a18491846e09914dc59 37560 devel optional dpkg-sig_0.13_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/wgCmO5zOp3h7rERAmKiAJ9sjvVlnYtrwH7Wk6bJ1hJb/37eaACdHEhy KBINJphGGb0oRCQHBfh3kzw= =UgSS -END PGP SIGNATURE- Accepted: dpkg-sig_0.13.dsc to pool/main/d/dpkg-sig/dpkg-sig_0.13.dsc dpkg-sig_0.13.tar.gz to pool/main/d/dpkg-sig/dpkg-sig_0.13.tar.gz dpkg-sig_0.13_all.deb to pool/main/d/dpkg-sig/dpkg-sig_0.13_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted texinfo 4.8-5 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 24 Feb 2006 12:35:27 +0100 Source: texinfo Binary: texinfo info Architecture: source i386 Version: 4.8-5 Distribution: unstable Urgency: low Maintainer: Norbert Preining [EMAIL PROTECTED] Changed-By: Norbert Preining [EMAIL PROTECTED] Description: info - Standalone GNU Info documentation browser texinfo- Documentation system for on-line information and printed output Closes: 276000 352630 Changes: texinfo (4.8-5) unstable; urgency=low . * Fix segfault when resizing the terminal rapidly by checking more carefully whether the display line is set prior to refering to it. [info/display.c:display_update_one_window] (closes partly #345739) (Thanks to Loïc Minier [EMAIL PROTECTED]) * Fix the watch file * Remove the dependency on tetex-bin | tex-common, we can live without it. This also fixes the Priority failure of texinfo=standard depending on tex-common=optional. * Include texinfo.tex version 2006-01-27.14 (Closes: #276000) * Edit Changelog entry for 4.8-1 for bug #282643. * Remove texmf/pdftex/plain/misc/pdfcolor.tex in tmpdir to make dh_install shut up, this file is already installed by tetex/texlive. * change test in postinst script from which fmtutil-sys to kpsewhich --version. If it is present *and* can be run (i.e. tetex and libkpathsea is unpacked and configured), only then call the rest of the script. (Closes: #352630) Files: 58c05a238b8c60f019f567e24d9e56e7 615 doc standard texinfo_4.8-5.dsc 08774554c50026a16180a62c9d586ce5 94764 doc standard texinfo_4.8-5.diff.gz 48274277c68224103e997849e9312b51 1219008 text standard texinfo_4.8-5_i386.deb 97e8ad3aef970305f95588afc45916d3 219120 doc important info_4.8-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/xNk1IXdL1v6kOwRAnt0AJ4x3CaUeOO8+96yJSTFQZzdvzVvRACfbcdE a1nzrw7a3NjZfmHi1q5Jxms= =UOBg -END PGP SIGNATURE- Accepted: info_4.8-5_i386.deb to pool/main/t/texinfo/info_4.8-5_i386.deb texinfo_4.8-5.diff.gz to pool/main/t/texinfo/texinfo_4.8-5.diff.gz texinfo_4.8-5.dsc to pool/main/t/texinfo/texinfo_4.8-5.dsc texinfo_4.8-5_i386.deb to pool/main/t/texinfo/texinfo_4.8-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted linux-kernel-di-m68k-2.6 0.70 (source m68k)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 24 Feb 2006 07:37:06 -0600 Source: linux-kernel-di-m68k-2.6 Binary: kernel-image-2.6.15-1-mac-di reiserfs-modules-2.6.15-1-amiga-di fat-modules-2.6.15-1-mvme147-di ppp-modules-2.6.15-1-mac-di reiserfs-modules-2.6.15-1-hp-di fat-modules-2.6.15-1-amiga-di jfs-modules-2.6.15-1-amiga-di nic-shared-modules-2.6.15-1-hp-di jfs-modules-2.6.15-1-sun3-di ppp-modules-2.6.15-1-mvme147-di scsi-modules-2.6.15-1-mvme147-di reiserfs-modules-2.6.15-1-atari-di scsi-modules-2.6.15-1-mvme16x-di fat-modules-2.6.15-1-mac-di reiserfs-modules-2.6.15-1-sun3-di fat-modules-2.6.15-1-mvme16x-di nic-shared-modules-2.6.15-1-amiga-di reiserfs-modules-2.6.15-1-mvme147-di jfs-modules-2.6.15-1-hp-di ppp-modules-2.6.15-1-mvme16x-di fat-modules-2.6.15-1-bvme6000-di scsi-modules-2.6.15-1-amiga-di fat-modules-2.6.15-1-atari-di jfs-modules-2.6.15-1-mvme16x-di nic-shared-modules-2.6.15-1-mvme147-di ppp-modules-2.6.15-1-atari-di kernel-image-2.6.15-1-mvme16x-di kernel-image-2.6.15-1-hp-di nic-shared-modules-2.6.15-1-mac-di jfs-modules-2.6.15-1-mvme147-di reiserfs-modules-2.6.15-1-bvme6000-di jfs-modules-2.6.15-1-q40-di reiserfs-modules-2.6.15-1-mvme16x-di jfs-modules-2.6.15-1-mac-di scsi-modules-2.6.15-1-hp-di reiserfs-modules-2.6.15-1-mac-di nic-shared-modules-2.6.15-1-q40-di kernel-image-2.6.15-1-mvme147-di kernel-image-2.6.15-1-sun3-di scsi-modules-2.6.15-1-bvme6000-di ppp-modules-2.6.15-1-amiga-di ppp-modules-2.6.15-1-bvme6000-di fat-modules-2.6.15-1-hp-di nic-shared-modules-2.6.15-1-sun3-di scsi-modules-2.6.15-1-mac-di ppp-modules-2.6.15-1-hp-di kernel-image-2.6.15-1-bvme6000-di jfs-modules-2.6.15-1-atari-di jfs-modules-2.6.15-1-bvme6000-di nic-shared-modules-2.6.15-1-atari-di ppp-modules-2.6.15-1-sun3-di nic-shared-modules-2.6.15-1-mvme16x-di nic-shared-modules-2.6.15-1-bvme6000-di reiserfs-modules-2.6.15-1-q40-di scsi-modules-2.6.15-1-sun3-di scsi-modules-2.6.15-1-atari-di fat-modules-2.6.15-1-q40-di kernel-image-2.6.15-1-q40-di kernel-image-2.6.15-1-atari-di scsi-modules-2.6.15-1-q40-di kernel-image-2.6.15-1-amiga-di fat-modules-2.6.15-1-sun3-di ppp-modules-2.6.15-1-q40-di Architecture: source m68k Version: 0.70 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Stephen R. Marenka [EMAIL PROTECTED] Description: fat-modules-2.6.15-1-amiga-di - FAT filesystem support (udeb) fat-modules-2.6.15-1-atari-di - FAT filesystem support (udeb) fat-modules-2.6.15-1-bvme6000-di - FAT filesystem support (udeb) fat-modules-2.6.15-1-hp-di - FAT filesystem support (udeb) fat-modules-2.6.15-1-mac-di - FAT filesystem support (udeb) fat-modules-2.6.15-1-mvme147-di - FAT filesystem support (udeb) fat-modules-2.6.15-1-mvme16x-di - FAT filesystem support (udeb) fat-modules-2.6.15-1-q40-di - FAT filesystem support (udeb) fat-modules-2.6.15-1-sun3-di - FAT filesystem support (udeb) jfs-modules-2.6.15-1-amiga-di - JFS filesystem support (udeb) jfs-modules-2.6.15-1-atari-di - JFS filesystem support (udeb) jfs-modules-2.6.15-1-bvme6000-di - JFS filesystem support (udeb) jfs-modules-2.6.15-1-hp-di - JFS filesystem support (udeb) jfs-modules-2.6.15-1-mac-di - JFS filesystem support (udeb) jfs-modules-2.6.15-1-mvme147-di - JFS filesystem support (udeb) jfs-modules-2.6.15-1-mvme16x-di - JFS filesystem support (udeb) jfs-modules-2.6.15-1-q40-di - JFS filesystem support (udeb) jfs-modules-2.6.15-1-sun3-di - JFS filesystem support (udeb) kernel-image-2.6.15-1-amiga-di - Linux kernel binary image for the Debian installer (udeb) kernel-image-2.6.15-1-atari-di - Linux kernel binary image for the Debian installer (udeb) kernel-image-2.6.15-1-bvme6000-di - Linux kernel binary image for the Debian installer (udeb) kernel-image-2.6.15-1-hp-di - Linux kernel binary image for the Debian installer (udeb) kernel-image-2.6.15-1-mac-di - Linux kernel binary image for the Debian installer (udeb) kernel-image-2.6.15-1-mvme147-di - Linux kernel binary image for the Debian installer (udeb) kernel-image-2.6.15-1-mvme16x-di - Linux kernel binary image for the Debian installer (udeb) kernel-image-2.6.15-1-q40-di - Linux kernel binary image for the Debian installer (udeb) kernel-image-2.6.15-1-sun3-di - Linux kernel binary image for the Debian installer (udeb) nic-shared-modules-2.6.15-1-amiga-di - Shared NIC drivers (udeb) nic-shared-modules-2.6.15-1-atari-di - Shared NIC drivers (udeb) nic-shared-modules-2.6.15-1-bvme6000-di - Shared NIC drivers (udeb) nic-shared-modules-2.6.15-1-hp-di - Shared NIC drivers (udeb) nic-shared-modules-2.6.15-1-mac-di - Shared NIC drivers (udeb) nic-shared-modules-2.6.15-1-mvme147-di - Shared NIC drivers (udeb) nic-shared-modules-2.6.15-1-mvme16x-di - Shared NIC drivers (udeb) nic-shared-modules-2.6.15-1-q40-di - Shared NIC drivers (udeb) nic-shared-modules-2.6.15-1-sun3-di - Shared NIC drivers (udeb) ppp-modules-2.6.15-1-amiga-di - PPP drivers (udeb)
Accepted bricolage 1.8.9-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 23 Feb 2006 14:13:00 +0100 Source: bricolage Binary: bricolage bricolage-queued libbric-perl bricolage-cms bricolage-db Architecture: source all Version: 1.8.9-1 Distribution: unstable Urgency: low Maintainer: Daniel Baumann [EMAIL PROTECTED] Changed-By: Daniel Baumann [EMAIL PROTECTED] Description: bricolage - Virtual Package to install full Bricolage CMS bricolage-cms - Content Management System bricolage-db - Content Management System database schema bricolage-queued - Defered publishing for Bricolage CMS libbric-perl - Bricolage Content Management System libraries Closes: 348948 Changes: bricolage (1.8.9-1) unstable; urgency=low . * New maintainer (Closes: #348948). * New upstream release. Files: 9334e4fed9299506f53833ca2cf18aa6 691 web optional bricolage_1.8.9-1.dsc 6eb9102388b00c669f52b59efb0fce9b 2558177 web optional bricolage_1.8.9.orig.tar.gz 2f28c0a1734e89aba38337f5ac364e58 17008 web optional bricolage_1.8.9-1.diff.gz cbce923fef089c36a0901ddea1298600 1875618 web optional libbric-perl_1.8.9-1_all.deb d5d0a6bf717264eb077f319038e321b2 1558814 web optional bricolage-cms_1.8.9-1_all.deb 4db2e315c64e7493703f8c5f8e7a5dd8 137714 web optional bricolage-db_1.8.9-1_all.deb 54d5b8cd0f5b9fb32c0463404cfbfb0a 87290 web optional bricolage-queued_1.8.9-1_all.deb 6c147722219333c1ff12c521f989c36b 78736 web optional bricolage_1.8.9-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFD/zupxa93SlhRC1oRAlqvAKCgYvGulGq9BgZSl4eMe9DIv0OxZgCg3xbf n7z87jOyaGg8n8AdLrhUdgk= =7BUC -END PGP SIGNATURE- Accepted: bricolage-cms_1.8.9-1_all.deb to pool/main/b/bricolage/bricolage-cms_1.8.9-1_all.deb bricolage-db_1.8.9-1_all.deb to pool/main/b/bricolage/bricolage-db_1.8.9-1_all.deb bricolage-queued_1.8.9-1_all.deb to pool/main/b/bricolage/bricolage-queued_1.8.9-1_all.deb bricolage_1.8.9-1.diff.gz to pool/main/b/bricolage/bricolage_1.8.9-1.diff.gz bricolage_1.8.9-1.dsc to pool/main/b/bricolage/bricolage_1.8.9-1.dsc bricolage_1.8.9-1_all.deb to pool/main/b/bricolage/bricolage_1.8.9-1_all.deb bricolage_1.8.9.orig.tar.gz to pool/main/b/bricolage/bricolage_1.8.9.orig.tar.gz libbric-perl_1.8.9-1_all.deb to pool/main/b/bricolage/libbric-perl_1.8.9-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted lastfmsubmitd 0.22-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 23 Feb 2006 14:44:58 -0500 Source: lastfmsubmitd Binary: lastfmsubmitd Architecture: source all Version: 0.22-1 Distribution: unstable Urgency: low Maintainer: Decklin Foster [EMAIL PROTECTED] Changed-By: Decklin Foster [EMAIL PROTECTED] Description: lastfmsubmitd - submission daemon for the Last.fm social music network Changes: lastfmsubmitd (0.22-1) unstable; urgency=low . * New upstream release. Last one today, hopefully. Files: e0b67ced845e371e518168d793b9bf5a 585 sound optional lastfmsubmitd_0.22-1.dsc 1fce589a95860ffc07a8acdbe42db1d0 19050 sound optional lastfmsubmitd_0.22.orig.tar.gz 0652b929aedb4de42e8e1bf62e9923e5 3585 sound optional lastfmsubmitd_0.22-1.diff.gz 32553658133d9de32e61dc21edd871e5 25722 sound optional lastfmsubmitd_0.22-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/hEFuIJGh/GWjRsRAuCZAJ42FXonK4bKHZEit8Mvs8haat6maACeMdai iZHvCtmYS18IdrZm0axu5uI= =8zDw -END PGP SIGNATURE- Accepted: lastfmsubmitd_0.22-1.diff.gz to pool/main/l/lastfmsubmitd/lastfmsubmitd_0.22-1.diff.gz lastfmsubmitd_0.22-1.dsc to pool/main/l/lastfmsubmitd/lastfmsubmitd_0.22-1.dsc lastfmsubmitd_0.22-1_all.deb to pool/main/l/lastfmsubmitd/lastfmsubmitd_0.22-1_all.deb lastfmsubmitd_0.22.orig.tar.gz to pool/main/l/lastfmsubmitd/lastfmsubmitd_0.22.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
