Re: DEP17 /usr-move: debootstrap set uploaded
Marc Haber writes: > Helmut Grohne wrote: >> Thanks for bearing with me and also thanks to all the people (release >> team and affected package maintainers in particular) who support this >> work. > Thank you for doing this work. I have rarely seen a change of this > magnitude in Debian that was managed on this professional level. I > especially praise the way you have communicated the progress. 100% agreed. The care and excellence that you've brought to this work has been exceptional. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: File descriptor hard limit is now bumped to the kernel max
Simon McVittie writes: > On Thu, 06 Jun 2024 at 18:39:15 +0200, Marco d'Itri wrote: >> Something did, because inn would start reporting ~1G available fds and >> then explode, and that patch solved the issue. :-) > It might be worthwhile to try to track down what larger component did > this, because inheriting a larger rlim_cur without opt-in can also break > users of select(2) as described in > <https://0pointer.net/blog/file-descriptor-limits.html>. I took a quick look at the old INN source and didn't see anything obvious. I was half-expecting it to do something like set the soft limit to the hard limit (that sounds like a very INN sort of thing to do), but if so, I couldn't find it in a quick search. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: About i386 support
r...@neoquasar.org writes: > Then it's not a problem in the first place. If you can't reproduce a bug > with a reasonable effort, then it is unconfirmed and you can stop > worrying about it. I think you're confusing two different types of reproduction. Architecture porting bugs are often hardware-specific. The bug may be 100% reproducible on that instance of the architecture, an instance that you do not own and do not have access to. So the package is reliably broken for a user trying to use that architecture, and yet the porter has limited ability to triage or debug it because they don't have access to that architecture. This is one of the reasons why projects (not just Debian) drop support for architectures. Once the *maintainers* no longer have easy access to instances of that architecture, it's very hard to support, even if users keep trying to use that architecture and run into problems that are reproducible for them. That's the first hurdle. The second hurdle you then run into is that frequently the cause of these problems is deep inside the compiler, the kernel, or some other complex piece of upstream code. There are a very limited number of people who have the ability to track down and fix problems like that, since they can require a lot of toolchain expertise. It's not a simple thing to commit to doing. Debian relies fairly heavily on a whole ecosystem of upstream developers to do a lot of the difficult work for supporting architectures, including the kernel, GCC, binutils, etc. If that ecosystem stops supporting architectures, it will be very difficult for Debian to keep support, and doing so usually requires the people interested in keeping those architectures working to also become upstream kernel, GCC, etc. developers. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Reviving schroot as used by sbuild
Simon McVittie writes: > Persisting a container root filesystem between multiple operations comes > with some serious correctness issues if there are "hooks" that can modify > it destructively on each operation: see <https://bugs.debian.org/499014> > and <https://bugs.debian.org/994836>. As a result of that, I think the > only model that should be used in new systems is to have some concept of > a session (like schroot type=file, but unlike schroot type=directory) > so that those "hooks" only run once, on session creation, preventing > them from arbitrarily reverting/overwriting changes that are subsequently > made by packages installed into the chroot/container (for example dbus' > creation of the messagebus uid/gid in #499014, and exim4's creation of > Debian-exim in #994836). I'm not entirely sure that I'm following the nuances of this discussion, so this may be irrelevant, but I think type=btrfs-snapshot provides the ideal properties for container file systems. This unfortunately require file system support and therefore cannot be used unless you've already embraced a file system with subvolumes, but if you have, you get all of the speed of a persistent container root file system with none of the correctness issues, because you get a fresh (and almost instant) clone of a canonical root file system that is discarded after each build. I use that in combination with a cron job to update the source subvolume daily to ensure that it's fully patched. Unfortunately, there's no way that we can rely on this, but it would be nice to continue to support it for those who are using a supported underlying file system already. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Reviving schroot as used by sbuild
Guillem Jover writes: > I manage my chroots with schroot (but not via sbuild, for dog fooding > purposes :), and use type=directory and union-type=overlay so that I get > a fast and persistent base, independent of the underlying filesystem, > with fresh instances per session. (You can access the base via the > source: names.) I never liked the type=file stuff, as it's slow to > setup and maintain. Ah, thank you, I didn't realize that existed. That sounds like a nice generalization of the file system snapshot approach. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Reviving schroot as used by sbuild
PICCA Frederic-Emmanuel writes: >> Ah, thank you, I didn't realize that existed. That sounds like a nice >> generalization of the file system snapshot approach. > I think that this how the > sbuild-debian-developer-setup > script, setup chroots Yeah, I think all that my contribution to this thread accomplished was to demonstrate that I set up sbuild years ago based on a wiki article for btrfs and don't know what I'm talking about. :) Apologies for that. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Q: Ubuntu PPA induced version ordering mess.
Alec Leamas writes: > So, at least three possible paths: > 1. Persuade users to uninstall PPA packages before installing official > packages and also generation 2 PPA packages with sane versions like > 5.10.x > 2. Use versions like 9000.5.10, 9000.5.12. etc. > 3. Use an epoch. > Of these I would say that 1. is a **very** hard sell upstream. Users are > used to just update and will try, fail and cause friction. > 2. and 3. both adds something which must be kept forever. Given this > choice I tend to think that the epoch is the lesser evil, mostly because > the package version could match the "real" version. I would use an epoch. It sounds like the PPA was in serious use by the intended users and they're going to be switching to your packages. You are trying to make that easy and avoid obvious and easily-forseen problems and I think that's good: that's exactly what a maintainer should do. If it were just a handful of people you could walk through the transition, that's maybe different, but it sounds like that's not the case. 2 is a hard sell to upstream for psychological reasons. Maybe it shouldn't be, maybe upstream should be fine with this, but as you say upstream in practice isn't going to be fine with this and honestly if I were upstream I probably wouldn't be either, even if I knew I should be. It's hard enough to get people to use version numbers properly. Getting them to use a "weird" version number that their users might be confused by for the rest of time is going to be difficult. Changing the version number only in Debian is even worse: that's just horribly confusing for users and will be forever. And the confusion is going to affect upstream as well. Basically, you'd be burning a lot of social capital with upstream for no really good reason and you probably still wouldn't be able to convince them. I don't think it's worth it. I would just use the epoch. I know people really hate them and they have a few weird and annoying properties, but we have a bunch of packages with epochs and it's mostly fine. It's something you'll have to keep working around forever, but not in a way that's really that hard to deal with, IMO. (I would also warn upstream that you're doing that, so that they know what the weird "1:" thing means in bug reports in the future and why it's there.) This feels like exactly the type of situation that epochs were designed for: upstream was releasing packages with weird version numbers and now they're effectively going back to normal version numbers that are much smaller. In other words, to quote policy, "situations where the upstream version numbering scheme changes." Yes, in this case it was only in their packages and not in their software releases, but that still counts when they have an existing user base that has those packages installed. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Bug#1075905: ITP: python-fraction -- Fraction carries out all the fraction operations including addition, subtraction, multiplication, division, reciprocation
Yogeswaran Umasankar writes: > As I look further, it appears that standard Python libs such as float or > decimal.Decimal do not provide exact representation of rational numbers > (fractions) without potential loss of precision. Seems ‘fraction’ > package yield exact results because those functions directly work on > fractions (to my limited understanding). > decimal.Decimal is better than float, but it only extends to arbitrary > precision decimal arithmetic, not exact representation of rational > numbers. Given that these libraries could potentially serve as > dependencies for tensor-related packages and beyond, should we consider > bringing 'fraction' or restrict ourselves to float (which is a fallback > in moarchiving if fraction unavailable)? I think the suggestion is to use the Python standard library package "fractions" specifically: https://docs.python.org/3/library/fractions.html -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: RFC: Sensible-editor sensible-utils alternative and update
Simon McVittie writes: > The approach to this that will work consistently is to launch the > handler asynchronously (in the background), and not attempt to find out > whether it has exited or not. So for example an interactive shell script > might do something like this: > #!/bin/bash > # note that disown is a bashism > xdg-open "$document" & > disown $! > echo "Press Enter when you have finished editing $document..." > read What this is telling me is that ideally someone should tighten the definition of EDITOR in Policy 11.4, which is the specification satisfied by sensible-editor, to make it clear that GUI editors with these sorts of properties are not valid things to set EDITOR to point to unless flags are present to make them behave in a way that satisfies the expectations of programs that use EDITOR. I don't have any strong opinion on the merits of trying to figure out how to invoke the editor with the proper flags to make it follow the expectations of EDITOR if EDITOR is not set, but we do need to be careful to not invoke programs that would cause, e.g., git commit --amend to immediately exit with no changes to the commit message, and to do that we probably need to write down what those expectations are. I think the Policy language was written in a time where we just assumed there was an obvious way for editors to behave that didn't include things like backgrounding themselves. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Accepting DEP14?
Chris Hofstaedtler writes: > "latest" is illnamed. What do you expect to find in a branch thats > called debian/latest? > Packaging for unstable? For experimental? What if both evolve in > parallel? Yes, some packages do that. We discussed this a lot during the drafting of DEP14, and the reason why the standard allows either convention is that it depends on the package and there were two separate perspectives with no consensus that one was universally better. Maintainers of some packages that upload to unstable except during freezes, during which they temporarily move into experimental, but consider it the same line of development, and then move back into unstable after the release preferred debian/latest since it matched how they thought about the line of development. People who maintained separate unstable and experimental lines of development preferred debian/unstable and debian/experimental. Personally, I use debian/unstable but do experimental development in that same branch if it's "targeting unstable," which is either the best or worst of both worlds, depending on your perspective. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: RFC: packages that can be installed by the user but not used as build dependencies
Lisandro Damián Nicanor Pérez Meyer writes: > So, what about if we could have [meta] packages that can be installed by > the user but not used as Build-Depends entries? Please note that for the > moment I'm targeting more at the idea itself rather than at the > implementation (but I'll certainly love to know if you have an idea on > how could this be implemented). > At one point I thought of adding a Lintian test checking for this kind > of usage, but first and foremost I would like to know if you think this > is a viable/acceptable idea, maybe even adding a special section in our > policy. I could have sworn that we already had tags like that in Lintian. Certainly, this is a concept that has already existed in Debian for some time. There have always been metapackages or other similar cases that are only intended for end users and would make no sense as build dependencies, such as all of the task-* packages. Lintian feels like the right place to put a test like this. If there are dependencies like that which could potentially cause serious issues, those could even be an auto-reject tag. I'm not sure that Policy would have much to say about this unless we need some mechanism for labeling such packages other than a MR to Lintian. The important information is the list of packages that shouldn't be used this way, and the hard part is probably gathering that list. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Representing Debian Metadata in Git
Chris Hofstaedtler writes: > My *feeling* is we should do the opposite - that is, represent less > Debian stuff in git, and especially do it in less Debian-specific > ways. IOW, no git extensions, no setup with multiple branches that > contain more or less unrelated things, etc. +1 I think this is particularly important for attracting new contributors and easing the onboarding process. There are a lot of odd Debian-specific things that people have to learn because they're necessary to make Debian work. I am dubious that the Git representation is one of them, and would rather continue down the path of providing Debian tools and processes that reduce the delta between how Debian packaging uses Git and how most free software development uses Git. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Validating tarballs against git repositories
Otto Kekäläinen writes: > On Tue, 2 Apr 2024 at 17:19, Jeremy Stanley wrote: >> On 2024-04-02 16:44:54 -0700 (-0700), Russ Allbery wrote: >> [...] >>> I think a shallow clone of depth 1 is sufficient, although that's not >>> sufficient to get the correct version number from Git in all cases. >> [...] >> >> Some tools (python3-reno, for example) want to inspect the commits >> and historical tags on branches, in order to do things like >> assembling release notes documents. I don't know if any reno-using >> projects packaged in Debian get release notes included, but if they >> do then shallow clones would break that process. The python3-pbr > You could use --depth=99 perhaps? > Usually the difference of having depth=1 or 99 isn't that big unless > there was a recent large refactoring. Git repositories that are very > big (e.g. LibreOffice, MariaDB) have hundreds of thousands of commits, > and by doing a depth=99 clone you avoid 99.995% of the history, and in > projects where changelog/release notes is based on git commits, then > 99 commits is probably enough. I suppose that's *possible*, but I'd want to see some concrete survey evidence to support that. I'm fairly sure that 99 would be insufficient to build a change log on some of my small packages for which I'm a single developer in all cases, let alone a project with any significant commit volume and a policy of separating unrelated changes into separate commits. My guess is that the sweet spots are --depth=1 and a full checkout, it's not generally possible to tell which a given package needs in advance (in other words, it's best handled as a configuration option), and it's probably not worth the effort to mess around with any intermediate depth. I suspect we'll find that the vast majority of packages work fine with --depth=1, and the remaining cases should just use a full checkout to avoid creating fragile assumptions that may work today and break tomorrow. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Linux Core Consortium
Bruce Perens <[EMAIL PROTECTED]> writes: > You use the LCC version available to you at the time you release, > whatever that is. It may make sense for you to schedule your release to > come some months after the LCC's, but I can't see that you have to do > everything modulo 18 months. I think this is a hideously bad idea, and I say this as a representative of an institutional user of Debian that has been hurt by the lack of ISV support. Having Oracle support Debian would be great, but not if it comes at the cost of Debian's ability to make its own fixes and releases of core libraries and toolchain components. One of the reasons why we chose Debian in the first place is that the packages that come out of the Debian project are simply higher quality, in large part because they themselves are maintained in an open-source fashion rather than as proprietary packages maintained by single vendors controlled by commercial and economic restraints. If I wanted Red Hat's broken libc maintenance process, I know where to find it. We explicitly chose Debian because it's *better* than Red Hat in the core system maintenance that we care about. I think that tying core Debian packages to the Red Hat boat anchor is a horrible, horrible idea. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Re: removing in postrm rc*.d symlinks that I did not create
Nicolas Boullis <[EMAIL PROTECTED]> writes: > A package of mine installs an init script. But as the corresponding > programs plays with the motherboard's chipset configuration, it is quite > prone to break the system. So I chose not to install rc*.d symlinks by > default. A technique that I've used in packages with this issue is to install the rc*.d symlinks by default, but also have the init script check a file in /etc/default to see whether or not to actually start at boot. If you install a default /etc/default file that says not to start, you accomplish the same thing, don't have this problem, and make it just as easy for users to enable the package. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
Andrew Suffield <[EMAIL PROTECTED]> writes: > On Thu, Feb 17, 2005 at 09:04:59PM -0600, Donald J Bindner wrote: >> When you compile a kernel and check the help on a module, you'll >> never find "If unsure, don't say Y." Something to think about... > That's because the string is "If unsure, say N". > [EMAIL PROTECTED]:/usr/src/linux-2.6.10$ grep unsure * -r | grep Kconfig | > egrep -c "say '?Y" > 148 > [EMAIL PROTECTED]:/usr/src/linux-2.6.10$ grep unsure * -r | grep Kconfig | > egrep -c "say '?N" > 366 > So much for that theory. Testing it took no more than a couple of > minutes; you could have done that yourself and saved us all the time > of a couple of mails. I think you may have missed Donald's point. As I read his original message, you're confirming exactly what he was trying to drive at. "If unsure, don't say Y" feels awkwardly backwards to me as well, compared to "If unsure, say N." Both sentences are, of course, logically equivalent if there are only two options, but I have to go through a small bit of additional processing to understand what I should do when presented with the first phrasing, and it leaves me with a vague wondering if I missed some other third choice. That's not even getting into the valid point raised by someone else, namely that it's unfortunately easy to read right past the "don't" in the "if unsure, don't say Y" phrasing. My eye, if I'm in a hurry, picks up on "unsure" and "Y" in that sentence and I can easily see myself not paying close enough attention to parse and understand all the connecting words. Certainly, that's my problem for not being attentive enough, but it's worth making it easier on the poor sap in a hurry. That effect is even worse when the phrasing is more drawn-out, like "If X, you should not say Y." -- 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: dehs will stop
Lars Wirzenius <[EMAIL PROTECTED]> writes: > Denial of service attacks on the bug tracking system, on mailing lists, > mail servers, and maintainers is unappreciated. 6229 bug reports would > result in all sorts of unnecessary and unwanted load on all sorts of > systems and people. It is because of reasons like these that mass-filing > of bugs must always be discussed on debian-devel beforehand, so that the > utility of the bug reports can be weighed against the load and > disruption they cause. > In this situation, I think it is clear that filing 6229 *wishlist* bugs > is completely unwarranted. Wouldn't it be a lot easier, if there is consensus that having a watch file is the right thing to do, to add it as a lintian warning? That seems like a far lower-impact way of notifying 6,229 package maintainers. One problem with either approach (although somewhat less so for filing bugs if someone is carefully hand-checking each one) is that there are packages in Debian that are based on an upstream release that's completely dead or unsuitable for further tracking for some reason. For such packages, the watch file is actually counter-productive, since it implies some ongoing relationship to the original upstream release that isn't accurate. -- 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: [RFC] OpenLDAP automatic upgrade
Clint Adams <[EMAIL PROTECTED]> writes: > If there were anything besides FUD, I'd consider it on its own merits, > but all I've seen thus far is an anecdote that OpenLDAP has trouble with > some version of db4.3 on some platform because of some undescribed flaw > related to the log format change. There does not appear to be a report > in the Debian BTS about this problem. You should probably bear in mind that the problem was judged by the OpenLDAP maintainers to be sufficiently severe that they removed db4.3 from their supported db version list in the latest release of OpenLDAP. That's a bit more than FUD, although I agree that it's not specifics. I agree that it's unclear at the moment whether the problem is unique to OpenLDAP or whether other applications would encounter the same problem. -- 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: RFC: drop kerberos4-support?
Brian May <[EMAIL PROTECTED]> writes: > Ideally that would be "AFS environment that our users require". > However, I would be happy is that was "AFS environment that will work > without recompilation of Debian packages". Right now, the AFS packages in Debian will work with either native K4 or with krb524, although the server support for native K4 isn't in Debian. > My preference would be native K5. > However, I get the impression that isn't yet possible with openafs in > Debian (unless I am badly confused). You're correct, although it's very close. It will be possible with the 1.4.1 release (and is almost possible right now but openafs-krb5 is too old; I'm waiting for the 1.4.1 release to retire the openafs-krb5 package and package aklog and asetkey with openafs). So it will be possible for etch. The aklog in openafs will also support krb524d. However, dropping KTH Kerberos loses the ability to work with native K4 easily because of afslog (klog would still be available, as would the PAM modules, but not something that worked from a K4 ticket cache). We're already building our own version of afslog for K4 at Stanford, though, so I'm not sure how much that would really impact anyone and what sites (if any) would be affected. > So if using krb524 works, then hopefully that would be OK. > (when I last tested it I couldn't get it to work with anything except > krb4 support in the KDC, but I may have been doing something wrong...) README.servers in the openafs-fileserver package explains how to set up OpenAFS with Kerberos v5 authentication via krb524d, and at least with the packages in sid it's been fairly well-tested. The setup scripts needed a bit of work that I just recently finished. -- 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: RFC: drop kerberos4-support?
Brian May <[EMAIL PROTECTED]> writes: >>>>>> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes: > Russ> You're correct, although it's very close. It will be > Russ> possible with the 1.4.1 release (and is almost possible > Russ> right now but openafs-krb5 is too old; I'm waiting for the > Russ> 1.4.1 release to retire the openafs-krb5 package and package > Russ> aklog and asetkey with openafs). So it will be possible for > Russ> etch. The aklog in openafs will also support krb524d. > I can't seem to find it in my version ;-( Are you looking at the original upstream source? aklog isn't included in the openafs packages in Debian because openafs-krb5 still contains aklog. That's one of the things that will change in the 1.4.1 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]
Re: Spliting packages between pkg and pkg-data
Nicolas Boullis <[EMAIL PROTECTED]> writes: > On Sun, Nov 20, 2005 at 12:13:48PM +0100, Bill Allombert wrote: >> 3) Keep the files that 'signal' executables in the same package than the >>executable (e.g. menu file, program manpage). > Why? I agree that it menu files and manpages are generally not that > large, but what would it break to have them in pkg-data? > (I would consider it strange to have such files out of the main pkg > package, but it looks policy-compliant as far as I can see...) Well, one practical concern is that it makes it harder for other utilities like lintian to analyze the package properly. -- 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: Spliting packages between pkg and pkg-data
Nicolas Boullis <[EMAIL PROTECTED]> writes: > On Sun, Nov 20, 2005 at 12:39:24PM -0800, Russ Allbery wrote: >> Well, one practical concern is that it makes it harder for other >> utilities like lintian to analyze the package properly. > Well, that's an argument I don't like. Those are tools that help us > check our packages are correct, but I don't think it is reasonable to > modify otherwise correct package only to make such tools happy. For the > same reason, I'm not happy with setting lintian overrides, as I consider > it bloats the packages for no good reason (although the "bloat" is very > limited"). Sure, ideally lintian would be able to cope with any packaging practice that actually works. However, this is a lot like coding standards in a programming language. There's a lot of evidence to indicate that following standards that are more restrictive than the language actually requires can make it easier to find bugs and detect problems, even though it isn't necessary and there are times for exceptions. I think lintian is one of the best things about Debian since it lets one catch a multitude of problems that are otherwise difficult to detect and easy to forget to look for. Using any sort of lint tool is always a bit of a tradeoff, though, since there will always be things that are correct but impossible for the lint tool to analyze for one reason or another. lintian's particular flaw is that it can't do most forms of interpackage analysis, so one has to provide all the details it needs to do its job in a single package whenever possible. In the absence of any compelling reason why something *needs* to go in another package, it therefore makes sense to me to keep it together to make life easier for QA tools. But then, I'm a big believer in lint, -Wall, and similar checking tools, up to and including minor modifications to my coding or packaging style to avoid false positives. I think the tradeoff is more than worth it; the more effective I can help the lint tools to be, the more consistently high-quality my packages are. -- 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: cvs loginfo configuration for alioth?
It seems like folks have found good solutions for their problems already, but just for the hell of it, I thought I'd mention that I maintain a CVS commit reporting script mostly because the other ones I'd found didn't seem to do quite enough or were poorly documented. It's at: <http://www.eyrie.org/~eagle/software/cvslog/> and while I've not used it specifically with Alioth, I'd be happy to respond to any reports of issues or requests for additional features. (I know the option handling needs some improvement; I plan on rewriting it shortly to use the same approach that my similar svnlog program for Subversion uses.) -- 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: buildd administration
Ingo Juergensmann <[EMAIL PROTECTED]> writes: > Please stop assuming wrong facts. > As I already stated several times before: Ryan was offered to integrate > the buildd.net software. He declined with the argument that all > information is already available on buildd.d.o. That's a clear sign that > he doesn't want to integrate it. Blame him, not me. And where is the > source for buildd.debian.org? If you want to replace an existing infrastructure, you have to clearly demonstrate that the new stuff is better. Saying that it's okay that the new stuff isn't publically available because the old stuff isn't either doesn't help the cause any. Also, it's somewhat ironic that, in a thread where much has been made of how overloaded the existing buildd administrators are, the offer of the buildd software was made privately to one of those overloaded individuals. (And were they then allowed to make it public?) C'mon, this is a free software project. The obvious first step for providing better infrastructure would be to make that infrastructure publically available for anyone to download, play with, hack on, or otherwise evaluate, whether the existing infrastructure component is similarly available or not. I'd think this would just be common sense. -- 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: buildd administration
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > Russ Allbery <[EMAIL PROTECTED]> writes: >> C'mon, this is a free software project. The obvious first step for >> providing better infrastructure would be to make that infrastructure >> publically available for anyone to download, play with, hack on, or >> otherwise evaluate, whether the existing infrastructure component is >> similarly available or not. I'd think this would just be common sense. > You can test and play around with buildd.net all you want and easily see > "its superiority". You can also contact Ingo and ask him for the > scripts, as I have done, and you may recieve them. Something that I > found impossible for buildd.d.o. > Ingo is offering a service and paying for it. That he isn't throwing the > source at anyone casualy stumbling accross his site should hinder anyone > intrested. I wholeheartedly approve of the decision to decline to use the software of people with this attitude towards free software as part of the core Debian infrastructure. It's one thing to have the source diverge due to lack of time, but the above rings TONS of MAJOR warning bells for me. It sounds very much like the sort of conversation that I get into with vendors who are trying to say they do "open source" without actually doing anything of the sort. Much of what we do here is *exactly* about throwing the source at anyone casually stumbling across our site. -- 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: buildd administration
Anthony Towns writes: > Since this point obviously needs to be made clearer, I guess it's time > to have some more rounds of removing packages that have long outstanding > RC bugs. I guess I'll coordinate with the RM team to do this sometime > over Christmas/New Year. (The following comment should not in any way be read as referring to Thomas's packages.) Please look at orphaning them before just removing them. In many cases, other people may be willing to pick up the package had they been aware that it needed more attention. There are unfortunately a lot of RC bugs right now, partly due to the documentation licensing issues, whereas the list of orphaned packages is much smaller and easier to look over. -- 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: buildd administration
Michael Banck <[EMAIL PROTECTED]> writes: > There are currently no public build logs for hurd-i386, but we are > working on getting them published on experimentel.ftbfs.de as well. If you can get them into <http://people.debian.org/~igloo/status.php>, that would be wonderful. I read that page religiously for my packages and will investigate and attempt to fix any problem that shows up there. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Packages-arch-specific (was: Sparc build failure analysis)
Steve Langasek <[EMAIL PROTECTED]> writes: > On Sat, Dec 10, 2005 at 06:53:47AM -0800, Blars Blarson wrote: >> Again: what can I do with such a list? See the list below. > Changes to the P-a-s list should be sent to the contacts listed at the top > of this file (http://buildd.debian.org/quinn-diff/Packages-arch-specific). I have to admit that this is the one area of the buildds that I've found a little frustrating and/or confusing due to lack of communication. I co-maintain openafs, which builds a variety of arch-specific packages plus an arch-independent package with the kernel module source. OpenAFS upstream does not support arm, m68k, mips, or mipsel. It's highly unlikely that it will *ever* support those architectures; the kernel integration is non-trivial to do, and I've never heard from users of those architectures who are particularly missing AFS. (AFS is a little heavy-weight for the sorts of things that people usually do on those architectures, I think.) Now, the openafs package does immediately fail with a reasonable error message on the unsupported architectures and tags all the binary packages as only being applicable to supported arches, but it feels like a waste, every time I upload a new openafs package, for it to go into those architecture queues, make the buildds download and install all the dependencies, and start trying to build, only to have it fail. It's always going to fail, I know it's always going to fail, and while this isn't a huge waste of resources, it's at least a little waste. So I followed the instructions at the top of that file and requested a P-a-s entry, after asking people here what to do. No response. Hm. I wasn't sure what to make of that -- maybe this request is too trivial to bother with, it's fine for the builds to fail, and I should just ignore it? Or maybe my e-mail wasn't received? Or maybe I misunderstood something and this was the wrong channel or the wrong thing to do? I waited a while (my saved mail says two months) and asked my AM about it. He said that mailing them again was probably the right thing to do. So I went ahead and did that, providing the specific entry that I think should be used. No response (that was in August). However, I notice in the build report that m68k is now marking openafs as "not for us" (but the other arches aren't). Is this because of my mail? Because the buildd administrator noticed the error message? This is a really minor issue in the grand scheme of things. It's not RC, it doesn't break anything, it's really mostly cosmetic plus a minor resource waste. Now I'm feeling kind of guilty about bothering clearly busy people with a trivial request, and I probably really shouldn't send this message to debian-devel either, since certainly it's not any kind of serious problem that this hasn't been done. But I really want to learn. I want to understand what the right thing to do is. It kind of bugs my (probably overactive) sense of neatness to see openafs sit in those build queues and then fail rather than cleanly being skipped. If I should just stop bugging people, I'm happy to do that, but I'd heard from a few other people who seemed experienced that this is what I should do, so it would be nice to get a message that explicitly says "stop bugging us." Or, well, anything. Certainly I don't expect such a message even within a month for this sort of low-priority request; it takes me that long to get to my mail too. But Maybe the right thing to do would be to work out a way for package maintainers to provide input to their own P-a-s entries in some sort of automated fashion? It does seem like a package maintainer is generally going to know this sort of thing, and I hate to bother busy buildd maintainers with this kind of thing if I could do it myself. -- 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: buildd administration
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > Ok, lets take an example: Where is the source thrown at you for > www.debian.org? > It isn't. You have to ask around, get to know or dig deep along the > links to find cvs.debian.org. Funny, I just did a Google search for site:www.debian.org cvs repository www.debian.org and there it was, plain as day. > Ingo and I wanted to improve the (still non public) buildd.d.o scripts > and were rejected with "All the info is already there". That is why > buildd.net now runs the scripts. The warning bells ring with buildd.d.o, > not buildd.net. > And yes, the buildd.net scripts are now closed sourced if you will. But > the offer to open them up, to integrate them into and improve buildd.d.o > was made long before that and still stands. See, what you keep missing is that, regardless of the willingness of the current buildd maintainers to work with you, you are using the openness or not of your work as a bargaining point. I have serious philosophical problems with that. Until such time as the proposed new infrastructure is *actually* free software, as opposed to a bargaining chip, I personally consider your objections invalid and completely support the decision of the buildd team. Even if the current software isn't publically available for whatever reason (personally, I'm putting my money on "hacked into place over time and not particularly easy to massage into a form someone else could run," but who knows), if you want to make an argument that your stuff is better, you have to actually release it as free software as far as I'm concerned. It's the minimal bar to meet, and it's not even interesting to have a conversation with you about it until you meet that bar. -- 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: Packages-arch-specific
Steve Langasek <[EMAIL PROTECTED]> writes: > Right, well, as noted, it's generally a fairly low priority to get > packages added to P-a-s -- even though it's an eventual goal, the waste > just really isn't so much (in the usual case) to warrant a rush job. So > from that standpoint, as long as there is quite such the backlog on > P-a-s that there is (from what I can see), it seems like something > maintainers should also give a pretty low priority to. Yeah, that makes sense. I agree with the other message that having something in the BTS for this is probably a good idea. That way, one knows the message has been received and is in a queue somewhere and that people will pick it up when they get a chance, or if it really belongs somewhere else, they can easily transfer it or close it or what have you. > Anyway, you could always try throwing this in Adam's direction as well > now that he's listed as a co-maintainer of the file. I noticed that just as I was sending the last message and may do that. > Well, except between the time you wrote this message and the time I'm > drafting a reply to it, I've filed/upgraded at least three bugs about > packages wrongly limiting themselves to Architecture: i386; and I'm sure > there are plenty more out there in the packages I haven't looked at yet. > Skills do vary among maintainers, and especially among novice > maintainers there's certainly a tendency to mark packages as > arch-specific when they shouldn't be. If P-a-s were being updated > automatically based on whatever the maintainer thinks should be there, > it would've been substantially harder to find these bugs. Oh, hm, yeah, good point. I wasn't thinking to base it on the control file so much as letting the maintainer send a PGP-signed message somewhere to change it, but either way, that's a concern. -- 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: congratulations to our ftp-master team
Steinar H Gunderson <[EMAIL PROTECTED]> writes: > I don't know the details of the three longest-running packages, but I > assume you asked an ftpmaster about those? Patent issues around video codecs, discussed on debian-devel ad nauseam over the past few years. It would be nice to eventually get some resolution on this, but it's a known thorny licensing issue and isn't the easiest thing to work through. -- 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: congratulations to our ftp-master team
A Mennucc <[EMAIL PROTECTED]> writes: > BTW: I know that 'mplayer' has always been fishy business in Debian > but what did 'xvidcap' ever do wrong? AFAICT the only problem may be > that 'xvidcap' contains FFMPEG code ; but FFMPEG has been in Debian for > quite long now, so I do not really understand what is going on here. People explained a long time ago why this isn't a good argument, and it's kind of frustrating to have people continually asking for a repeat of it. The existence of a package in Debian is not proof that the package is okay to distribute for Debian. We do actually make mistakes, including mistakenly allowing packages into Debian that turn out not to have distributable licenses. It happens all the time. Assuming that what you say above is correct and FFMPEG is the only issue (and I have no reason to doubt you), I agree that xvidcap and ffmpeg should be treated the same. However, that is not evidence that xvidcap should be in Debian -- it's evidence that they should be treated the same. Perhaps the correct thing to do is file an RC bug on ffmpeg and get it removed from the archives. I don't know. When one doesn't know, the right thing to do is frequently both not make the problem worse and not overreact, meaning leaving ffmpeg in the archive and xvidcap in NEW until the situation is clearly understood and resolved is quite reasonable. Of course, we do need to eventually actually get the situation resolved and come to a conclusion, after which either both should be in the archive or neither should. But the current situation of having one in the archive and one not during a hazy patent/license issue is *not* evidence of someone doing a bad job. It is evidence of an incomplete job, which I think everyone, including the ftp-masters, would agree with. -- 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: buildd administration
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > Russ Allbery <[EMAIL PROTECTED]> writes: >> Funny, I just did a Google search for >> site:www.debian.org cvs repository www.debian.org >> and there it was, plain as day. > That implies that you already know/suspect it is in cvs. Goswin, with all due respect, you really either have no idea what you're talking about here or you're rather bad at using Google. A search on: site:www.debian.org repository www.debian.org despite being for very generic terms turns up a page explaining the CVS repository for www.debian.org in the third page of results. Yes, you have to pick some good search terms, since finding the pages that are about developing the Debian web pages rather than finding pages that are about developing for Debian is tricky. But that's just part of using a search engine. >> See, what you keep missing is that, regardless of the willingness of >> the current buildd maintainers to work with you, you are using the >> openness or not of your work as a bargaining point. I have serious >> philosophical problems with that. > Where did I ever say "We must use this because it is free?" You didn't. If you were saying that, I'd actually have more respect for your position. You are instead saying "our stuff is proprietary and we'll only release the source if the buildd.debian.org maintainers agree to play ball." That's deeply messed up, and as far as I'm concerned that stops the conversation cold. I don't care how messed up the current stuff is -- I'm very nervous about software written by someone with that attitude coming anywhere near Debian core infrastructure. > Both buildd.d.o and buildd.net are in exactly the same state regarding > openness: You have to ask the maintainer for the scripts personaly. And that's not sufficient for any replacement. I don't think it's great for the existing scripts either, but they have a few huge advantages: they're already in place and they're already working. If we're looking at giving up those advantages and replacing them with something else, then the *least* that the new stuff should do is be free software. > My argument is that is has better functionality not better idiology. If you want more people to support your argument, produce better ideology too. Otherwise, you can keep whining about this on debian-devel until the end of time and as far as I'm concerned the right thing for everyone involved in Debian to do is ignore you. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Access to svn.debian.org
Okay, I'm stymied and I'm not sure where to ask. I had an Alioth ID rra-guest from before I was approved as a Debian developer, and I can use it to access the pkg-perl repository on svn.debian.org without any trouble. When I became a Debian developer, I got a new Alioth ID rra. It's now also been added to the pkg-perl repository. But it doesn't work with svn.debian.org. Using the Alioth password for that account just results in rejected authentication. I've set a public key in Alioth for the account but that doesn't seem to change anything. (Whereas with rra-guest, setting a public key in Alioth worked great and now I can use public key authentication to svn.debian.org.) What am I doing wrong? Is there someone in particular I should contact for help? I'd like to switch my project memberships and other Alioth data over to rra from rra-guest, but this is making that impossible. Thanks in advance! -- 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: Access to svn.debian.org
Clint Adams <[EMAIL PROTECTED]> writes: >> developer, and I can use it to access the pkg-perl repository on >> svn.debian.org without any trouble. When I became a Debian developer, I >> got a new Alioth ID rra. It's now also been added to the pkg-perl >> repository. But it doesn't work with svn.debian.org. > Assuming nothing is wrong, you may need to wait up to 24 hours for that > to take effect. Hm, I *thought* it had been several weeks already, actually. But maybe I'm confused and I just got added and I'm misremembering thinking that was done a while ago. -- 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: congratulations to our ftp-master team
Anand Kumria <[EMAIL PROTECTED]> writes: > A simple assurance that your package will be rejected from the NEW queue > if no ftp-master approves it within 2 weeks would actually be a benefit. Why? It seems like, if that's the way that you want the world to work, you could already just pretend that this is the case. If your package has gone for more than two weeks, it seems to me like you could decide to treat it in all respects as if it had been rejected and just go on with your life. If it ends up getting accepted, you could orphan it, or decide to pick it up again. -- 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: congratulations to our ftp-master team
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Russ Allbery <[EMAIL PROTECTED]> writes: >> Anand Kumria <[EMAIL PROTECTED]> writes: >>> A simple assurance that your package will be rejected from the NEW queue >>> if no ftp-master approves it within 2 weeks would actually be a benefit. >> Why? >> It seems like, if that's the way that you want the world to work, you >> could already just pretend that this is the case. If your package has >> gone for more than two weeks, it seems to me like you could decide to >> treat it in all respects as if it had been rejected and just go on with >> your life. If it ends up getting accepted, you could orphan it, or >> decide to pick it up again. > When the ftp masters reject a package, they say why it has been rejected > as a rule. So at least that part can't be substituted for in this way. Yes, but that's a different conversation. Anand didn't say anything about getting a reason. The proposal was that packages be automatically rejected if no ftp-master approves it within two weeks. I don't understand how that helps anyone. You still don't get any explanation, and now there's not even a chance someone will find time to look at it. -- 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: switching to vim-tiny for standard vi?
Graham Wilson <[EMAIL PROTECTED]> writes: > On Sun, Dec 18, 2005 at 06:54:42PM +, Andrew M.A. Cater wrote: >> Count me as an nvi person. Vim is great - but not as the default in >> the most basic system, no matter how stripped down. > Why is nvi better if the size of nvi and vim-tiny are comparable? Among other things, because it doesn't do the obnoxious auto-indent thing that you have to work around with :set paste. I have no objections to vim as an editor, but it would be nice for vi to be, er, vi. vim isn't really vi; it's something that was originally based on vi and is now something slightly different. (Of course, nvi isn't exactly vi either, but it's a lot closer.) This isn't really new information. I guess I'm just speaking up to represent those people who do indeed care about tighter compatibility to the original vi than vim offers. I won't lose lots of sleep if I lose this argument. :) -- 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: Size matters. Debian binary package stats
Steinar H Gunderson <[EMAIL PROTECTED]> writes: > On Sun, Dec 18, 2005 at 08:23:56PM +0100, Olaf van der Spek wrote: >> Why would that stop working if you switch compression schemes? I guess >> tar is coded to use gzip with -z and bzip2 with -j, but why is there no >> generic way to add coders/decoders (codecs) to tar (and other >> applications that wish to use compression filters)? Well, tar supports --use-compress-program. [...] > (The -j flag to tar is a Debian specific extension, BTW No, the Debian extension was -I (and even that was present for a while in upstream). It was changed to -j because that's what upstream did. The -j flag is present upstream as of 1.13.18. -- 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: /run vs. /lib/run
Thomas Hood <[EMAIL PROTECTED]> writes: > Any other defenders of /lib/run? Of /run? /run makes much more sense to me. /lib/run just seems unbearably ugly, not to mention that it would be kind of nice to have a read-only /lib be a possibility for a variety of reasons (yes, I know, module dependencies make this hard). Perhaps this is a bad idea (or perhaps this is even how it's already done), but given the very limited number of things that would have to use /run, would it be possible to write them all to use /var/run if it's available and only if it's not, fall back on /run? That way, /run could be created during the boot process, then moved to /var/run and removed again once /var is available, making it a transient aspect of the boot process and not hanging around as a new top-level directory. -- 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: /run vs. /lib/run
Anthony Towns writes: > There aren't any technical differences between the first two options. I agree with that. > Each of the solutions has a degree of ugliness -- in the first case, > the ugliness is in violating the "no new directories in /" rule and > making /run/ifstate seem more important than /etc/network/ifstate or > /var/run/ifstate would be; in the second, it's in having to introduce > a new subdirectory name to separate the variable parts of /lib out; in > the third, it's the system specific ugliness of having to ensure /var > is mounted early. That's not the ugliness that I care about with /lib/run; the uglyness that I care about is that it's introducing /var content into /lib, which feels like a serious violation of the spirit of the FHS to me (yes, we're already violating the letter, but only because there's no /share and /lib is essentially a merger of /lib and /share). /run is not equivalent to /var/lib; it's equivalent to /var/run, which is not at all a lib directory to me. But it's all just aesthetics. > (TBH, I'd be much happier just making the technical changes necessary to > ensure /var is mounted early -- keeps the filesystem sane, and it's just > a simple matter of programming, rather than arguing over what's ugly. Yeah, I agree with this too. -- 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: c2a transition: libraries still needing transition
Nathanael Nerode <[EMAIL PROTECTED]> writes: > In addition, the following libraries still need to be uploaded with name > changes for the *c2* transition: > log4cpp -- new maintainer needs a sponsor, see bug 303794 The new maintainer says that he has a sponsor and is working on fixing some problems with the package. -- 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: buildd administration
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > You just try to make a point out of buildd.net not having a direct > source link which is completly irelevant imho. Hey, I don't care if there's a direct link or not. I care if the source is available for anyone to go download. If it's available from some obscure place, great, that's new information in this thread. Where is it? I'll go link to it and make it less obscure and then we can have more interesting discussions. > If you (as in buildd.d.o) want to add a source link then do it. That is > debians decision ultimately. So far Debian hasn't made that addition and > Ingo didn't want to make it. That is your/his choice and changes nothing > on the freeness of the software. It just changes the propagation medium. This may sound heretical to you, but I don't consider software to be DFSG-free unless there's actually a copy somewhere that people can get to. If the source is unavailable, the software isn't free, regardless of what theoretical license is attached to the theoretical source that no one has access to. If you only want to distribute the software via e-mail, fine, send me a copy of it, I'll put it up on my public web site, and then it will be free. And then one could have a more meaningful conversation about where it should fit into buildd.debian.org. -- 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: Thoughts on Debian quality, including automated testing
Thijs Kinkhorst <[EMAIL PROTECTED]> writes: > On Wed, 2005-12-21 at 17:08 +0100, Petter Reinholdtsen wrote: >> At the very minimum, I believe all base packages (those installed by >> debootstrap by default) should have co-maintainers. > This sounds like a good compromise between the two sides of this > discussion. packages.qa.debian.org already bugs you to find a co-maintainer if the package is priority standard or higher. It's a good hint but not mandatory, which feels about right to me. I don't really understand what requiring a package to have a co-maintainer looks like. Do you remove the package from Debian if there's no co-maintainer? Surely not for base packages. Do you force a co-maintainer on the package somehow? How? What if someone is just listed as a co-maintainer but never does anything? Also, I think this is a little silly for small packages. My experience with this sort of volunteer work in other areas is that if one person does nearly all the work on a regular basis, you're not gaining that much by having a backup. The person who is theoretically the backup isn't up to speed on the package anyway and is going to be starting roughly as cold as any other random person out there. And there simply isn't enough work for two people for a lot of packages. I think that the energy used to define these sorts of procedures is probably better used finding a package with a large bug count and volunteering to work with the maintainer to try to get the bug count down. -- 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: Experiment: poll on "switching to vim-tiny for standard vi?"
Glenn Maynard <[EMAIL PROTECTED]> writes: > I much prefer vim-tiny over nvi, others have agreed (at least Frans Pop > and Joey Hess), and not one person so far has actually said they prefer > nvi over vim--just that they prefer its defaults, which has been > addressed. Just to be completely unambiguous about my earlier message, I do indeed prefer nvi over vim, regardless of how vim is configured. It's smaller and it does what I expect, which neither vim in its default mode nor vim in its compatible mode does. Also, I prefer not to have to configure my vi to behave like vi, but maybe that will be changed. It's not a matter of just configuring it on one host, like it is with XEmacs. I only use XEmacs for major editing and can customize it extensively on the small handful of systems that I use all the time. I use vi for routine system administration, configuration file editing, and all small edits, and I use it on a ton of different Debian machines from a variety of different accounts that don't all share a single configuration or set of home directories. (I realize that other people feel the same way about vim. I'm just stating a personal preference, not arguing that other people's preferences are wrong.) On the other hand, I don't consider it a major issue and can live with whatever decision people come to, which is why I voted both alternatives above further discussion in the straw poll experiment. :) -- 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: Thoughts on Debian quality, including automated testing
Petter Reinholdtsen <[EMAIL PROTECTED]> writes: > [Russ Allbery] >> Also, I think this is a little silly for small packages. My experience >> with this sort of volunteer work in other areas is that if one person >> does nearly all the work on a regular basis, you're not gaining that >> much by having a backup. The person who is theoretically the backup >> isn't up to speed on the package anyway and is going to be starting >> roughly as cold as any other random person out there. > Did you miss the point that a package need to rot quite a long time > before packages are taken out of the hands of a missing or useless > maintainer? Maybe that's the problem that you should concentrate on fixing instead of trying to work around it with a solution that won't necessarily fix it and which adds pointless overhead to packages that are well-maintained? > If there is a co-maintainer, he will most likely not wait that long > before he continue maintenance of the package. Or maybe he'll be so uninterested in the package since there's never been anything for him to do that he won't even notice the problem and won't be any improvement over not having a co-maintainer at all. > You seem to be talking about a "co-maintainer" whose entire > responsibility is to be listed in the uploaders field, while I talk > about co-maintainers which have expressed interest in actually > maintaining a package. The latter are quite likely to be able to take > over when the primary maintainer us unable to keep up with his tasks. I'm pointing out that if you require co-maintainers for small packages, what you're going to get is a whole bunch of the former. There isn't enough work for two people, plus people annoyed with the rule will list co-maintainers in order to make people stop bugging them. -- 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: Thoughts on Debian quality, including automated testing
Frank Küster <[EMAIL PROTECTED]> writes: > It would be good if there was a way to find out "problematic" packages, > by extracting information about > - how many bugs does a package have > - how many of them don't have a single response > - how many have not been dealt with for n months (or days/weeks for RC > bugs) > - how many packages depend on the package > and try to create some rating or ordering. One could then not only > identify packages that could use some work, but also for which of them > it's most useful. <http://haydn.debian.org/~thuriaux-guest/qa/global.html> Was posted to debian-devel a few days ago. :) > Another good thing would be an effort to go through important packages' > ancient bugs and clear them up. E.g. all those, mostly years-old dpkg > bugs that report a segfault. Either something should be done about > them, or they should be closed. Amen to this. As soon as I finish a few other projects related to my own packages, I'd been thinking about picking one of those packages and volunteering to do bug triage. I don't see how anyone can find anything in the BTS when a package has hundreds of bugs, and certainly I doubt new bug reporters are really reviewing all of the existing bugs if there are more than a hundred of them. (debbugs's strong point is handling a small number of bugs on *lots* of different packages; I find it somewhat difficult to follow when dealing with a *lot* of bugs on a single package.) -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Re: debbugs tangent
Erinn Clark <[EMAIL PROTECTED]> writes: > * Russ Allbery <[EMAIL PROTECTED]> [2005:12:22 09:14 -0800]: >> (debbugs's strong point is handling a small number of bugs on *lots* of >> different packages; I find it somewhat difficult to follow when dealing >> with a *lot* of bugs on a single package.) > OT for this thread, but: do you notice this even with usertags/user > categories? I'd be curious to hear suggestions for improvements. I'm not sure yet; I haven't tried hard to use usertags to work around this. For the packages I've worked on so far, it's been easier to just fix the bugs until the bug list got down to something reasonable. I think it's likely to help a great deal, though, and may largely take care of the problem for developers (although it doesn't help the reportbug problem). -- 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: Heimdal and openssh
Juha Jäykkä <[EMAIL PROTECTED]> writes: > 1) Ssh-krb5 (sarge) and openssh 4.2 (sid) will not talk GSSAPI to each > other. I gather from openssh mailing lists that no versions of openssh > <4 and >4 will ever talk GSSAPI together due to some security patches > made. Thus this is not a Debian -related problem, but it leads to one. Er, huh? wanderer:~> dpkg -l ssh-krb5 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii ssh-krb5 3.8.1p1-10 Secure rlogin/rsh/rcp replacement (OpenSSH w wanderer:~> ssh windlord Last login: Thu Dec 22 21:07:28 2005 from 113.110-113-64.ftth.swbr.surewest.net 23:10:07 up 12 days, 7:22, 28 users, load average: 0.00, 0.01, 0.00 windlord:~> dpkg -l openssh-server Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii openssh-server 4.2p1-5Secure shell server, an rshd replacement Works fine for me. > 3) LDAP needs gssapi libraries compiled against Heimdal, not MIT > kerberos (I assume this has something to do with the service being used > is Heimdal, not MIT.) No, it has to do with thread safety and is partly obsolete now that MIT Kerberos 1.4 is in sid. MIT 1.4 should be fine for OpenLDAP for most purposes (although as I recall Quanah says that it has a lot of trouble compared to Heimdal under load). Anyway, LDAP just uses SASL; it doesn't link with Kerberos directly. So you should be fine installing whatever SASL modules you prefer, whether the Heimdal ones or the MIT ones. > 4) Now that I have Heimdal GSSAPI libraries, openssh GSSAPI will not > work. Um, this doesn't make any sense to me. Two different GSSAPI libraries, two different library names or SONAMEs, should co-exist on the same system just fine. The *development* packages don't co-exist, but the libraries do. I have them both installed at the same time on my system right now. > 5) As a side note: I learned afterwards that AFS token passing with ssh > *needs* openssh compiled againsta heimdal-dev. Don't ever do AFS token passing. Pass your Kerberos tickets with GSSAPI and then use a PAM module to get AFS tokens from your forwarded tickets. AFS token passing is obsolete, insecure, and requires that you use protocol version one. > Now my real question: what's the smartest way to keep all these > self-compiled packages up to date? I'm pretty sure you shouldn't need to do any of this. :) > [1] MIT kerberos is not thread safe (unless my info is outdated) MIT Kerberos is thread-safe as of 1.4. > and only Heimdal is capable of seamlessly integrating to AFS. MIT Kerberos works fine with AFS, but I admit that you have to go to marginally more effort. Not enough to deter me from using MIT, but if you prefer Heimdal, I won't stand in your way. :) > The first can be worked around, but the second is probably very > important to anyone running AFS and kerberos. Not really. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Bug#344626: ITP: svn2cl -- Convert Subversion logs to GNU-style ChangeLogs
Package: wnpp Severity: wishlist Owner: Russ Allbery <[EMAIL PROTECTED]> * Package name: svn2cl Version : 0.4 Upstream Author : Arthur de Jong <[EMAIL PROTECTED]> * URL : http://ch.tudelft.nl/~arthur/svn2cl/ * License : BSD (3-clause) Description : Convert Subversion logs to GNU-style ChangeLogs svn2cl generates a text GNU-style ChangeLog from a Subversion repository log by transforming the output of svn log. It also has preliminary support for generating HTML ChangeLog files. For CVS users, it is roughly equivalent to cvs2cl but for Subversion. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#344626: ITP: svn2cl -- Convert Subversion logs to GNU-style ChangeLogs
Florian Ragwitz <[EMAIL PROTECTED]> writes: > Is this tool somehow related to [0]gnuify-changelog.pl in the subversion > package? What can it do more? > 0. /usr/share/doc/subversion/examples/gnuify-changelog.pl.gz It's completely different and has some additional functionaly, most notably actually listing the files that were changed, combining entries for a single day if desired, adding the revision number if desired, more closely outputting the ChangeLog style, and support for generating HTML. It uses svn log --xml and an XSLT transform. Turns out that the maintainer is a Debian developer, so I'm going to point him at my package and probably won't end up maintaining it myself. -- 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: Heimdal and openssh
ou would be getting tokens from your forwarded tickets. Or maybe you have KerberosGetAFSToken enabled in sshd_config? The AFS token passing I know about is an old, old hack that dates from OpenSSH 2, that has to be explicitly enabled when OpenSSH is compiled, and which only ever worked with protocol version one. If there's something else going on (which there may be; I've always been content with GSSAPI authentication and ticket forwarding, so I've not looked in detail), it's something else that I'm not aware of. > Thanks for a very informative answer. I'd really like to get to the > bottom of this, but that remains to be seen... Me too. It really should all just work. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Re: ITK: debmake
Daniel Kobras <[EMAIL PROTECTED]> writes: > Corrin Lakeland <[EMAIL PROTECTED]> >gnubg I've adopted gnubg with Corrin's permission and this is now fixed in the version just uploaded yesterday. -- 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: How to Increase Contributions from Volunteers
Andreas Fester <[EMAIL PROTECTED]> writes: > My impression is that the process of becoming a developer is very hard, > both for the applicant but also for the Application Managers. If someone > contributed to the project continously for a long time, then decides to > apply for New Maintainer which then takes another year (I dont know if > this is the usual case), this could be frustrating. It really isn't *hard*, though. That's the thing. If you've worked with Debian for a while and read all the documentation, it's not at all difficult to become a Debian developer and there are a lot of people available to help. It's *time consuming*, for both the applicant and the AM (and the DAM). That's what people complain about. It can take most of a year, or even more. But that's not time spent constantly working; most of that time is spent waiting in various queues for someone to have free time. -- 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: Packages still Depending on xlibs-dev
Bas Zoetekouw <[EMAIL PROTECTED]> writes: > Hi Daniel! > You wrote: >> Debian QA Group <[EMAIL PROTECTED]> >>libubit-dev > Maybe this package should just be removed? It doesn't have any reverse > dependencies afaics, and hasn't had a non-QA upload since feb 2004. Already requested with ftp.debian.org, see Bug#344597. -- 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: What's the best directory to put a local Debian repository?
Maurits van Rees <[EMAIL PROTECTED]> writes: > I'm wondering what the best place is to put a local Debian package > repository. Directories that spring to mind are: [...] > - /srv/debian > According to the Filesystem Hierarchy Standard the /src dir is for > Data for services provided by this system, which seems to fit the > bill. I vote for this. At Stanford, we're slowly trying to migrate local data for services running on the machine into /srv. It's the Right Thing from the FHS perspective so far as I can tell. -- 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: Need for launchpad
Stephan Hermann <[EMAIL PROTECTED]> writes: > Well, we can't change the world totally, but avoiding a tool, because > it's free, but non-free source, it's more a joke then anything else, > because I had to avoid many of the services I need in my daily > developers world. And this belief, in a nutshell, is the reason why I'm a Debian developer and, while I might use Ubuntu in a situation where it looks like a good distribution, I have no interest in contributing to it except insofar as Ubuntu, and anyone else, is welcome to reuse my contributions to Debian. If you want to call that a joke, feel free. *shrug*. I actually believe in free software. -- 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: Need for launchpad
Andrew Suffield <[EMAIL PROTECTED]> writes: > Can anybody actually think of a reason why they might want to keep any > of this code proprietary, other than grabbing power? I can't see *any* > way in which this could possibly be anything else. The only reason I can > think of is to be able to use launchpad to control people, for whatever > reason. Proprietary advantage over other Linux distributions. I don't think that's the same thing as controlling people, quite. I think they believe the key to producing an excellent Linux distribution, more than anything else, is excellent integration tools that do as much as possible of the dirty work involved in pulling lots of software packages together. They're investing in writing better tools, and they're keeping them private so as to maintain a competative advantage with them over Red Hat, SuSE, Fedora, and so forth. Including Debian, for that matter. That's fine with me. I'm not the sort of believer in free software who feels that non-free software is morally wrong. This is something that commercial companies can do; they can throw resources at a particular problem and if they have the right people and the right starting points and the right management infrastructure, they can often come up with stuff that's significantly better than the state of the art. More power to them; the ideas, if not the software, will eventually enter the commonwealth of information. However, I'm not interested in helping them make money. They're not paying me and I don't do this for money except insofar as it's an incidental part of my job. If I were looking for a new job, I might consider whether that would be a fun place to work. Since I'm not, and I'm working on building a better free Linux distribution, working on or using non-free components is a waste of time and effort. Nothing worse, but also nothing better. I wish them the best of luck with improving the state of the art, but their work is irrelevant to me, except as an idea generator, until such time as it's free. Since otherwise, I'd be missing the whole point. I want to build up the information commons, not work on doing something great just for the sake of doing something great. Unless the work enters the general commons, all the code and effort is basically wasted in relation to my goals in working with Debian. -- 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: Canonical's business model
Andrew Suffield <[EMAIL PROTECTED]> writes: > On Sun, Jan 08, 2006 at 10:30:07PM -0800, Russ Allbery wrote: >> They're investing in writing better tools, and they're keeping them >> private so as to maintain a competative advantage with them over Red >> Hat, SuSE, Fedora, and so forth. Including Debian, for that matter. > ...damnit, I never thought of that. And you know why not? Because on > some level I thought that all the noise they make about 'contributing > back to Debian' was more than just lip service. I had (stupidly) wanted > to believe that it wasn't *just* their PR machine at work. I think that more than one thing can be going on at once. There are commercial companies that keep things secret for competative advantage and *also* contribute other things back to the broader community. IBM, for instance, to take a prominant example. I don't believe that all of the rhetoric around Canonical is bogus; I think much of it is entirely true. However, they're also a company. Companies, no matter how generous the founder and no matter how strong the ideals, still do behave in certain ways. Sometimes that's delayed, and often they continue to work with a community while still finding other ways to make a profit, but the decisions at some point do become economic. This isn't necessarily a bad thing. It's just a splash of reality. It's not infrequent these days for a company to form around a free software project, and often the result is a burst of resources and significant improvements. But through that period, it's also important to maintain sight of why the free software project is bigger than any company that might form out of it, and to be constantly planning for the day when the company will go away, become hostile, stop giving back, or otherwise take its balls and go home. Since this almost *always* happens sooner or later. I'm not ideological about how other people work. If people want to work for a commercial company or not release their work or what have you, more power to them. I hope they make lots of money and live a wonderful life with lots of interesting things to play with. However, from the perspective of building a free infrastructure, the only work done by companies that matters in the long run is the work they release to the world. Everything else is just something more that will have to be rewritten or reinvented later by someone else until finally it's released as part of the commons. It's their work to waste (and from their perspective it may not be a waste -- putting food on the table of employees is also a useful activity, even if it's not the activity that I personally care to help), and I'm not going to fight with them about it, but neither am I going to pour my time and resources into helping with their business model unless it also benefits the information commons that I'm trying to expand and improve. As such, I think getting upset at them is fundamentally missing the point. Companies act like companies, sooner or later. Companies are fundamentally economic. I don't mind them buying goodwill -- the only actions a company *can* take, at a fundamental level, are buying and selling. However, I'm always going to expect a company to take whatever actions lead to the most return on their investment. If that's helping Debian, they'll help Debian. If at some point helping Debian is no longer good for the bottom line, they'll stop helping Debian. Because of that, they're fundamentally unpredictable in a way that a personal relationship is not, and I'm not going to rely on them and I don't want to see any infrastructure beholden to them. I agree with David; the best approach is to try to build personal relationships with the people doing the work, and insofar as their job at Canonical lets them do work that Debian can benefit from, to take advantage of those additional resources and not worry about looking gift horses in the mouth. As long as we don't become *dependent* on the actions of a company, we can certainly accept and use contributions that a company is willing to pay for, with good grace and expressed gratitude. For example, personally I really appreciate the Ubuntu patch archives. For me personally, it's been useful and helpful. > If you're right, then it would mean that their concept of 'contributing > back' means to purchase 'goodwill' at the lowest available price - which > would be consistent with the behaviour we've seen from them so far. In > effect, treating it as another asset, and behaving like a classical > company that focusses on the bottom line. So that's actually plausible. It's also important to not completely conflate the people who work for Canonical with the actions of Canonical the company. Many
Re: lintian problem [shared-lib-without-dependency-information]
Székelyi Szabolcs <[EMAIL PROTECTED]> writes:
> I'm trying to make my first package... Everything goes fine except one
> thing. Lintian says:
> W: libvrb0: shared-lib-without-dependency-information
> ./usr/lib/libvrb.so.0.4.0
> I understand what this means, know how to fix it (by adding -lc to ld
> arguments). Unfortunately the upstream source uses some strange
> (non-auto{make,conf}) build system, meaning (among other things) that
> the arguments of ld are hard-coded into the configure script.
You really shouldn't have to add -lc to the ld arguments; that indicates
that upstream is doing something very odd.
> Solutions may be:
> * modifying the configure script
> * manually adding libc to 'Depends:' line
> * overriding the warning
> Which one sould I choose? Any other idea?
> The upstream source is available from http://vrb.slashusr.org/
Upstream is explicitly writing out a Makefile that links the library with
-nostdlib -nostartfiles, despite the fact that the library calls libc
functions. This is broken. I'm not sure about the -nostartfiles,
although that seems very suspicious, but -nostdlib is simply wrong and
should be removed so far as I can tell.
You may want to ask upstream why they did that, but I'd patch Configure to
remove -nostdlib in the maketop function that writes out the Makefile.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Re: Need for launchpad
Matt Zimmerman <[EMAIL PROTECTED]> writes: > Do you mean to say that you have been discouraged from contributing to > Ubuntu because the Launchpad source code is not available to you? It's far broader than just Launchpad. I am discouraged from contributing to Ubuntu because Ubuntu is not *fully* committed to free software, by which I mean building the entire infrastructure on free software and making available all tools, or at least as much as practically possible, as free software. Debian isn't perfect at this. There are portions of the Debian infrastructure where the exact version that Debian is running are not necessarily available. However, these are generally considered within the project to be anomolies and Debian *does* have a general committment to free software for its infrastructure. I'm not at all surprised that Ubuntu is drifting into closed-source software, as this is a standard development path for a company based around free software. I'm not upset. I'm simply not interested, and consider that path to be entirely predictable. > The response to this thread has been predictable, given the wording of > the original post and the strong opinions that free software developers > often hold regarding their toolset. A similar argument would surely > ensue if someone proposed that all Debian developers use Subversion for > source code management, for example. Manoj's analogy with human > language, while dripping with sarcasm, is apt. The whole web-based bit is mostly uninteresting to me. There are various ways of wrapping a command-line interface around a properly designed web service, such as SOAP or XML-RPC. The problem I have is that Launchpad isn't free. As such, it immediately becomes irrelevant to me as far as Debian infrastructure is concerned. Please note that I'm not picking on Ubuntu. I had this exact same discussion (even including hurt feelings and unnecessary drama) with the buildd.net folks just a few weeks ago. > As for licensing, some code has already been released as open source, > and Canonical has made commitments to do more of the same in the future. This is great, and I for one greatly appreciate any and all contributions that Canonical makes back to the broader community. For so long as Canonical doesn't contribute *everything* (or at least nearly so; see the above caveat) back to the broader community, I'm uninterested in working *directly* on Canonical's distribution, but I'm certainly interested in helping Canonical in return for Canonical's contributions to the general community. In other words, my unwillingness to work *directly* on a distribution that is backed even in part by a non-free infrastructure should not be taken to imply that I'm unwilling to even cooperate with the people who are working on it. I'm quite happy to have my work for Debian used in Ubuntu, and I'm quite happy to fix bugs, accept patches, and minimize divergence even if it doesn't affect Debian directly (see Bug#342607 for a trivial instance, where I also did the work of getting the patch and approved upstream). You just won't see me become an Ubuntu developer unless Ubuntu as a whole is committed to free software from the ground up. And certainly, I would oppose blessing any closed-source toolset as part of Debian's infrastructure, regardless of its origins. Which is where I entered this particular thread. -- 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: Canonical's business model
Matt Zimmerman <[EMAIL PROTECTED]> writes: > I agree with most of what you've said, except for the assertion that > individual people are fundamentally different in this respect. Debian > developers, in general, work on Debian in their spare time, and make > their living by other means. Often these pursuits come into conflict, > being in competition for the same resources (primarily time), as many of > us know all too well. Hm, yes, that's a good point. I still feel like it's a bit different, in that at the level of individuals, it tends to be a different in quantity of contribution rather than time and one gets more warning and in ways that are easier to deal with, but this isn't *always* the case. > The fact that for-profit companies need to create economic justification > for free software contributions doesn't mean that they can't be valuable > contributors. A huge volume of such contributions have come from > profit-motivated initiatives, both at the individual and organizational > level. Oh, absolutely. Definitely agreed. I think it's fantastic when people get to work on free software as part of their job, and those people are a huge resource for free software. There are inherent limits to how much one can do this as a hobby, and someone who's paid to work full-time on free software can simply do quite a bit more than someone who has to do it as a hobby and balance it against getting paid. Finding good ways of taking advantage of the work of people who are paid to work on free software is very important for any free software project, including Debian. -- 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: Heimdal and openssh
Juha Jäykkä <[EMAIL PROTECTED]> writes: >> * Interoperate with ssh-krb5 << 3.8.1p1-1 servers, which used a >> slightly >> different version of the gssapi authentication method (thanks, Aaron >> M. Ucko; closes: #328388). > Perhaps this is THE patch which makes them all work together while > openssh folks claim they don't? This is a side-issue, but it would be > nice to know. That may very well be the case, yeah. I've not done a lot of experimentation. > Ahem... my krb5.conf says "permitted_enctypes = aes256-cts-hmac-sha1-96" > (in libdefaults). So this is the culprit here? [Please, do not patronize > me on using a non-recommended config. =) It's simply that I think DES > has no security to speak of these days. 3DES might be worth trying, > though.] In further discussion, this turned out to be the problem that started all the attempts at rebuilding things (in case anyone else happens upon this thread). The versions of everything in sarge aren't set up to support 256-bit AES as the only supported enctype, but this will probably work in etch. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Re: Need for launchpad
Florian Weimer <[EMAIL PROTECTED]> writes: > * Russ Allbery: >> Debian isn't perfect at this. There are portions of the Debian >> infrastructure where the exact version that Debian is running are not >> necessarily available. However, these are generally considered within >> the project to be anomolies and Debian *does* have a general >> committment to free software for its infrastructure. > Is there such a commitment? I did feel a bit strange to read the > announcement that Debian welcomes highly proprietary solutions for its > data storage, but I assumed that it was just me. Well, this gets into the software vs. hardware thing, and while I understand and even sympathize with people's feelings on free hardware and free firmware, most of the free software community really does treat them differently. I don't really want to get into the debate in this thread about whether or not this is justified, but the software portions are more important to me personally. And yes, I think there is a commitment. I'm not sure that it's as strong as it ideally could be, but I think it's stronger than any other major Linux distro by far, and it's resulted in concrete changes in the past (for example, Debian's project mailing list servers are no longer running qmail, even though qmail, as non-free software goes, is almost, but not quite, free). -- 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: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265920
Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> writes: > that distinction isn't made clear: it's only if people think about it > that they will realise that they are supposed to report debian-specific > packaging bugs to the debian bugs database and package-specific bugs to > whatever upstream thingy they can find. _if_ they can find it. For my packages, I would like people to report upstream bugs with reportbug. I'll forward them upstream if need be. For most of the packages that I maintain, I have a very close relationship with upstream and have a lot of communication channels available to me that the bug reporter probably wouldn't have. For example, if someone reports a bug in OpenAFS, I usually talk it over with the developers on Zephyr before forwarding it to the upstream bug database. I think this is a case where very large packages like Firefox or OpenOffice may have different needs than the majority of packages in Debian. -- 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: Development standards for unstable
Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > Well, that's current practice, but nobody is stopping anyone to give a > little bit more care into QA packages... The hardest problem, speaking as someone who wanted to do that and who still wants to do that as soon as I can find time, is that many of the packages that are QA-maintained are very difficult for the average developer to test. For various reasons, QA accumulates a lot of packages with obscure usages or obscure dependencies that are difficult to modify just because one can't be sure one hasn't broken something. For example: dcl: GNU Enterprise - Double Choco Latte eco5000: Orga Eco 5000 smartcard reader PCSC and CT-API driver gnusim8085: Graphical Intel 8085 simulator goldedplus: Offline mail reader for Fidonet and Usenet gsmartcard: A smart card reading, writing and managing program for Gnome gtkhx: A GTK+ version of Hx, a UNIX Hotline Client just to pick a few obvious ones off the first page of the orphaned package list that I'd have no idea how to test. > Also, I am wondering how much success such a 'common maintained packages > team' would have while there is a shortage of people caring for general > QA of orphaned packages or just on the archive at all. Yeah. It's not like there's a shortage of work now. I have 20 or 25 saved messages of people looking for sponsors, another 20 QA packages with bugs that I think I can fix, and a bunch of work for the Debian Perl group that I could do as soon as I find some free time. -- 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: Development standards for unstable
Thomas Viehmann <[EMAIL PROTECTED]> writes: > Can you elaborate on this? I'm not sure how the existence of more > packages that should be orphaned invalidates dealing with those that > presently are. > There's 169 orphaned packages today, why not do something about them? The thing is... most of the orphaned packages are in fairly good shape. Most of the orphaned packages are orphaned because they're obscure and the person who cared about the package has left the project or run out of time. However, they are probably still working fine for people with those obscure needs, and as such there isn't an obvious significant gain for Debian by getting rid of them. The packages in the worst trouble in Debian are not the orphaned ones. By pretty much every available QA measure we have (RC bugs, open bugs, bugs without a response, lintian errors, time since last upload, etc.), almost of the packages in the worst shape have a regular maintainer. -- 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: Need for launchpad
Matt Zimmerman <[EMAIL PROTECTED]> writes: > Ubuntu, while its license policy is somewhat less strict than the DFSG, > is not drifting into closed-source software. It's virtually unchanged > since the project's inception. The policy and development may be virtually unchanged since the project's inception since I have no idea how many other closed-source components such as Launchpad you've been working on from the beginning, but at least the public face is drifting as those projects are deployed and become part of the day-to-day work on Ubuntu. And hey, as I said, if that's what you want to do, more power to you. I'm well aware that many in the free software community are quite happy to use closed-source and/or commercial infrastructure toolsets and services. The advertising deluge that drowns me every time I try to look at Sourceforge is a good reminder of that. :) However, the more that you deploy and depend on closed-source tools, the less interesting Ubuntu is to me personally. (It's quite likely that you don't care, and that's fine. I don't really expect you to.) -- 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: Development standards for unstable
Thomas Viehmann <[EMAIL PROTECTED]> writes: > Russ Allbery wrote: >> The thing is... most of the orphaned packages are in fairly good shape. > How do you know? Well, because at one point I went through the PTS for each one of them, checked for filed bugs, checked lintian reports, etc. I haven't specifically *used* each of them, but I think the choices are no one is using them (popcon seems to say no), no one is reporting problems (possible, but statistically I'd expect someone to notice), or they're in fairly good shape. > I think that not shipping unmaintained and unsupported packages is a > benefit. Packages need a maintainer to enter, I think they should need > one to stay. Orphaned packages *are* maintained and supported by the QA group to a degree. They're not as closely maintained as the ideal regularly maintained package is, and it takes a while to fix problems, but there are people who look at the bugs and deal with major issues. My point is that this is actually *better* than a depressing number of the packages that have regular maintainers. A while back, when that global ranking of packages based on various criteria such as last maintainer upload, number of bugs, number of RC bugs, number of lintian errors, and so forth was posted, there were no orphaned packages in the top 150 problem packages. Admittedly, that's partly because number of NMUs since a maintainer upload was one of the criteria and QA-maintained packages don't have that, but still. That's fairly impressive. > Look at dcl as a random example. I think that not having a maintainer is > quite a burden when security bugs such as the one fixed shortly before > sarge release occur after release and this is when the upstream seems up > to speed and people (here Joey Hess) in Debian track security reports > globally, otherwise, security bugs might even go unnoticed. I grant that security is one case where not having someone closely monitoring the package can be a serious problem. > Also, I'm not sure how much the important bug impedes the functioning of > the package, IMHO it would be rather bad if new installation was > impossible with postgresql without documenting it beforehand. Using > dbconfig-common probably would also be on a maintainer's todo list. So > really, while the QA maintenance is certainly fine ATM, the package > probably isn't as well supported as we would expect from a designated > maintainer. That I would agree with, certainly. It's definitely better for the packages to be adopted, and one would expect better maintanence from a regular maintainer. I just don't think that mass-removing orphaned packages just becaues they're orphaned is a good way of improving the general quality of Debian. Now I should go off and mentor some adoptions of orphaned 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]
Re: [ad-hominem construct deleted]
Sami Haahtinen <[EMAIL PROTECTED]> writes: > I can understand that a part of the people behind Debian feel hostile > against Ubuntu because it's succeeding in something that Debian was > trying to achieve. But what i can't understand is that people behind > Ubuntu are trying to reach out and build a bridge between the people in > Debian and some people are intentionally trying to burn them. They are > really investing time on the co-operation, they are creating tools to > help this. What are the Debian people doing, they are bitching about > Ubuntu people not putting their backs in to it. For those who are concerned with closer co-operation between Debian and Ubuntu, lots of people have already tried to send a clear message. The best way to encourage and help this is to *stop posting things like the above* and just go work on syncing changes. Help with the work, don't tell us what we do and don't believe. As long as you keep accusing people of burning bridges or bitching about other people's work, those of us who feel like we have legitimate concerns tend to want to repeat them or try to explain them again. The result is that threads about the *differences* get longer and longer and accumulate more posts, and as a result the gap looks wider and wider. If, on the other hand, you'd accept that a lot of Debian developers really care deeply about things like free software and aren't going to use tools like Launchpad *but still want to co-operate*, stopped bringing up the things that we disagree about, and started trying to improve communication by taking a few Ubuntu fixes and filing them as Debian patches, or helping with a Debian transition like the modular X transition that will obviate the need for tons of divergence, or did something else concrete to bring the distributions closer together, you'd find that many of the same people who are arguing with you here would happily help. Personally, I monitor the Ubuntu patches for all of my packages and apply whatever looks reasonable. Maybe it's not the best way to contribute back changes, but it works fine for me. It probably wouldn't if my packages had more complex differences, so finding a better way to communicate those complex differences would be valuable work. If closer collaboration is something you want to see, stop telling us that the only reason why we're not working harder for Ubuntu is because we're jealous, *listen* to what we're actually saying, and help synchronize the hard cases. All this nattering on mailing lists doesn't make the software any better. -- 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: For those who care about lesbians
Mike Bird <[EMAIL PROTECTED]> writes: > There was nothing offensive about Andrew's message. Since you do not > offer any reasons for your melodramatic conclusion, I suspect that you > are merely trolling. > I *hope* you are not using this list to engage in discrimination against > those whose sexual orientation may be different from your own. Er, I thought it was offensive because it was sexist, not because there's anything wrong with being lesbian. Regardless, I think this was pretty much the poster child for "two wrongs don't make a right." -- 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: For those who care about lesbians
Manoj Srivastava <[EMAIL PROTECTED]> writes: > On Sat, 14 Jan 2006 11:19:37 -0800, Russ Allbery <[EMAIL PROTECTED]> said: >> Er, I thought it was offensive because it was sexist, not because >> there's anything wrong with being lesbian. > Umm, the fact that the phrase "You like looking at > hetrosexuals" is sexist just flew below my radar. I'm not sure this is the place, but, well, since several people have said they didn't understand The message that started all this is sexist because it ties into and reinforces a presentation of women as sexual objects for men to stare at in a context where this is entirely inappropriate. It plays into the conception of lesbians as eye-candy for men, thereby demeaning and belittling a sexual choice in a way that isn't done to gay men. It's sexist because it specifically uses women in a sexual situation to make its point, thus addressing readers differently depending on their gender in a forum where gender should be irrelevant. It's sexist because it brings gender and sexual orientation into a context where there was absolutely no reason to discuss it, in exactly the same way as making jokes about lesbians in a professional workplace environment would. That it wasn't intended as sexist, but rather was being used to make a completely different point, actually makes it worse. That such a message would be considered appropriate to make that sort of point is an expression of casual, subconscious sexism, rather than anything conscious. It's exactly the sort of behavior that, in sum, across many such supposedly "harmless" individual instances, makes professional technical environments uncomfortable for women. I don't mean to make a huge deal about this. I'm only posting this because you essentially asked, and because I think other people honestly didn't get it and maybe someone will understand. It is, by itself, not particularly overwhelmingly horrible, and I expect pretty much everyone who read it went "wow, that was stupid" and went on with their lives, but it *is* the sort of thing that sets the wrong tone and over time, with repetition, creates a more hostile environment. (If you don't agree with me, please, please, *please* don't argue about it here. It's really not at all relevant to this mailing list, and talking about it at length just makes it worse. I promise I won't post any more on the topic; I'm sure that we would all like to put the whole stupid thing behind us and get back to doing the technical work that this mailing list is actually for.) -- 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: Need for launchpad
Thomas Hood <[EMAIL PROTECTED]> writes: > I can't comment on your package. I have seen changes in some packages > that looked gratuitious, but then I have been comforted by the thought > that the perpetrators of gratuitous changes are the ones who have to pay > the price for it, because they have to carry such changes forward. However, to the degree that the Ubuntu patches have these sorts of gratuitous changes that shouldn't be merged with Debian, the patch database quickly becomes useless. The current patch system is only useful if a maintainer can easily review it for changes that should be incorporated in Debian, and nothing makes that impossible faster than changes like autotools modifications. -- 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: Implicition declarations of functions and bugs
Samuel Thibault <[EMAIL PROTECTED]> writes: > In buildd logs, I could find several > test.c:3: warning: implicit declaration of function 'f' > warnings > This can be very problematic on 64bits architectures such as AMD64: Yes, and definitely maintainers should clean this up when they see it unless they know it's safe. On the other hand, *most* of the cases of this warning in my experience are harmless because the function returns an int. It's most commonly seen in ancient software that doesn't include all of the right headers for functions like getopt(). The problems generally only arise with functions that return pointers. -- 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: Implicition declarations of functions and bugs
Samuel Thibault <[EMAIL PROTECTED]> writes: > Kurt Roeckx, le Fri 20 Jan 2006 23:56:22 +0100, a écrit : >> But this really is the maintainer of the package that should look >> at this. I don't think it's up to the buildd's maintainers to >> go and look for this type of bugs. > Ok, but maintainers don't seem to care so far. Something is needed to > get their attention on this issue. It's sometimes a notable divergence from upstream to fix this kind of thing, so I can understand why maintainers don't fix it if it's not actually causing problems. If you identify a case where it causes or is likely to cause problems, surely that's a regular bug report that maintainers should then deal with according to its severity. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Re: when and why did python(-minimal) become essential?
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Matt Zimmerman <[EMAIL PROTECTED]> writes: >> No, not yet. The promotion to Essential needed to happen prior to >> writing any such scripts. > Are there .config scripts written in other languages? I would expect so, given that there are .config scripts written in Perl in Debian. In krb5-config, for instance, there is a bit of Perl code that parses the default realm out of an existing /etc/krb5.conf file. It's possible to rewrite that code in sed (I've done it), but it's not quite as thorough and it's less maintainable. -- 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: Pre-Depends for Xorg 7.0
David Nusinow <[EMAIL PROTECTED]> writes: > On Mon, Jan 23, 2006 at 12:15:23AM -0500, Joey Hess wrote: >> David Nusinow wrote: >>> Currently, it fakes FHS compliancy by creating various symlinks >>> (/usr/include/X11, /usr/bin/X11, /usr/lib/X11) to the appropriate >>> directories in /usr/X11R6. For 7.0, we need to make those symlinks >>> become actual directories. >> I thought that the idea instead was to move everything directly into >> /usr/include, /usr/bin, and /usr/lib. Why keep the X11 subdirectories? > Right. The everything that you'd expect to go in to /usr/bin and > /usr/lib will install there, at least as far as Xorg goes. An example of > that is that the new xterm package installs to /usr/bin rather than > /usr/X11R6/bin. I haven't finished the packaging of everything, but it > seems that some of the header files are put in to differenct dirs of > /usr/include. I'll investigate the reasoning for this further. As for > /usr/lib/X11, data files like fonts currently go in there. I understand why /usr/include/X11 and /usr/lib/X11 would stay; after all, those are perfectly reasonable names for what they are currently symlinks to. I don't understand why /usr/bin/X11 wouldn't go away completely, at least for the programs that come with X. Maybe that's the plan and the above is just a bit confusing since all three of those directories aren't treated quite the same way? >> What about all the packages that you don't control that also still put >> things in /usr/X11R6? Recall that policy allows this for anything still >> using Imake, as well as mandating it for any package containing X >> fonts. > Right, they're still allowed to as far as I'm concerned. It's basically > that Xorg is giving up claim on that directory in a sense. I don't know > about the fonts issue given the above, I'll look in to that. Does upstream imake still dump everything into /usr/X11R6 or has it too been modified to use a more conventional installation structure? (Or is imake going away completely?) I'd love it if imake itself just used a better directory layout, since it's going to be a *long* time before everything that currently uses imake switches to some other build system (even if that's been in progress for years). -- 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: Autobuilding and the build-arch target, again
Simon Richter <[EMAIL PROTECTED]> writes: > - "If a package has both Build-Depends and Build-Depends-Indep, it > MUST have a build-arch target" > Would probably catch 95% of all cases. So far, I know no existing > packages that don't have those targets but use both B-D and B-D-I. I know tons of such packages, namely all arch-independent Perl modules that use debhelper with proper dependencies. You have to put anything required during debian/rules clean into B-D, not B-D-I. However, the buildds won't see such packages, so that lack of compliance with this proposal may not hurt. But then it reduces to your next proposal. > - "If a package has Build-Depends-Indep and is to be autobuilt, it > MUST have a build-arch target" > This would be special treatment for the autobuilders. Would work in more > cases than the check for both B-D and B-D-I though. As we cannot know > before the build whether a package will build any arch-dependent > packages, we can only guess here. To gain something here, we would have > to check whether any binaries for other architectures already exist, and > only in this case build-arch could be invoked. Talk about ugly. I think the way of phrasing this is "if the source package has both arch-specific and arch: all binary packages and B-D-I, it must have build-arch and build-indep targets." It's a pain to have the policy be this conditional, but I think this is going to make the fewest packages buggy while still accomplishing the goal. > - "Turn the SHOULD into a MUST in policy and have dpkg-buildpackage > check the Standards-Version" Checking the standards version for this sort of thing seems rather evil to me, but maybe I'm too conservative. -- 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: Pre-Depends for Xorg 7.0
Nathanael Nerode <[EMAIL PROTECTED]> writes: > Yep. > Imake is still being shipped for the benefit of third-party packages, > but it is not used by anything in Xorg 7.0 IIRC. Doing a quick check, I > think very few if any other packages in Debian use imake. I think you should perhaps check a little more thoroughly before jumping to conclusions. Here's a list of packages that install binaries into /usr/X11R6/bin and don't have lintian overrides for it. In spot checks, about a quarter of these packages use imake. And that's just the packages with binaries; there are a number of other packages that don't install binaries but that still use imake (I happen to maintain one of them, a font package). bugsx buici-clock ctwm emelfm fte-xwindow fvwm95 gerstensaft gipsc gradio hamsoft hanterm-classic hanterm-xf ibp isdnutils-xtools ivtools-bin ivtools-dev kdrill kinput2-canna kinput2-canna-wnn kinput2-wnn kterm lbxproxy lm-batmon lsb-core lwm mctools-lite mgp olvwm olwm oneko pgaccess pixmap plotmtv ppxp ppxp-x11 proxymngr qcam seyon skkinput tkdesk twlog twm videogen vtwm wmavgload wmcpu wmdate wmnet wmscope xautolock xbase-clients xbatt xbattbar xcal xcalendar-i18n xcb xclip xclips xdkcal xdm xdmx xdu xengine xfaces xfishtank xfm xfs xfwp xgdipc xinput xipmsg xlbiff xli xlockmore xlockmore-gl xmeter xmix xmon xnest xpostit xrn xserver-common xserver-xorg xsysinfo xtel xtoolwait xtrlock xutils xvfb xview-clients xviewg xviewg-dev xvkbd xxkb xzoom yank -- 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: Pre-Depends for Xorg 7.0
Nathanael Nerode <[EMAIL PROTECTED]> writes: > Imake is considered dead-except-for-routine-maintenance upstream as far > as I can tell, so best practice would be to migrate away from it. > Unless someone plans to adopt it. imake the program, and xmkmf, are *probably* not that horribly difficult to maintain, apart from obnoxious C preprocessor issues. However, imake is very, *very* heavily dependent on the exact details of the X configuration. If upstream is abandoning imake, my worry on trying to maintain it would be that the X configuration may drift away from what imake can deal with. I've done that sort of X configuration hacking to make imake install things in appropriate locations and use the right compilers in the past. It's not fun work; it's painful, tedious, and exceedingly boring, and I wouldn't recommend it if you can avoid it. -- 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: Bug#350231: ITP: libsocket++ -- a family of C++ classes for Socket Operations
James Vega <[EMAIL PROTECTED]> writes: > Copyright Notice: > - > Copyright (C) 1992-1996 Gnanasekaran Swaminathan <[EMAIL PROTECTED]> > Permission is granted to use at your own risk and distribute this > software in source and binary forms provided the above copyright notice > and this paragraph are preserved on all copies. This software is > provided "as is" with no express or implied warranty. That license doesn't appear to grant the right to distribute modified works. -- 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: Bug#350231: ITP: libsocket++ -- a family of C++ classes for Socket Operations
James Vega <[EMAIL PROTECTED]> writes: > On Fri, Jan 27, 2006 at 07:52:35PM -0800, Russ Allbery wrote: >> James Vega <[EMAIL PROTECTED]> writes: >> >> > Copyright Notice: >> > - >> > Copyright (C) 1992-1996 Gnanasekaran Swaminathan <[EMAIL PROTECTED]> >> >> > Permission is granted to use at your own risk and distribute this >> > software in source and binary forms provided the above copyright notice >> > and this paragraph are preserved on all copies. This software is >> > provided "as is" with no express or implied warranty. >> >> That license doesn't appear to grant the right to distribute modified >> works. > If I'm unable to contact the original upstream for > clarification/updating the license, this could go into non-free, right? A license that says that Debian can't redistribute modified source is problematic even for non-free, since it means that Debian can't fix security vulnerabilities. -- 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: when and why did python(-minimal) become essential?
Josselin Mouette <[EMAIL PROTECTED]> writes: > If a good number of scripts that would be worth including in the base > system were written in haskell or scheme, I would be the first one to > support that inclusion. Which scripts written in Python do you feel should be included in the base system and cannot be currently because Python isn't included? Be specific. A killer application that everyone wants to have in base will be the way that Python would enter base; without that, I think this discussion is largely a waste of time and an invitation to back into argumentative corners that can only result in hurt feelings. Personally, I write both Perl and Python, and if some fantastic core component of Debian ended up being written in Objective CAML, I think that would be a great excuse to learn Objective CAML. But bickering over which language is best isn't going to get us anywhere. There's a pure resource tradeoff involved, and any language, including Perl, has to pass a cost/benefit analysis that involves real applications we want to run in base. Obviously, once the language is already in base and is already being used, the cost/benefit analysis reverses and one instead starts looking at the cost of removing it. The inherent merits of the language rarely end up being a decisive factor. -- 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: when and why did python(-minimal) become essential?
Josselin Mouette <[EMAIL PROTECTED]> writes: > There have already been - admittedly sporadic - proposals to rewrite > some key parts of the system, like the init scripts or adduser, in > python. However, if the proponent knows from the beginning the > implementation wouldn't be accepted because of the language it is > written in, you can't expect him to start working on it. Well, if those people don't mind their policies, now there's Ubuntu with python in essential. That work, if good, won't go to waste even if Debian doesn't want it. There's a testing ground in Ubuntu for rewriting some core component in Python and making it much better, so much better that we all gasp in appreciation and want it in Debian too. Not all rewrites are improvements, so I don't get particularly excited about people's plans to rewrite something and make it so much better. Few rewrites that are started actually finish. The few that are often introduce lots of new bugs in exchange for the old, known, worked-around bugs. -- 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: Bug#352912: general: Reduce network load using zip packaging and VFS
Портон Виктор Львович <[EMAIL PROTECTED]> writes: > Not always. For example, apache2 package is split into two packages: > apache2 and apache2-doc (and also apache2-dev and several others). To > Build apache2 binary package most of documentation files are not > needed. In the case of apache2 downloading only needed files (e.g. using > compilation directly from network filesystem) would be big traffic save. I still don't understand what problem you're trying to solve by reducing downloads for source packages, even if successful. Very, very few people download source packages. Debian is a binary distribution. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Re: Bug#353381: ITP: freebsd-manpages -- Manual pages for a GNU/kFreeBSD system
Joe Smith <[EMAIL PROTECTED]> writes: > Sorry to change the topic, but looking at some of the manpages in the > "manpages" package, and some of the pages in the "manpages-dev" causes > me no notice some pages that look like they probably should be in a > different package. Your points about sync(8) and tzselect(8) seem reasonable on the surface, but the rest of this seems to be disregarding the fact that manpages and manpages-dev are not native packages. Those man pages are included in that package because they're maintained together upstream in a distribution that Debian packages. There are various reasons why the man pages for libc interfaces are in a separate package that probably aren't worth getting into; suffice it to say that libc upstream is probably not going to incorporate and maintain the relevant man pages. Also, it makes less sense than it sounds to include the section two man pages with Linux rather than separately in the manpages-dev package; the userspace API is often not exactly the system call exposed by the kernel, since libc mediates the system call and often does some rejiggering of data types in the process. -- 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: Bug#353277: ndiswrapper in main
Anthony Towns writes: > If it's only useful for non-free software, we should probably consider > it. More likely, it's not useful at all, and we should consider > dropping it entirely. How many libraries do we have in this state? We went through this whole discussion with emulators, with people pushing them towards contrib under the theory that there was no free firmware for them to play. Then people packaged various free firmware just to get the emulators back into main. This process strikes me as a significant waste of time and energy, and I'm not sure what it's supposed to accomplish. If the package absolutely requires a piece of non-free software to work, or if it's an installer for non-free software (such as the various installer packages or the packaging wrappers around djb software), it goes in contrib. If it just implements some sort of API or ABI that isn't specific to some *particular* piece of non-free software, I think shoving it towards contrib is just a waste of everyone's time. As we already saw with emulators, free uses of that API or ABI tend to eventually materialize, making this distinction requires drawing a lot of thin and hazy lines, and (worst of all) it always sparks long, pointless threads about the definition of freedom on debian-devel. I don't think the distinction between main and contrib should be so unstable as to change based on the existence of some theoretical piece of third-party software. As long as the software implements some reasonably generic API or ABI that isn't inherently non-free and doesn't require a dependency on non-free software in the dpkg sense, I say just put it in main and not worry about whether anyone has used that API or ABI in free software yet. It saves on moving things around later, I can't see how it breaks anything in the DFSG, and it means one less controversial grey area decision that we have to make all the time. -- 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: PROPOSAL: debian/control file to include new License: field
Jari Aalto <[EMAIL PROTECTED]> writes: > To my understanding the only way to obtain the license information for a > package is to actually download it (or install it) and the study the > content of > /usr/share/doc//copyright > It would be better if user could use the packaging search commands, like > grep-dctrl -F License ... --and -F package ... Out of curiosity, why? What problem are you trying to solve? > PROPOSAL: > Add new field to the debian/control (which would be generated by > dh-make): > License: > It would contain a canonicalized word to describe the license in > questions, like: > GPL, GPL2, GPL3, LGPL, BSD, Perl Artistic, MIT/X . Custom This has been proposed before. One of the problems with this idea is that many packages have more complex licenses than that, ones that cannot be easily encapsulated into a single term. Many packages contain files under various different licenses and many packages are covered under minor modifications to standard licenses, so coming up with these terms becomes a bit complicated, can't be fully accurate, and seems likely to spawn a complicated set of rules that are hard to verify. In other words, it seems like a lot of work, and it's not clear what problem it would really solve. -- 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: 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: ./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]
Re: ./configure in debian/rules
Pjotr Kourzanov <[EMAIL PROTECTED]> writes: > Russ Allbery wrote: >> 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. > I suppose the patches to debian/rules would be welcome on this list, no? I certainly would welcome patches for any of my packages. However, I'd prefer that they be submitted as bugs. I'll get to it eventually as I do new uploads, so don't feel like you have to file bugs. -- 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
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > I'm one of the people who actually helped design the GNU Makefile and > configure standards, and --host does not "signal that you're > cross-compiling." What signals that you are cross-compiling is a > disagreement between --host and --build. That's the old way. Autoconf changed this in the current releases. Now, specifying --host signals that you're cross-compiling, whether it disagrees or not. Yes, this was not a backward compatible change. A lot of people were upset about it. And yes, it was a change in the GNU Makefile and configure standards. But see the current Autoconf manual: `--host=HOST-TYPE' the type of system on which the package will run. By default it is the same as the build machine. Specifying it enables the cross-compilation mode. There's a long archived discussion on the Autoconf mailing list about it. -- 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
Miles Bader <[EMAIL PROTECTED]> writes: > Russ Allbery <[EMAIL PROTECTED]> writes: >> `--host=HOST-TYPE' >> the type of system on which the package will run. By default it >> is the same as the build machine. Specifying it enables the >> cross-compilation mode. >> There's a long archived discussion on the Autoconf mailing list about it. > Is there a one-sentence summary of the reason for the change? It's been a while, and I'm not sure that I completely followed the discussion and all of the arguments. However, if I were to hazard an attempt, I'd say: The new behavior is easier to explain, easier for humans to predict in the presence of auto-generated arguments to --host and --build, and easier to implement in Autoconf. -- 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
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Russ Allbery <[EMAIL PROTECTED]> writes: >> That's the old way. Autoconf changed this in the current releases. >> Now, specifying --host signals that you're cross-compiling, whether it >> disagrees or not. >> Yes, this was not a backward compatible change. A lot of people were >> upset about it. And yes, it was a change in the GNU Makefile and >> configure standards. > I'm not sure this was appropriate. Autoconf may be the most frequent > generator of configure scripts, but the standards for the operation of > configure scripts are not written by autoconf. > So, leaving aside the autoconf manual, did the actual GNU configure > standards change? It may have, although I don't know what it said before. What it says now appears to be consistent with the current Autoconf behavior, although apparently doesn't require it: To compile a program to run on a host type that differs from the build type, use the configure option --host=hosttype, where hosttype uses the same syntax as buildtype. The host type normally defaults to the build type. If it says anything else about this topic, I can't find it in a quick look before a meeting. There doesn't appear to be any specific mention of "mismatch" or the like, so a very strict reading of the above would imply that the behavior is undefined if --host is specified but equal to the build type (since the standards document doesn't explicitly spell out what happens then). -- 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: "but ./configure makes it look so easy", or why cross compiling isn't always trivial
Peter Kourzanov <[EMAIL PROTECTED]> writes: > Peter Samuelson wrote: >> Of the six or so packages I'm involved with, three of them need more >> than just '--host'. (And two of the others are arch:all, so there's no >> need to cross-compile them anyway.) If that's representative, you're >> looking at a *lot* of work by a *lot* of people to realise your dream. >> Well, that or a *lot* of work by you, to write and submit patches for >> all these packages. > Yes. But if I can convince maintainers then I suppose this can become > *less* work for a *lot* of people:-) It is often not at all trivial to redo the build process to avoid having to build and run programs. The amount of work that the GCC maintainers put into this is significant. I'm afraid that for many other packages, people are going to question whether the amount of work required is really justified. You'd probably be best off picking a subset of packages that make sense to cross-compile and focusing on them rather than hoping for the entire distribution. The entire distribution includes things like the full Mozilla suite, and it would surprise me if cross-compiling such things was really on anyone's radar or will be. (Apologies if Mozilla has put a ton of work into that already -- I'm fairly sure that the example could be replaced by dozens of other large packages if need be.) -- 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: Maintainer for fftw 2.1.3 requested
James A Treacy <[EMAIL PROTECTED]> writes: > BTW, how does one go about getting their name removed from being > listed as the maintainer of a package(s)? Bugs were filed against wnpp > in Aug 2004 to orphan the fftw packages listed above but I still am > getting all mails related to them. You have to do a new upload with the maintainer set to the QA group. I had no idea that those were orphaned. See: <http://www.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-orphaning> although it could perhaps be slightly more explicit. -- 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: NEW queue backing up again -- ftpmasters, any explanation or comment?
Brian May <[EMAIL PROTECTED]> writes: >>>>>> "Simon" == Simon Richter <[EMAIL PROTECTED]> writes: > Simon> The main reason for the NEW queue is the US export > Simon> legislation. If it were legal to make packages immediately > Simon> downloadable, it would be done. > In which case why do new packages with known source code end up in the > NEW queue? I'm dubious that's really the main reason for the NEW queue. Looking at <http://ftp-master.debian.org/REJECT-FAQ.html>, the ftpmasters check a lot more than that. In addition, they also verify licensing issues. I consider that check to be an integral part of the Debian QA process and wouldn't want to do without it. US export legislation is the reason why we don't make things in NEW publically available until after they've been processed, but that's a different issue. -- 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#304709: ITP: libafs-perl -- Perl interface to the AFS distributed filesystem
Package: wnpp Severity: wishlist Owner: Russ Allbery <[EMAIL PROTECTED]> * Package name: libafs-perl Version : 2.2.3 Upstream Author : Norbert Gruener <[EMAIL PROTECTED]> * URL : http://www.mpa-garching.mpg.de/kwiki/nog/afsperl/ * License : GPL or Artistic (Artistic in practice, see below) Description : Perl interface to the AFS distributed filesystem AFS is a distributed filesystem allowing cross-platform sharing of files among multiple computers. Facilities are provided for access control, authentication, backup and administrative management. This package provides Perl bindings to the AFS APIs, including support for doing in Perl nearly all of the operations possible with the AFS client programs. Note that the licensing on this package is a bit subtle, although it shouldn't be a serious problem. The module is licensed under the standard Perl terms of the user's choice of GPL or Artistic, but OpenAFS is licensed under the IBM Public License, which is DFSG-free but incompatible with the GPL. Therefore, the Artistic license is the license one has to consider when looking at the combined work. Also, the upstream source includes a copyright notice and license from Stanford University for the original version of the module. This is our old license agreement, which is not clearly DFSG-free (it doesn't clearly grant the right to distribute modifications). However, Stanford University has since relicensed the original code under the DFSG-free MIT license that's compatible with most everything. I've told the upstream author about this, and this will also be clearly noted in the copyright file of the package. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.26 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304728: ITP: webauth -- Cookie-based web authentication using Kerberos
Package: wnpp Severity: wishlist Owner: Russ Allbery <[EMAIL PROTECTED]> * Package name: webauth Version : 3.2.4 Upstream Author : WebAuth Team <[EMAIL PROTECTED]> * URL : http://webauthv3.stanford.edu/ * License : MIT/X Description : cookie-based web authentication using Kerberos WebAuth is a cookie-based web authentication system built on top of Kerberos. It relies on a central authentication server that handles all user authentication for a domain and creates user authentication credentials for any web server that needs strong authentication. This package differs from mod_auth_kerb in that it will work with any browser, not just those supporting SPNEGO, without sending the user's password to each web site to which they wish to authenticate. It supports a form of single sign-on in that a user only has to autheticate once to the central authentication server and then can visit any web site within that authentication domain without needing to reauthenticate. This package comes in two sections, an Apache module and supporting library for all of the servers that want to authenticate users and an Apache module and supporting scripts for the central authentication server. It also has Perl bindings for its library, which are used by the authentication server user front-end. As a result, the current plan is to break it out into nine packages: libapache2-webauthApache module for client web servers libapache2-webkdc Apache module for central authentication server libwebauth3-perl Perl bindings for the WebAuth libraries libwebauth1 Supporting WebAuth shared library libwebauth1-dev Development files for WebAuth shared library libwebkdc-perlPerl modules for central authentication server webauth-tests Test suite for client web server webauth-utils Command-line utils for WebAuth key management webauth-weblogin User front-end to central authentication server Note that libapache2-webkdc depends on the S/Ident libraries for full functionality. An ITP for S/Ident will be filed in a moment. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.26 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
