Re: unstable? nah. :-)
Tyler MacDonald wrote: I moved the server because wedohosting.com's bandwidth fees were getting prohibitive (i'm with iweb.ca now).. otherwise I would have been happy to have it continue running for another few thousand days. :-) I find that Tera-Byte.com in Edmonton has nice colo rates. And yes, webohosting.com's fees seem quite excessive. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: making more packages binary NMU safe
Ken Bloom wrote: I noticed that glabels is broken on i386 because it's not binary NMU safe, and someone did a binary NMU. After poking around a bit, I found http://lists.debian.org/debian-dpkg/2005/11/msg0.html, which discussed a possible solution to this problem. Since then, we have changed the version number format for binary NMUs, so I wanted to submit a patch (based on the one mentioned previously) to allow the creation more binNMU safe packages. Instead of doing blind substitutions like it is done currently, it is possible to separate Arch:all from Arch:any|other|whatever in the substitution script such that, Source-Version = bin NMU version for binaries that are build Source-Version = 'original' version for Arch:all binaries This way nothing needs to be changed. No transition. Just some code. Not as trivial as introducing new variables, but a lot simpler in the sort term and the long term. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#308725: ITP: dhcpv6 -- a stateful address autoconfiguration protocol for IPv6
On 5/12/05, Peter Samuelson [EMAIL PROTECTED] wrote: [Adam M.] Description : a stateful address autoconfiguration protocol for IPv6 DHCPv6 is a stateful address autoconfiguration protocol for IPv6, a counterpart to IPv6 stateless address autoconfiguration protocol. Please specify whether your package provides a client, a server, or both. If it's only a client, or only a server, you should probably rename the package accordingly (see the DHCPv4-related packages). This was meant as a ITP: source package here One binary will include the client, and another the server It wouldn't hurt to mention that the stateless server is the Debian package 'radvd' and doesn't require specific client software other than iproute or whatever. Yes, radvd is the stateless server and the kernel has the client for auto-self-configuration. It can either be used independently or it can coexist with its counterpart protocol. This protocol uses client/server mode of operation but can also provide support through a Relay Agent. Is the Relay Agent provided by this package as well, or by a separate Debian package, or does Debian not have one at all? I don't think there is one. The sources do have a dhcp6relay.c, but that is not compiled. The relay agent is in the TODO list. I guess the Relay Agent should have been lowercase! - Adam
Re: mrtg package problems
Laszlo Boszormenyi wrote: Hi, On Tue, 2005-05-10 at 12:23 -0500, Adam Majer wrote: Currently there are two packages that he maintains, Yup. I would like to maintain mrtg since I do use it. As to the other package, it probably should be orphaned. OK, please check the bugs, review patches etc. for mrtg. I may even sponsor it if you need it. A company I am contact with, is just checking it, but they may switch to netmrg. Most (or almost most :) of the bugs seem like they were fixed some time ago. Some of the bugs look like usability issues and I will get to those. My other big cleanup job was with lpr, which I think is now in a much better shape then when it was orphaned. This is another small, yet important to me, package that was neglected way too long. As to netmrg, well, it looks OK. I guess it depends what one needs. All I need it to get some SNMP data into a graph form. For me mrtg is perfect for what I need it. The new mrtg (0.11) will probably not make it into Sarge due to the freeze. The one in Sarge is quite usable without any major bugs. And finally, I will not be needed a sponsor :) Anyway, I will try to take care of the problem. I'll see if I can contact Shiju and if there is no response by end of the month, I'll orphan the packages and take over mrtg, unless someone has a problem. I am OK with it, even if I am only a simple DD without too much words. Anyway, you can do NMUs meanwhile as Jeroen already wrote about it. Sure. I will look over the bugs and try to get the vast majority closed/fixed. I didn't know that Jeroen tried to contact Shiju until I read his reply to you yesterday. - Adam signature.asc Description: OpenPGP digital signature
Re: mrtg package problems
Gunnar Wolf wrote: Adam Majer dijo [Tue, May 10, 2005 at 12:23:10PM -0500]: Currently there are two packages that he maintains, http://qa.debian.org/[EMAIL PROTECTED] *libnet**-easytcp-perl **mrtg I would like to maintain mrtg since I do use it. As to the other package, it probably should be orphaned. I am not currently using it, but seems easy to maintain - I'll take it over. Sure. Thanks. I guess Shiju's packages are now divided up. Now let's see if he even reads his email anymore. There is no rush anymore since the new packages will most likely not enter Sarge. - Adam signature.asc Description: OpenPGP digital signature
Bug#308725: ITP: dhcpv6 -- a stateful address autoconfiguration protocol for IPv6
Package: wnpp Severity: wishlist Owner: Adam M. [EMAIL PROTECTED] * Package name: dhcpv6 Version : 0.10 Upstream Author : ?? Not a single one - many... * URL : http://dhcpv6.sourceforge.net/ * License : Mostly BSD, some LGPL and MIT/X Description : a stateful address autoconfiguration protocol for IPv6 DHCPv6 is a stateful address autoconfiguration protocol for IPv6, a counterpart to IPv6 stateless address autoconfiguration protocol. It can either be used independently or it can coexist with its counterpart protocol. This protocol uses client/server mode of operation but can also provide support through a Relay Agent. Current upstream does not appear to be very active. I'm not yet certain whether I will make this a Debian package or Upstrea/Debian patch. This depends on how much of the code can be replaced by current libc functionality. I should get this package done within a month (so by mid-June) since I will be doing some code reviewing and not just packaging. - Adam -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-k7 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Baghira] :: Re: packages missing from sarge
Vadim Petrunin wrote: Sorry, but looks like there is no rc bugs in the baghira package. There was only one bug Serious policy violations but it is resolved now. Why it is out of release? http://packages.qa.debian.org/b/baghira.html Ask the maintainer. It was not in Sarge because of that one RC bug. The fixed version was uploaded just two days ago so... Sarge has frozen a while before that. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Debian AMD64 is Debian
Hamish Moffatt wrote: On Friday 06 May 2005 11:22am, Joerg Jaspert wrote: Hi Note: non-free is NOT provided yet. We need to decide what we do with it, as we may be forbidden to distribute some of the software in it (we aren't Debian). Not necessary. For 'sattrack' for example, I got permission for us to distribute it in Debian. But I don't know if that extends to Debian-AMD64 (an unofficial distribution) and Ubuntu would certainly have to ask for their own permission. Actually, non-free is not Debian as well (as far as I recall), but all of us consider it part of the Debian project. Honestly, I would consider the AMD64 port part of the Debian project since it is a *port* and you can find it at http://www.debian.org/ports/amd64/ . The only differences between non-free and AMD64 non-free is that AMD64 is not part of the Debian mirror network (ie. not officially part of Sid/Sarge). Anyway, I think if package can be distributed by Debian, it can implicitly be distributed by any of the Debian ports, released or not. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 is Debian
Goswin von Brederlow wrote: Adam M. [EMAIL PROTECTED] writes: We are not part of Debian. We are not allowed to use certain Debian resources such as buildd.d.o for buildd logs, access to the incoming queue for buildds or wanna-build and several other things. So if Debian itself does not think amd64 is part of it why should the law? Luckily other parts of Debian are not that subborn and support us none the less, like package.debian.org or soon cdimage.d.o to name two. Then let us hope that amd64 will be added to sid soon.. I am looking at the non-free copyrights and hopefully I will weed-out any Debian distribution only ones soon. I'll put the results up on people.d.o webpage so other distributions based on Debian, like Ubuntu, can use that if they want to make sure they do not distribute something they don't have permission to distribute... - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: www.debian.org and users information
Kevin Mark wrote: Hi DD folks, Sarge is now approaching zero kelvin and folks are scrambing to get the last few bugs squashed. I was recently thinking about why the non-clued folks bash Debian with incomplete or inaccurate facts and a way to address that. I think there should be a section on the main page that contains links to cluefull faq to clear the FUD and to shed light on That would imply we actually care about the FUD. Having an in-your-face FAQ about all these points would be OK, but people spreading the FUD would not care regardless. There is a group of people that will not read any manual, but think they still know everything regardless. They will look at stable/testing/unstable and proclaim from the bottom of their orifices that they know what these stand for. They will ignore the Debian Reference at http://www.debian.org/doc/manuals/reference/reference.en.html even though it is two clicks away from the main page (click on Docs then the Debian Reference). So the bottom line is people that listen/spreading FUD will probably not be addressed by this FAQ because they are not interested in reading documentation in the first place. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On 5/4/05, Adrian Bunk [EMAIL PROTECTED] wrote: On Tue, May 03, 2005 at 01:54:46PM -0500, Adam M. wrote: Adrian Bunk wrote: grave - serious isn't worth a discussion since there's not a big difference between them (both are RC) You are 100% wrong here. Why do we have bug severities then? Severities are there to inform the developer and the rest of the Debian world about the seriousness of the bug. I tend to stay away from packages that have grave or critical bugs against them before I read the bug report. So, let me refresh your mind about bug severities, ... Let me try to reformulate my point: important - serious or important - grave are worth a discussion, because if the bug is only important it's not unlikely sarge will ship with this bug. True, though important bugs can still be fixed during the freeze. We could have a lengthy discussion whether there are possible scenarios where a specific dependency problem might cause data loss (which would make it grave) or whether it's only a policy violation. (If you are using php4-mysql on a web server to write the orders of your costumers into a database, couldn't this bug cause data loss?) It wouldn't be grave just because it broke in my scenario. Data loss occurs when you think something worked, but it didn't. Or it corrupted/destroyed your data. I am ignorant to the actual bug though (haven't tried it myself). If the combination of php4 amd php4-mysql causes silent failures, then this is data loss and bug should be grave. If the application craps out with a visible error(s), or wrong output, then this bug does not cause data loss and is not grave. This doesn't mean all bugs are not important (not in BTS severity sense). I treat all bugs as important and try to resolve them. But the practical differences between critical, grave and serious are small enough that if I send a bug as grave and you'd downgrade it to serious, I wouldn't care. True, it doesn't really matter for the submitter if the bug is critical or serious if they only care that version X+1 of package doesn't go to testing due to the bug and X works. But severities do matter when you try to prioritize your work. For example, it is inappropriate for someone to file a critical bug just because they can't use feature X in program Alpha. Severties can and should be used to keep more buggy versions from progressing into testing. Severities are for practical reasons while many people still put their emotions into bug reports. This usually ends up with inflated bug severities. - Adam
Re: Bug#307570: please provide releasenotes (Re: Release update: editorial changes to the testing propagation scripts)
Holger Levsen wrote: btw, google has no (good) hits for sarge releasenotes, but for sarge release notes they have... maybe this helps. Try sarge release notes - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
Adrian Bunk wrote: grave - serious isn't worth a discussion since there's not a big difference between them (both are RC) You are 100% wrong here. Why do we have bug severities then? Severities are there to inform the developer and the rest of the Debian world about the seriousness of the bug. I tend to stay away from packages that have grave or critical bugs against them before I read the bug report. So, let me refresh your mind about bug severities, |critical - |makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. |grave - |makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. |serious - |is a severe violation of Debian policy http://release.debian.org/sarge_rc_policy.txt (roughly, it violates a must or required directive), or, in the package maintainer's opinion, makes the package unsuitable for release. |important - |a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. |normal - |the default value, applicable to most bugs. |minor - |a problem which doesn't affect the package's usefulness, and is presumably trivial to fix. |wishlist - |for any feature request, and also for any bugs that are very difficult to fix due to major design considerations. source: http://www.debian.org/Bugs/Developer#severities Thus, a bug that makes the package break like this falls under the important category (since an easy work around is available). *But*, the bug is also a violation of the Debian policy (ie. depends), so it becomes serious. Grave bugs are only there if the package doesn't work at all when you upgraded ALL depends to latest versions. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming removals
François-Denis Gonthier wrote: On May 3, 2005 09:54 am, Martin Michlmayr wrote: #297426: O: langband -- The langband Common lisp game Reported by: Kevin M. Rosenberg [EMAIL PROTECTED]; 63 days old. #297427: O: langband-data -- The Langband sound/image/etc files for langband engine Reported by: Kevin M. Rosenberg [EMAIL PROTECTED]; 63 days old. Can a non-DD (like me) take over those packages? Yes. You just need a sponsor to upload. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: launchd and lookupd
martin f krafft wrote: Apple has just released launchd, a init/cron/watchdog/etc. replacement. Has anyone looked at it? It seems like a bit of work to It is not a good idea to replace multiple system utilities with one. Right now I can install a different cron or inetd or atd, or I can remove them. I don't think launchd is a viable alternative to all these programs since it tries to do too much. There are positives for apple for doing this, but I don't think they translate to an open distribution like Debian. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Outrageous Maintainer
Anthony DeRobertis wrote: Klaus Ethgen wrote: The according bug is #306608. This is a bug, though possibly not in the libwxgtk2.4-python package. If the relevant maintainers (libwxgtk2.4-python, wxpython2.5.3) and bug sumitters can't work out a solution, then ask the Technical Comittee to do so. That's what they're there for. I haven't read the bug report, but when a newer package replaces an older one, you need to have add a Conflicts: old version Replaces: old version To the new package. I think apt-get, dselect and others have been set up in this manner. It is not correct to put Conflicts in the 2.4 package because it is 2.5 that *caused* the conflict. It came on the scene AFTER 2.4, right? - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sarge release for amd64 - Please help to fix the remaining bugs
Steve Langasek wrote: Ideally, we would have agreement to update all of the following packages to libmysqlclient12 at the same time: I would suggest that libmysqlclient14 should be used if possible. MySQL has changed the way passwords are stored in the database and this prevents clients from connecting to MySQL databases unless old-passwords option is enabled (which it is in Debian). libmysqlclient12 clients cannot connect to MySQL 4.1.x and newer databases unless old password is explicitly used or enabled. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Temporal Release Strategy
Isn't the process: 1) make a patch 2) give it to the apache developers 3) new packaged apache versions have the patch 4) patch makes it upstream 5) patch no longer needed in debian package You know, there are security updates for stable releases. You have to patch those. If there are 15 versions of Apache in various stable releases, that means 15 packages to apply patches to. Well, let's just say it is less then realistic. Also, try providing an efficient stable security build daemons! The chroots would have to be rebuilt for each package. ? I guess I don't understand enough about how the build process works for the packages in debian but that sounds funny to me. Or I just don't understand what you mean. To build security patches, you need the same libraries, compilers, etc... for the release so the built package has the same ABI. In many ways, current testing is your stable. No kidding, so what the heck is the point of having a stable symlink to woody. The stable, testing and unstable symlinks should be removed. They are just being used as FUD by people against debian. Yes, it is mostly FUD. You can change the symlinks to stale, staging, bleedingedge or whatever. For more information of what is in Debian, and especially its FTP structures, see http://www.debian.org/doc/manuals/reference/ch-system.en.html#s-dists Also, I think you replied to this without even reading the thread. I said his definition of stable, not current stable. Extending the testing period from testing to your proposed candidate and then stable would do nothing about normals bugs. RC bugs are usually found quite quickly by people using unstable. Why not let people choose what they want to use woody sarge or sid and never change the names again. I think lots of people are happy with how things work now. No need to ever do a release again. Just remove the old/arcane symlinks. Almost everyone I know uses sid; I don't think anyone is going to switch to sarge once sid is out. These names will never change. You can still use Slink or Hamm if you want. Oh, and Sid will never release because it is always unstable. See above link for more details. Also, your the last statement shows your lack of understanding of the release process. Instigating needless flamewars, like you just did, is probably the main reason why Ubuntu was created. So, if you are going to rant about something you don't know about (and don't care about since you use Sid, not Sarge), take a break and then think if it's worth it. - Adam
Re: Temporal Release Strategy
On 4/20/05, Jeff Carr [EMAIL PROTECTED] wrote: Adam M wrote: ? I guess I don't understand enough about how the build process works for the packages in debian but that sounds funny to me. Or I just don't understand what you mean. To build security patches, you need the same libraries, compilers, etc... for the release so the built package has the same ABI. Surely. I just thought there could be only one version of a package in the Packages.gz file. I didn't think each older package that might be in main/a/apache/ would be rebult with the enviornment that it was originally built in. If I understand you correctly and that is what happens, then I see that would be computing intensive. Well, this is one problem with having automatic releases like this. There are much bigger problems though, like mirror space. The Vancouver proposal trying to address this. If you have a package with versions A for arch A', then maintainer uploads package version B but arch A' can't keep up building it, then the mirrors must have both, versions A and B of the source of the package. Vancouver proposal was trying to move some less popular and/or obsolete arches from the main mirror network to a voluntary one (ie. not trying to kill the ports or something). As you can see, having many overlapping releases like the Temporal Release Strategy would kill the current mirror network. Yes, it is mostly FUD. You can change the symlinks to ... Well, I can't really change them; I was more just giving my point of view as a happy debian user. ... Sorry; wasn't trying to do that. Just passing on results of working in a corporate enviornment and the kinds of complaints that have been used against debian deployment. I would suggest instead of saying you are installing testing, just tell them you are installing Debian Sarge, or Debian 3.1 and set up /etc/apt/sources.list to refer to sarge in place of stable/testing/unstable. There is no use telling people they are running unstable or testing if they don't know what it means in the first place (like telling people about building a nuclear power plant instead of a coal power plant - they'll rise up in protest without realising that coal power plants produce more radiation than a nuclear power plant). - Adam
Re: Temporal Release Strategy
On 4/16/05, Patrick Ouellette [EMAIL PROTECTED] wrote: On Fri, 2005-04-15 at 21:48 -0500, Adam M. wrote: Unfortunately this totally changes the purpose of stable. Stable is Yes and no. It changes the concept of stable in that stable evolves. You still have the static release as long as we decide to keep that version of all the packages in the package pools. The implementation of package pools created a virtual release environment where the release in the archives is only defined by the contents of the Packages file at the time of release. A similar thing is already here in http://snapshot.debian.net/ You cannot do this with the archive. The current archive size is already too big for most mirrors to handle. You can still have this environment. As long as your system looks at the Packages file from the release (and the security updates Packages file). see above link :) Testing does not remedy this problem. If testing was virtually always production quality then there would be no need for the release manager to go through an elaborate freeze bug fix cycle to get things in shape for a release. All you are proposing is another testing-like stage. Bugs would propagate there regardless. Bugs are part of stable as well. We should not destroy the notion of stable to get up-to-date packages. I'm not trying to destroy the notion of stable, I have a different definition of stable. My definition of stable is software that does what it is designed to do without bugs, in the manner in which the designer and programmer intended. I'm also trying to show that the Then your stable never existed. All software has bugs be it Linux or Windows based Software of any complexity without any bugs does not exist. For example, look at the number of bugs in emacs, yet, I would consider the software mature and relatively bug-free. traditional concept of a release in Debian is outdated. I will even go so far as to say the reason Debian has had exponentially longer release cycles is that the traditional concept of a release is flawed for a project the size and scope of Debian. We need to adjust our thinking outside the traditional definitions. Why? Why is there RHEL 2.0, 3.0.. Why not just RHEL 2005-01-01, 2005-01-02, etc..? The releases are there to provide interface stability. Everyone does this. What you are proposing is the time based snapshots which are already available on http://snapshot.debian.net/ Now, if you want to support snapshot of Debian with 36 month security, well, be my guest :) In the last 36-months, there were about 30 uploads of Apache to unstable. Now, if only 15 such versions propagated to stable snapshots, then you find a remote hole, and suddenly you have to backport a security fix for 15 versions of Apache! Also, try providing an efficient stable security build daemons! The chroots would have to be rebuilt for each package. I think this proposal could actually enhance the stability of Debian (where stability is defined as lack of bugs, not software that never changes except for security updates), as well as further enhance the reputation Debian maintains in the community. In many ways, current testing is your stable. Extending the testing period from testing to your proposed candidate and then stable would do nothing about normals bugs. RC bugs are usually found quite quickly by people using unstable. - Adam
Re: Temporal Release Strategy
Patrick A. Ouellette wrote: The progression I see is: unstable - testing - candidate - stable Unfortunately this totally changes the purpose of stable. Stable is there not to provide bug free, up-to-date software releases. Stable is to provide environmental stability. When someone installs package X from stable, it is guaranteed that this package will remain at version X though all security updates, etc.. It will remain as is, bugs and all. This has a few disadvantages and advantages. The main advantages include, * less time spent on maintaining your production machines - once you set them up, no need to change the configs. * ability to maintain 1000s of installations by one person - installing a new machine can be as simple as `dd` the partition. * security fixes do not break your system (3rd party applications or otherwise) The main disadvantage of this is that stable becomes stale. The current testing is a remedies for this problem. Up-to-date packages are provided in testing where the packages are virtually always production quality. The main disadvantage of testing is lack of environmental stability seen in stable. The only difference between the support of testing vs. stable in Debian is security support. If we have volunteers for the security team for testing (for Etch), then I'm certain Debian can have two release modes, stable - environmental stability implying stale packages testing - up-to-date packages implying more work by admins So, if we get testing-security working, then we will essentially have two releases. We should not destroy the notion of stable to get up-to-date packages. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Making new packages
Nico Golde wrote: Hi, if we would drop some archs now, what is the best way of making new packages. Should we just fill in the archs which are supported in the future too to hold the load on the archs buildds which will be dropped low? No. Just leave it as any unless there is a good reason not to. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gluck (cvs, people, planet, etc.) downtime - ongoing raid problems
Christian Storch wrote: Strange: Could there be any correlation with my observed problems about resolving anything of debian.org during exactly that time? (http://lists.debian.org/debian-isp/2005/04/msg00023.html) Name Server:SAENS.DEBIAN.ORG Name Server:KLECKER.DEBIAN.ORG Name Server:SPOHR.DEBIAN.ORG Gluck doesn't appear to host DNS of any kind. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gluck (cvs, people, planet, etc.) downtime - ongoing raid problems
Blars Blarson wrote: Name Server:SAENS.DEBIAN.ORG Name Server:KLECKER.DEBIAN.ORG Name Server:SPOHR.DEBIAN.ORG spohr changed IP addresses last week, and the glue record returned by the .org nameservers still had the old address when I checked a few hours ago. This has been reported to debian-admin. (The new address is 140.211.166.43) Ok, but that should not cause DNS failure unless the old spohr address returned authoritative no such domain or the other two DNSes didn't work either. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: watch file for SourceForge packages
Shaun Jackman wrote: This doesn't work for me: $ cat debian/watch version=2 http://prdownloads.sourceforge.net/n/ne/neutrino/neutrino-(.*)\.tar\.gz debian uupdate $ uscan neutrino: Newer version (0.8.2) available on remote site (local version is 0.7.3) neutrino: Successfully downloaded updated package neutrino-0.8.2.tar.gz and symlinked neutrino_0.8.2.orig.tar.gz to it New Release will be 0.8.2-1. -- Untarring the new sourcecode archive ../neutrino_0.8.2.orig.tar.gz Download it manually. watch files' main purpose is to watch upstream for a new version. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting openswan 2.2.0 back into sarge
Rene Mayrhofer wrote: Hi all, [Please CC me in replies, I am currently not subscribed to this list.] As some have already noticed, openswan has been removed from testing a while ago, most probably because of bug #291274, which did not apply to package version 2.2.0-4 (the one that has been removed from testing). As 2.3.0 You should have tagged the RC bug Sid. upstream is currently not production quality (this is my personal opinion, since it basically triggers a DoS on 2.2.0 installations, cf. #292132), I did Doesn't this mean that 2.2.0 is NOT release quality? It is a security problem if you can trigger a DoS on a package. not work on getting it into testing. Of course, I have to admit that I have been lazy in not filing a RC bug report to prevent it from entering testing and fixing this bug. However, it looked like 2.3.1 might get released soon at that time, so I had decided to wait for it and push it into testing as soon as the new upstream is there. At the moment, 2.3.1 is nowhere to be seen and I would really like to have a working (and not DoS-triggering) openswan in testing. My current intention would be to get 2.2.0-4 back into testing, which worked well in all of my own tests (I am still using that particular version on many production boxes) and does not seem to be broken for other users. What is the general opinion on that? The first step is to remove the current version from testing if it is not production quality. The second step is to locate the DoS problem in 2.2.0 The final step is to upload 1:2.2.0 or similar to unstable and wait for it to get to testing. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#301083: ITP: libevolution-ruby -- revolution, ruby binding for the evolution mail client
David Moreno Garza wrote: On Thu, 2005-03-24 at 17:31 +, Henning Makholm wrote: Scripsit David Moreno Garza [EMAIL PROTECTED] Revolution is a little Ruby binding to the excellent Evolution email client. Is it so little that it would be better to include it with the evolution package? Not quite sure since: a) evolution, IMHO, doesn't need to depend on ruby. b) It is a 3rd-party software, not included officially by Novell. c) It is a ruby module itself, just as other several hundreds. But if evolution's maintainer thinks it could be a good idea (I don't), we can implement it in the near future, yes. With regards to a), I don't think you need to depend on ruby at all. The reason is that the ruby bindings are only available for programs running in a ruby interpreter (AFAIK). Thus, if you want to *use* the ruby bindings, you then install ruby. If you do not install ruby, you do not need or use the ruby bindings. For example, if you package a libfoo package that is a C library, and libfoo-dev contains the static part of the C library, then there is no need to have libfoo-dev depend on the C compiler. Anyone that *uses* the libfoo-dev library will need to install a C compiler regardless. Thus, libevelution-ruby doesn't need to depend on Ruby. It only needs to depend on evolution. - Adam PS. It may need build depend on ruby, rake, etc.. , but that is different. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
