OT: appealing to the puritan interest [was Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor]
> You can't distribute text with the word "fuck" in it anywhere to minors in > the > US? > > Truly remarkable. Are there any minors reading this? Where do I hand myself > in? Well, you would need to check the penal codes of each individual state wherein such a minor resides; some states will allow you to write "fuck" to a minor as long as the work in question does not lack "serious literary, artistic, political and scientific value for minors." Some states will give you a pass because the "fuck" is electronic and not tangible. Were you to have transmitted the "fuck" from another state, you would also be guilty of interstate trafficking in material harmful to minors, so you could be prosecuted by the Federal government as well as whichever state you manage to find willing to prosecute you. I don't know how this applies to offenders from the UK. IANAL
Re: OT: appealing to the puritan interest [was Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor]
> It's "prurient", not "puritan". > > "dict prurient" will explain. Thank you for misinterpreting the wordplay. Please take this discussion to another mailing list or end it completely. These arguments have been rehashed within Debian since what I believe to be its original inception 7 years ago, when a bunch of concerned and open-minded people tried to block inclusion of the purity package. Rather than lose the purity package, we lost some of those people instead.
Re: Moria, as in the Author of
> Do you think moria still has a place in Debian? Or do you gather it > might be better removed? A better question is whether Mr. Koeneke is willing to relicense his code under a free software license so that moria and angband and derivatives can finally be free. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problem of savelog
> ii debianutils2.12.0 Miscellaneous utilities specific to Debian > ii exim 3.36-13An MTA (Mail Transport Agent) > > Is there anyone who encountered the same problem or is this > Alpha specific or even specific to my machine? This should be fixed in debianutils 2.13.0. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with - and ' in some man-pages
> Nevertheless, I don't know if it's a problem of the manpage system or of > the manpage writers, and how the writers could circumvent/solve the > problem. And this information would be useful before I start filing > bugs, or!? This is a bug in the manpages themselves. The unformatted source should have - for hyphenating normal prose, as in "happy-go-lucky", and \- to denote the minus signs used as characters on the command line and other such places. If the proper groff characters are used, your cut&paste and searching problems will vanish and everything will look pretty. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] OpenLDAP automatic upgrade
> Should we notify the maintainers to better go back to 4.2 for sarge? Don't bother notifying me; I won't be switching anything back to 4.2. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] OpenLDAP automatic upgrade
> Why? (technical reasons, please). Not that I am assuming there is enough > evidence to downgrade anything but OpenLDAP just yet, but your reply seems > to imply that even if there were, you would still not downgrade. 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. So, given that I don't see any reason to expect problems from db4.3, and that it would be painful for sarge and sid users to switch back to db4.2, I don't intend to do so. Now, as far as pestering other maintainers goes, I don't believe there's a point there either. Most of the packages currently built against libdb4.3 don't use transactional environments, and thus cannot be bitten by the txn log problem mentioned by Quanah Gibson-Mount. If there are any real problems with software built with Debian's db4.3 packages (which are built quite differently than Fedora's, for example), they should be reported so they can be fixed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] OpenLDAP automatic upgrade
> Only now I would trust BDB 4.2 with any mission critical data... but then, I > am the one which still builds Cyrus 2.1 against BDB 3.2 for stability (Cyrus > 2.2 will be built against BDB 4.2). IIRC, BDB 3.3 addresses very serious problems in 3.2, but we can't have 3.3 in Debian without a painful libdb3 transition. > On a tangent, why do we still have BDB 4.1 on Debian? Isn't it "not > exactly safe" on SMP and SMT machines? Or were all bugs fixed in 4.2 also > fixed there? As soon as packages stop depending on 4.1, it is likely to be removed altogether, just as 4.0 was. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: StrongARM tactics
> The buildd maintainer is one of the 'notoriously difficult to reach' > people in Debian. If you were interested in trying, contacting the > mailing list for the port is the obvious next step. What can the people on such a mailing list do about buildd issues? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
> The job of the buildd admin is to make sure packages are built. Mostly > that's automated, which is great, which means the buildd admin's job is > mostly to keep the automation working. Dan was a really good buildd admin. Maybe he knows what he's talking about. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Access to svn.debian.org
> 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
> True. However, the issue in question is whether or not it would be > better if they maintained in teams. I imagine that it would not be better. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
packages for sale
I intend to orphan the following packages: bricolage dbacl libcache-mmap-perl libmasonx-interp-withcallbacks-perl libparams-callbackrequest-perl libstring-crc32-perl scottfree ttf-kacst ttf-paktype If you want one of these, upload it with yourself as Maintainer. Immediately. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages for sale
Thanks to those who saved me the time and hassle of filing some wnpp bugs. > bricolage #348948 > dbacl #348949 > libcache-mmap-perl #348951 > libmasonx-interp-withcallbacks-perl #348952 > libparams-callbackrequest-perl #348953 > libstring-crc32-perl #348954 > scottfree #348950 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package priorities and dependencies.
> Does this make sense to anyone but me? It seems unnecessary for shared libraries to have priorities if they're useless without programs which depend upon them. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Package priorities and dependencies.
> I don't see your point, and you seem to have missed mine. My point is that there's no need for a package with no user-level functionality of its own, such as a library, to have a priority of its own. If an Important package such as 'at' depends on libelf0 for whatever dubious reason, libelf0 might be important. However, for systems that don't install 'at,' libelf0 is pretty much useless, and its classification as 'important' would be silly. It makes more sense to me for libraries to not have any priority, or more in line with your idea, have some mechanism in which the library will inherit the highest priority of the selected packages that depend upon it. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
> Those who have no space for documentation on their system should use "rm". > Our next package system will be able to use a policy file to exclude > installation from certain directories, like /usr/doc, which will make this > easier for the user who wants to exclude documentation from a system. What if one wants to exclude only HTML documentation? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
> For Deity, I suppose we could make pattern-matching work in the policy file. I think that would be preferable to simple directory exclusion. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
> Well, you're going to need a script to implement that policy. Probably > the best way to handle this is to provide a way to tell the package system > that you have deliberately removed a file, and that this file should not > be replaced. I wouldn't expect this in version 1.0 . What exactly is the rationale behind the HTML mandate? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt Important (was Re: dc and bc in Important?)
> "bare minimum" doesn't extend to a compilation environment. > or to printing, IMO. > > * netbase and netstd should both be there, they are standard > >on Unix It seems as though the implicit definition of "standard Unix system" omits a declaration of intended usage. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: watch files and weird version numbers
> I'll do that (they also used 1.7b which means "second release candidate > for 1.7), but I probably won't be able to rewrite history and make 1.55 > disappear... I had this problem before and used the equivalent of 1.70. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linda warnings
> Well, I did not talk about regular snapshots, but about direct exports. > Some tools in Debian (like "darcs-buildpackage", thank you John for > this) make it possible to make such SCM builds. However the Autotools > output is not versioned, so not included in the tarball. It is possible to run autoreconf with both cvs-buildpackage and arch-buildpackage. If darcs-buildpackage can't run a prebuild trigger or target, I'd say that it's deficient. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
> I may do that too, but its architecture support is abysmal compared to > Debian, so I have no choice in the matter at this point (and lack the > time to port ubuntu to all my archs). Perhaps the SCC plan will help make that choice easier for you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
> In every single patch system I've encountered, you can run debian/rules > patch and get the patched source. It's only one more command and I consider > it universal for all patch systems deployed in Debian. In some cases, this will fail if you don't have the build-dependencies installed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy (was: First draft of review of policy must usage)
> Here's a proposed patch. What do people think about this approach? I > know there was an inconclusive Policy discussion a while back about how > best to deal with this issue. As you can tell from this patch, I favor > the approach of documenting the specific features that we require and > assuming that their semantics are sufficiently clear in practice. > + the -a and -o test operators > + must be supported If people think this is a good idea (and I am not one of those people), then this wording is much too vague. At least one shell implements '-a' and '-o' as unary primaries, whereas what you mean by this patch is almost certainly to mandate support of '-a' and '-o' as binary logical operators. Again, the list operators "&&" and "||" can handle any legitimate need addressed by the -a/-o binaries. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
> Forgive me if I am wrong, but I was under the impression that posh was > created for the purpose of providing a shell which supports a minimum > of functionality required by policy against which scripts could be Not exactly a minimum. For example, posh implements a POSIX pwd builtin. If it were to drop this, one could argue that it still conforms to policy. However, scripts would be running /bin/pwd from coreutils instead, which is not POSIX-conformant, and things like the realpath() function in the tzdata postinst would fail miserably, because it depends on a POSIX feature of /bin/pwd. posh also implements test, echo, and kill, in more standards-oriented versions than those in coreutils and procps. Additionally, it provides true and false for no particular reason. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
> Why not ls? Judging by the lack of wishlist bugs requesting it and my own feeling of revulsion at the idea, I'd say that it's because no one wants it. A builtin ls might be a good idea for disaster recovery shells, though zsh-static does not have it. posh is not intended to be such a shell, nor to be particularly useful interactively. Since I cannot think of a legitimate reason for anyone to use ls in a shell script, I think it would add little value. If you disagree, feel free to file a bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy, version two
> Okay, here's try number two. I tried to incorporate the feedback from > various people. Please critique. Other than wanting the 'echo -n' and -a/-o bits to go away, I think this looks pretty good. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Explications needed...
> I think you're confusing the buildd admin with the porters. I expect Maybe that's because the buildd admins used to be the porters, and then, for some reason I do not understand, this mysteriously stopped being true. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kdemultimedia and libtunepimp
> ATM kdemultimedia (and therefore kde) is uninstallable on any arch > except amd64 because libtunepimp2c2a has not been built. I see from > the changelog of libtunepimp3 that it was renamed, so shouldn't > libtunepimp3 provide and replace libtunepimp2c2a or the dependencies > of noatun, juk. amarok, etc. be changed? The latter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where is the mysql package?
> Which installation method are you using in dselect? In think you have to > specify the directory "debian/dists/unstable" as base directory and select > distributions "main", "contrib", and "non-free". This would be nice, but the Packages files seem to be set up for /debian to be the base directory. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New QMail discussion list.
> The primary MTA? does that mean that more than one MTA can be installed on > Debian at once? I thought they all conflicted with each other. They do, and that should change.
Packages should not Conflict on the basis of duplicate functionality
The apparent solution to something like bug#45344 is to have all the packages providing an identd to conflict with one another. While reasonable in most cases, this has the horrible side effect of not letting the administrator have multiple identds on the system. What if I have a machine with three IPs bound to its primary interface and want to run midentd on one, oidentd on another, and pidentd on the third? Well, first of all I would have to replace Debian's inetd with something more configurable, but then I would be forced to deal with the package manager, which really should have no business preventing me from having as many implementations of identd as I like. Perhaps identd isn't an example to be taken seriously. So let's say that I have a POP server. I want to have qpopper running on port 110. Then I want cucipop running on port 995 through stunnel for users who want to use SSL. Then I want to run gnu-pop3d on a high port for testing purposes since it's brand new and I don't want to throw it into production without testing it first. What happens? Well, nothing, since all three packages cannot coexist peacefully. qpopper has nothing to say about the matter, but cucipop expressly conflicts with it, in addition to conflicting with pop3-server, which both it and gnu-pop3d provide. These packages don't conflict; they merely provide the same service. There is no reason that these three packages cannot coexist on the same system. Any namespace overlap can be solved by alternatives or renaming, as such things are normally rectified. Debian policy should proscribe such inconveniences.
Re: Packages should not Conflict on the basis of duplicate functionality
> Okay, then solve the problem of which one should actually work on the > standard port? You can't use update-alternatives if the software is Well, I would prefer that things didn't start listening for connections without asking first, but I can't imagine that that's a popular suggestion. > launched in a different manner. If you have such an advanced setup, it > isn't really that hard to build it yourself, or use --force. And if I did an apt-get dist-upgrade, I would get this: Reading Package Lists... Done Building Dependency Tree... Done You might want to run `apt-get -f install' to correct these. Sorry, but the following packages have unmet dependencies: cucipop: Conflicts: pop3-server Conflicts: qpopper but is installed gnu-pop3d: Conflicts: pop3-server E: Unmet dependencies. Try using -f. And if I were to do an apt-get -f dist-upgrade, it would remove gnu-pop3d and qpopper, leaving cucipop. So what you're telling me is that anyone with a "complex" setup shouldn't bother using Debian?
Re: Packages should not Conflict on the basis of duplicate functionality
> Of course. Now if you built them yourself, dpkg wouldn't touch them. If I wanted to build them myself, I would use Slackware. If I repackage them I will need to remove the Conflicts line from the control files every single time I upgrade. > People who want such "complex" setups should have enough sense to be able to > figure out how to make them work, without imposing additional difficulty on > the maintainers for such a rare case. There is not generally a use for more > than one POP server, ident server, mail server, etc. I can find exceptions, > but it isn't Debian's job to make every possible configuration easy, just > the most likely and typical ones. The most likely and typical configurations are those for a home workstation. So let's screw anyone who wants to use Debian on a production server. I run apache and roxen on the same machine. That's hardly typical. Why on earth would anyone want to run two different web servers? These two packages should obviously conflict since they're both web servers and want to grab port 80. They both provide httpd; should I file bugs against them demanding that they conflict with it too?
Re: Packages should not Conflict on the basis of duplicate functionality
> If you want to run two httpd's, popd's or mta's, you'll probably have to
> do more than the usual tweaking to the package setup anyway, so what is
> really the big deal of having to:
>
> 1. `apt-get source foo`
> 2. edit various files, mostly in debian/
> 3. add an epoch to the package version
> 4. `fakeroot debian/rules binary`
> 5. `sudo dpkg -i foo.deb`
What's really the big deal of having to
1. apt-get install apache roxen
By putting an epoch in the version number you defeat the whole automatic
upgrade system.
> If you must insist that these matters be resolved formally, then please be
> so generous to provide us with some reference implementations of a generic
> /usr/sbin/{httpd,popd,smtpd}-config.
I see absolutely no need for an httpd-config. I'm perfectly happy
with they way apache, apache-ssl, and roxen coexist.
Re: Packages should not Conflict on the basis of duplicate functionality
> And of course you can always do dpkg --force-conflicts. I believe that's what > the --force commands are really there for: special situations. Broken situations. Sure, you can --force dpkg to overwrite files from another package. But Debian prefers to fix the problem instead.
Re: Packages should not Conflict on the basis of duplicate funct
> a) I would not test a new daemon on a working machine, I would use a separate So? > b) if you know what you are doing, compile the packages by hand, fix their > install scripts, and remove the conflicts. You are trying to circumvent the > norm. If I wanted to compile them by hand, why would I even bother with the Debian packaging system? > Debian is operating on making the easy case easy. 90+% of our users want to > just install a package and go. Perhaps we would have more users if we didn't maintain such a mentality. 90+% of our users probably don't run production servers. Is there some reason you don't want to cater to 100% of our users if possible?
Re: Packages should not Conflict on the basis of duplicate funct
> Because as everyone knows the last 10% takes 90% of the work and often ends up > hurting the other 90%. Then it's being done wrong. > The point is Debian needs to work for as many people as possible. We are > doing Yes, that's exactly the point. > apt-get source qpopper [...] > dpkg -i qpopper-.deb > That is about all you need do. To be fancy, you could "fix" the postinst and > what not to not have the two stomp on each other. What's so hard about wget ftp://ftp.qualcomm.com/eudora/servers/unix/popper/qpopper2.53.tar.Z tar zxvf qpopper2.53.tar.Z cd qpopper-2.53 ./configure --options make su make install > The point is if you are claiming to know enough to test devel code, experiment > with server configs and the like, but are not willing or know enough to > compile a few apps, then maybe you are in the wrong line of work. That's ridiculous. What you're implying is that Debian is for people that don't know how to compile their own software. It's not. If anything, mucking about with debian/control is more work than getting the pristine source and installing into /usr/local. Why even bother with packages then? Why do we waste valuable disk space on master by compiling for other architectures when they can quite easily do apt-get -b source? I mean, the majority of Debian users have to be i386ers. Why waste all that work providing a binary distribution for m68k? Most Debian users are never going to have any use for a m68k .deb. And Debian SPARC? Please. Why should we waste our time when Solaris works just fine? And Alpha? Those people are always sending in patches complaining about 64-bit compilation problems. It just complicates things for everybody. There can't be that many people using Alpha. Obviously they can patch their own sources and not bother us with fixing the upstream. Why should we? I'll tell you why. Because if it won't compile on that arch, it's BROKEN. Just like having POP servers conflict is BROKEN. > And by first point still stands, what you want runs against what most people > would call a "production" server. I would never run an untested daemon on a > box w/ clients. God knows what will happen. I could show you entire engineering departments that insist on confusing development and production. Running a test daemon on an alternate port is hardly as ridiculous as changing live code. I would never run KDE on a "production" server, but bet there are quite a few people who would. (Yes, I said "server.") Guess what, Debian lets them. > Now I do agree with your initial statement, not all things should conflict. > wmcdplay and xmcd both play cd's -- they dont conflict. However a deamon > provides a known service that only one should be performing at ALL times. That is a very narrow viewpoint. I am looking right now at a machine with 4 inetd.confs (one for each IP). This is FreeBSD, so they can do that. They aren't running anything on the auth ports (and there are 4 auth ports--1 primary IP, 2 aliases, and 1 localhost). They could quite easily run 4 different identds out of the four different inetds, with no conflict except the one in your mind. Now, of course, Debian's inetd doesn't support binding to specific IP, but hopefully that will be fixed in future.
Re: Packages should not Conflict on the basis of duplicate funct
> Ok, let's bring this back to implementation. How would you propose we handle > this? Currently daemons install, set themselves up, and begin running. > > a) we can prompt. > b) we leave everything off and let the admin turn it on (not an option for > obvious reasons) > c) first come first serve -- first daemon installed does its job, the rest > install unconfigured > > any others? d) have something that keeps track of installed services, perhaps with priorities akin to alternatives. If there weren't an issue of services being run either in inetd or standalone, this could be accomplished with a souped-up update-inetd.
Re: Packages should not Conflict on the basis of duplicate functionality
> the "we-know-better-than-you" attitude is what redhat and caldera (and > microsoft, for that matter) does. it sucks. debian has always done > better than that - our way is to encourage people to learn to do it for > themself by not trying to hide the fact that knowledge and experience is > required (not just optional or "would be nice" but absolutly required) You don't think that "you only can have one daemon for a particular service and it's going to be turned on by default" is representative of the "we-know-better-than-you" attitude?
Re: Packages should not Conflict on the basis of duplicate functionality
> debian's attitude is: if you want something different, DIY. and more > importantly, it lets you DIY. Err.. what Unix DOESN'T let you DIY?
Re: Packages should not Conflict on the basis of duplicate functionality
> read the rest of my message. the bit that ranted about unix's that > get in the way of DIY. RH is one. sun's Netra is another...both are > examples of how NOT to do configuration management on unix. No. You're talking about doing something your way and then having it wrecked by the RH/whatever way. And if you decide to do something your way in conflict with the Debian way, Debian may wreck your work too. If I'm running /usr/local/sbin/sillycommercialpop3d, or /opt/sillycommercialpop/sbin/pop3d or wherever it should be stuck, and I want to install php72-pop3 which Requires pop3-server, and I naively apt-get install php72-pop3, not thinking it would require a local pop server or thinking that my pop server should be sufficient, I'd probably end up with a nice little tagalog pop server that installs itself in inetd and steals the port. There are two simple solutions to this. Either you do it the Debian way and package up sillycommercialpop with a Provides pop3-server and maybe a Conflicts pop3-server if you're feeling vindictive, and then you install the deb, or you never rely on Debian's automation again. When I recommend to people that they use kernel-package instead of DIY, they are usually a bit shocked.
Re: Packages should not Conflict on the basis of duplicate functionality
> There is currently no default -- it varies on a per-package basis. I note that ### to run vtund as a server on port 5000, uncomment the following line: #--server-- 5000 isn't uncommented by default.
Re: Packages should not Conflict on the basis of duplicate functionality
> Or are you saying something else? I was merely pointing out the irony of one of Craig's packages not enabling the daemon by default.
Re: Packages should not Conflict on the basis of duplicate functionality
> it isn't useful to run the vtund server until it is configured. there > is no "standard" configuration which is suitable for shipping as a > default - it MUST be customised for each site, each tunnel must be setup > individually. When did "useful" enter this discussion? pipsecd starts the daemon automatically even though no tunnel has been set up, and even if userlink-modules hasn't been installed. And even though it is of absolutely no use to you, the daemon starts running when you install the package. And if there's some sort of exploitable back door in the code, you're vulnerable. But fine, you think security is a non-issue. You seem to recognize at least one situation where it is counterproductive for Debian to make an assumption about the user's configuration. Why can you not recognize others?
Re: Packages should not Conflict on the basis of duplicate functionality
[Craig flaming Doctor What deleted] > if someone doesn't want a service enabled then they should not install > the package that provides that service. if they want the service, then > install the appropriate package. simple. their choice to install or not > install. > > now what is so fucking difficult to understand about that? The reasoning behind why anyone should share that opinion. I'm at a loss. Sure, you can --unpack a deb to get to the files without running the postinst or whatever starts these evil daemons, but why should --install be synonymous with "run"?
Re: Packages should not Conflict on the basis of duplicate functionality
> No, this is silly. When you install a package, it is for use. If you > don't intend to use it, why install it? Perhaps you can explain where this idea comes from. Of course, if I want to evaluate a daemon, I can --unpack the package into /usr/local/testfun and manually enable it, evaluate it, and then rm -r it. Sure, that's possible. And I can also compile it myself from dsc and munge the install scripts. Or I can build it from pristine source and stick it in /usr/local. So clearly nothing is preventing me from reaching my desired ends even if it prevents the preferable means. But I install packages I don't intend to use. On certain systems I'll install tcsh or csh. I have no intention of using them (this is aside from any package that might require a csh provider), but there is the potential for a user to want tcsh there sometime in the future, and if he is not clueful to get it on his own, he'll be okay because it's there. Having a shell package going and changing users' shells on install would be horrific, though I doubt anyone would dispute that. There are daemons that can be run legitimately by a user on high ports. Let's say you have a system where you let people run web servers in user space. Luckily, roxen and apache don't conflict with one another, so you can easily have both available for users to use, and edit the configs so that neither of them run on port 80 or any other system port. The daemons are being used; they're just not being used in the "standard configuration." On the downside, one cannot reasonably assume that if one installs both packages that roxen will grab port 80 on bootup. If you have packages conflict, then yes, you can be pretty certain that the pop server you've installed is the one that will be grabbing port 110 on all IPs, because any other pop server has been removed. So if the consensus is that "debconf should handle it," why don't we stop the flaming and whining and figure out the logistics of the matter?
Re: 5 days till Bug Horizon [zsh]
> > Package: zsh (debian/main).
> > Maintainer: Clint Adams <[EMAIL PROTECTED]>
> > 58941 core dump with function mycd() {builtin cd "$@" && echo $PWD}
> > [STRATEGY] Fixed in the next .deb. Already fixed upstream. (Mar15MH)
>
> That is a week ago, has it been fixed since then?
My apologies. I've been extremely overworked. I'll upload a new
.deb ASAP.
Re: Intent To Split: netbase
> No real reason? Only one package can listen in on port 25, and Only one package can listen on port 25 of one IP. It is possible to have multiple packages listening on different ports or different IPs.
Re: WTF does zsh 3.1.9 does in potato-proposed-updates ?
> Why a new zsh was introduced in potato-proposed-updates ? It's not > compatible with thw previous version... What do you mean, it's not compatible? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WTF does zsh 3.1.9 does in potato-proposed-updates ?
> The completion control system has changed, along with a few other > minor details. I am myself a zsh user and have since made the > adjustment; I'm not sure the attitude others have towards their > zshrc's. A number of the mechanisms used prior to zsh-3.1.x to > control the completion behavior are no longer available at all. > This is probably the source of his complaint. I don't believe that's true. The compctl stuff in 3.1, though deprecated, should be, on the whole, behave the same as it did in 3.0. However, that's irrelevant, because the version present in virgin potato is 3.1. Any new-style completion system "incompatibilities" between the version in potato and the one in proposed-updates can be considered bugfixes. There is no point in supporting the version in potato longer than necessary, as there have been numerous bugfixes since then, both within the completion system and elsewhere. In short, a new version should definitely be included in the next point release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WTF does zsh 3.1.9 does in potato-proposed-updates ?
> I've opened a bug against zsh for the aforementioned behavior. Fine. We can move the discussion there then. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: coreutils with acl support
> (Please CC: me, I no longer track debian-devel) Your M-F-T is broken. > I am contemplating the upload of a version of coreutils that will have > support for file acls. (I.e., mv & cp -p will preserve acls, and ls -l How about selinux support?
Re: FTBFS problems caused by texi2html changes
> texi2html's behavior changed recently: if it is invoked with > -split=chapter, old versions place the HTML files in the same > directory as the documentation source, whereas new versions place the > generated files in a subdirectory. To get the old behavior, one can use --output . --split=chapter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: snownews maintainership
> So I want to highjack the package. > Any meanings? Do it. Pop the trunk. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: about to remove libdb4.1
> FWIW, this is just about the same response I got from upstream when I > asked them about the issue. The solution is of course to get rid of > libdb and use tdb or something equivalent. Maybe you should convince bogofilter upstream to keep supporting tdb. They're dropping it on the grounds that it's slow and useless. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Incorrect use of dpkg conffile suffixes and lintian checks
On Sun, Jan 20, 2008 at 04:44:34PM +0100, Adeodato Simó wrote: > In summary, `run-parts` is safe wrt .dpkg-bak, `run-parts --lsbsysinit` > is not. Easy enough to fix if need be. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
On Mon, Jan 28, 2008 at 05:37:03PM -0800, Russ Allbery wrote: > This work flow simply doesn't work with our current source package format > and a patch management system. Requiring this to work *with the current > source package format* essentially means outlawing using patch management > systems to manage Debian packages. That's why this proposal is > controversial. I agree with Lars that we should move toward requiring it to work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
On Mon, Jan 28, 2008 at 06:58:10PM -0800, Russ Allbery wrote: > If wig&pen provides a defined series, then I don't need more than that. I > don't know enough about wig&pen to tell you whether all the pieces are > already there. It does not. To programmatically convert from quilt to a wig&pen debian.tar.gz, one would need to discard the series file and rename all the patches. I don't know whether the effort of adding a series or 00list file to a dpkg format 2.1 is worthwhile, but it seems like it might make things easier. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of packages shipping shell scripts with bashisms + MBF proposal
On Sat, Feb 09, 2008 at 04:39:11PM -0800, Russ Allbery wrote: > This one is somewhat arguable. Pure POSIX doesn't allow signal numbers, > but the XSI extension to POSIX does and dash and posh both support them. > We do not, in general, accept XSI extensions, but it's hard to argue > strongly for excluding a feature that even posh supports. Since 0.5.6, it does not; the only number it understands is the pseudo-signal 0, mandated by POSIX. The reason POSIX doesn't allow numbers is that they are inconsistent from platform to platform. People who learn signals on a commercial OS of yore sometimes assume that signal 5 means something other than SIGTRAP on Debian, and script traps and kills that end up not doing what is intended. When the names are used, this confusion is avoided. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Wed, Mar 05, 2008 at 12:55:00AM -0300, Henrique de Moraes Holschuh wrote: > Isn't this going way out of proportion? That's the first I hear from any > *refuses* to merge, as opposed to "the merge not going to be done the way I > would like it to happen", and "it is taking too long for it to get merged". What's the difference, really? Isn't it a case of people on all sides trying to control each other instead of cooperating? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DD in Antarctic Continent?
On Sun, Mar 09, 2008 at 10:14:14PM +0900, Hideki Yamane wrote: > Hi list, > > Just a question. > > In Developer Locations page(*), it seems that Debian Developer is in > Antarctic Continent... awesome! Is it real?? Not that one; someone made a sign error with his coordinates. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DD in Antarctic Continent?
On Sun, Mar 09, 2008 at 05:13:14PM +0100, Lionel Elie Mamane wrote: > So he's really in very-northern Finland/Sweden/Norway/Russia? If I recall correctly, he was somewhere in or around Michigan. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: broken .orig.tar.gz (Re: package upload rejected - no email)
On Mon, Mar 17, 2008 at 04:27:03PM -0700, Russ Allbery wrote: > Joerg has been moving towards doing more of this, and I applaud him for > doing so. I hope that anyone else who works on NEW does the same. It's > one of our best opportunities to raise the general quality of the archive > up-front, rather than filing bugs and trying to chase down maintainers who > sometimes no longer care now that their software is in the archive. I disagree with this entirely. The critical part of NEW checking is the license: whether it's legal to distribute and whether it's suitable for main. Anything else can be fixed up after the fact, and discretion beyond that should be discouraged, in my opinion. Furthermore, since anything (including the license) can be broken in subsequent uploads, making the NEW checkpoint more meaningful could lull one into a false sense of security. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: broken .orig.tar.gz (Re: package upload rejected - no email)
On Mon, Mar 17, 2008 at 05:18:20PM -0700, Russ Allbery wrote: > The last part is certainly true, although I don't think that makes the > check at that point unuseful. The initial upload is the point at which > it's the most likely that significant misunderstandings or structural > flaws will show up. For example, someone who doesn't realize they > shouldn't repackage upstream without a good reason will tend to do it > every time, and hence it will show up in the initial upload. The bugs > introduced later tend to be (although aren't always) less rooted in basic > misunderstandings. The check is probably not unuseful. Instead of a report or a series of bugs, however, the result of that check is sometimes a REJECT and thus a need to re-upload to NEW. > As for having this be outside the scope of NEW and something we can check > later, I agree in principle, but in practice packages are rarely ever > looked at again in a comprehensive way after NEW except via automated > checks. I'm painfully aware of just how limited Lintian is. There are a > lot of problems that it just isn't in a position to notice. If we had a > regular practice of more detailed package audits of existing packages, > that would be great, but that generally doesn't happen until packages > change maintainers. In the meantime, NEW is structurally our best shot at > this. I'm not convinced that the majority of these uncaught problems are significant enough to worry about. I would be surprised, for example, if using a non-pristine tarball was ever regarded as a release-critical issue. Why slow down NEW processing to check things like that? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BitTorrent and ISP interference
On Thu, Mar 20, 2008 at 08:50:11AM +1100, Ben Finney wrote: > William, please follow the Debian mailing list code of conduct > http://www.debian.org/MailingLists/#codeofconduct>; specifically, > don't send me individual messages that are also sent to the list, > since I didn't ask for them. How many times do people have to cite this stupid thing before someone removes it from the website? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .desktop files for x-www-browser and x-terminal-emulator
On Fri, Mar 21, 2008 at 07:43:22PM +0100, Luca Capello wrote: > I'd suggest debianutils, since it provides at least sensible-browser, > but it misses sensible-terminal-emulator. I'd suggest the packages actually providing x-www-browser and x-terminal-emulator, since debianutils is not one of those. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#472209: .desktop files with icons for x-www-browser and x-terminal-emulator
On Tue, Mar 25, 2008 at 08:35:12PM +0100, Luca Capello wrote: > Do you mean that every package that installs an alternative for > x-www-browser or x-terminal-emulator should install a .desktop file? > Maybe we can have a new alternative x-www-browser.desktop and > x-terminal-emulator.desktop. That seems far more sensible than putting it into debianutils. Also, that way users wouldn't have a superfluous icon and .desktop file if they haven't installed any web browsers or terminal emulators, which is a situation you might create if you put them in, say, base-files. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: intend to hijack GnuPG
[moving to -devel to make Christian happy] On Sat, Apr 19, 2008 at 09:57:44AM +0200, Andreas Barth wrote: > And, BTW, most of us (including me) have a paid dayjob, and are of > course active on that one for the contracted time - for obvious reasons. > Telling that I would neglect Debian because I'm spending more time on my > dayjob than Debian wouldn't motivate me, and that's probably the same > for everyone else. I also have to say that last time I spoke with elmo > on IRC, he answered within minutes to me. I don't see how any of that is relevant. If I know I'm going to be too busy to do something, I'm not going to commit to doing it well. I'm not going to commit to doing it at all. If I have the time to do something I've committed to doing and I don't do it because I am "unmotivated", that is my issue. It is not Debian's responsibility to motivate me more than anyone else. Certainly the only motivation I should need is the knowledge that I committed to do something and have not rescinded that commitment. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mailing lsit code of conduct, again
On Sun, May 18, 2008 at 05:21:52PM +0200, Frans Pop wrote: > Clint Adams sent a request to d-www to have the CoC changed and I have > replied with a strong NACK to that suggestion. If the CoC should be You neglected to Cc me. > changed, it should be done after a proper discussion (on d-project > probably) and at least be done in coordination with the listmasters, not as > the result of an individual request by a random DD. Since the code of conduct was published without discussion and a consensus within the project, and since modified by "random" DDs (depending on whether or not you consider the members of webwml random) without discussion or consensus within the project, I consider this a somewhat deceitful stance to take. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mailing lsit code of conduct, again
On Sun, May 18, 2008 at 06:35:20PM +0200, Frans Pop wrote: > Wrong. You neglected to request to be CCed. My M-F-T was clearly a request to be Cc'd. > That's bullshit. The CoC has been in place and unchanged for years. Please Yes, and it has been controversial and WRONG for years. > check the origin in the relevant VCS before making such claims. Check the mailing list archives where I have stated that this is a bad idea. I have opposed this, as an active member of this project, for longer than that damn webpage has existed. There has never been consensus. There have only been people trying to tell other people to do things that make sense because other people are apparently too stubborn or inept to use their software properly. > It was also not committed by "random members of webwml", but by a Debian > Listmaster, i.e. by someone acting within his delegated authority. If you think that such inanity is in the purview of Listmaster then maybe we should "clarify" that instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mailing lsit code of conduct, again
On Sun, May 18, 2008 at 07:31:37PM +0200, Frans Pop wrote: > I agree it has been controversial. However, "wrong" is just your opinion. > My opinion is that it is "right" for Debian's lists. My preference for a default is to suggest that everyone always Cc unless otherwise requested. Note that I did not mail a patch that codifies this, because legislating something like that when there is clearly no consensus about the right thing to do would lead to all sorts of strife. Do you see where I'm going with this? What I proposed instead amounted to a single grammar change, and the removal of some controversial, sometimes-flouted, and, as Russ points out, unenforced bits of the CoC upon which the project never actually agreed. Such a change would introduce benefits: a certain group of people would no longer have the option of using that webpage as a "stick to beat people with"; the CoC would gain a smidge more legitimacy since a higher percentage of it would be less controversial; fewer people might be encouraged to omit Cc's in spite of my M-F-T. I am posting far too much in this thread. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Switching /bin/sh to dash (part two)
On Tue, Jul 21, 2009 at 06:14:27AM -0700, Russ Allbery wrote: > Except that every package in Debian that explicitly uses bash has no > declared dependency on bash because it's essential. I think attempting to > go through and add all those dependencies and test would be a huge waste > of time and resources. I think it's certainly worth it in the long run. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash (part two)
On Tue, Jul 21, 2009 at 04:18:07PM -0700, Steve Langasek wrote: > Why? Because: On Fri, Jul 24, 2009 at 09:38:01AM +0200, Steve Langasek wrote: > If the goal is to make *bash* removable, then I can understand why that > would be helpful to some people since it's the heavier shell by far. None > of what you're talking about in this subthread actually advances that goal, > however. The blocker for removing bash is that today, packages invoking > /bin/bash are not required by Policy to depend on it. And if they did, we > might find that there are Priority: required packages using it, which > there's no policy against, making the exercise more or less pointless. > > Oh yeah - libpam0g is one, and libpam0g is transitively essential. Those packages can be fixed if we want a nice, lean core system. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash (part two)
On Fri, Jul 24, 2009 at 03:43:47PM +0200, Steve Langasek wrote:
> Patches will be considered.
The second hunk isn't relevant to bash, but it seems a waste to
call ls and head for no reason.
--- debian/libpam0g.postinst.orig 2009-07-24 08:59:07.0 -0500
+++ debian/libpam0g.postinst2009-07-24 09:00:38.0 -0500
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
# postinst based heavily on the postinst of libssl0.9.8, courtesy of
# Christoph Martin.
@@ -73,7 +73,7 @@
for service in $check; do
if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
- idl=$(ls /etc/init.d/${service} 2> /dev/null | head -n 1)
+ idl="/etc/init.d/${service}"
if [ -n "$idl" ] && [ -x $idl ]; then
services="$service $services"
else
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
shells and posix compliance [was Re: Switching /bin/sh to dash without dash essential]
[not replying off-list because that seems counterproductive and arrogant] On Fri, Jul 24, 2009 at 03:49:15PM +, brian m. carlson wrote: > Actually, if it's invoked as /bin/sh, it is supposed to be > Bourne-compatible. That's my experience with the current version: Not much effort is put into strict POSIX compliance, though people certainly do complain about it[1]. > I don't know what other versions do. I'm working on finding bugs with > zsh as /bin/sh; see #510358. If anyone knows about a good /bin/sh > (POSIX, XSI, or Debian) testsuite, please let me know off-list. I'd certainly welcome improvements to the posh testsuite to that end. Run the harness with category 'debian' or 'posix' depending on which "standard" you're going for. [1] http://www.zsh.org/mla/workers/2009/msg00881.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Sun, Nov 01, 2009 at 07:29:23PM -0800, Russ Allbery wrote: > Also, note that the ftp team are at least project delegates, whereas the > Lintian maintainers are "just" package maintainers. If we have a > governance problem with the ftp team making this decision, it would be > even worse if the Lintian maintainers were making this decision. No, in fact the opposite is true. Any function that is correctable by any member of the developer body is inherently better than one that is under the control of a small group that has been given superpowers, legitimately or not, by virtue of the fact that it is correctable by any member of the developer body. Of course we will never come to accept that idea as a group, and people will foam at the mouth about the Constitution and the DPL, and other people will foam at the mouth about the same old power issues that come up over and over again cyclically with different faces, and one day I will learn to keep my mouth shut. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
On Wed, Nov 18, 2009 at 07:41:51AM +0100, Luk Claes wrote: > I don't think it's good to waste buildd time on failing to build packages. > I also don't think anyone is stopped from setting up a service that > allows source-only uploads as a go-between. Do you mean set up an unofficial upload queue that builds a source package, autosigns the .changes, and uploads it to Debian? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian as open project
On Thu, Dec 03, 2009 at 07:45:30PM +0100, Luk Claes wrote: > Unfortunately Debian does not seem to be able to also have real > constructive discussion about complex issues on the lists. So for these > issues we usually have real discussions on IRC, real life, phone or > private mail. The final result of these discussions is normally also on > the lists as proposals or announcements. The phenomenon you describe is harmful for the project because runs counter to what is good for Free Software. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ITA: dict-gcide
On Tue, Dec 15, 2009 at 05:24:48PM +0530, Ritesh Raj Sarraf wrote: > The copyright file lists that the copy of GCIDE is archived. I am not very > sure > who the current upstream is and if this database is still actively maintained. It is not. Upstream abandoned GCIDE on the grounds that WordNet is a free dictionary that is actively maintained, and so GCIDE was no longer necessary. I feel that WordNet is of poor quality and largely inadequate, so I disagree. > There have been many bugfixes to typos and definitions but I don't see a > debian/patches folder. Is Debian the only distribution packaging it now ? > Currently there are 19 open bug reports against this package. If I intend to > fix them, where do I submit the patches ? You don't. You will be effectively maintaining a fork. You might consider changing the name. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: update on binary upload restrictions
> Is it technically and/or socially possible to send build logs to > buildd.debian.org? Yes, the current security model does not prohibit that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On management
> I would think that the same things that attract a technical individual > could attract a non-technical individual. Desire to learn. Desire to > contribute. Desire to build skills for resume or future employment. > And so on. The thing is that the current NM process is heavily biased > toward technical people/programmers/developers/etc. That is probably a > discouragement to people who are more management oriented. I'm not sure what you're advocating, but in my experience, project managers without the capacity to understand the technical issues of the project that they are supposed to be managing are worse than useless. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Three-package clearance sale
Newly orphaned: conquest - a real-time, multi-player space warfare game xmaddressbook - X-based (Motif) address book zsh30 - zsh 3.0 xmaddressbook also needs someone to take over as upstream. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Error with fakeroot
> I created one package. When I try to perform the below > command, come this error: > > pc101:# fakeroot debian/rules binary > fakeroot: FAKEROOTKEY set to 818929733 > fakeroot: nested operation not yet supporte > > Any suggestion ? Are you trying to run fakeroot within fakeroot? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Error with fakeroot
> Hi, > > The command: > > pc01:package/fakeroot debian/rules > fakeroot: FAKEROOTKEY set to 818929733 > fakeroot: nested operation not yet supported > > Att, > > Faria Let's try this another way. Why is FAKEROOTKEY already set? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Error with fakeroot
> Not sure why on earth you would want to do this, but it seems to work > OK on etch. Maybe this is only supported with recent versions of > fakeroot? No, it's only appearing to work OK. You'll lose state between the different fakeroot invocations and that's why the error message is there until we have a proper solution implemented. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Error with fakeroot
> I doubt that. > You can easily run into this problem by using > make-kpkg --rootcmd fakeroot modules-image > and the nvidia module will fail with Does this happen every time? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intention to drop sparc32 support for Lenny
On Wed, May 23, 2007 at 12:07:01AM +0200, Turbo Fredriksson wrote: > If I knew anything about kernel interior and development, I'd be happy > to step up, but... Why don't you step up and learn then? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Wanted: introductory page for all teams
On Sun, May 27, 2007 at 12:11:03AM +0200, Frans Pop wrote: > However, I do feel my comment is justified in the sense that if there is > one thing in Debian that is the joint responsibility of _all_ DDs, then > it is the website. So yes, if you've never contributed in any way to the > website, feel some shame and kindly shut up. If it's the joint responsibility of _all_ DDs, then why doesn't everyone have commit access? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Wanted: introductory page for all teams
> The wiki is completely centered on English and therefore fails to serve a > significant portion of our users. Sure, parts of the wiki are translated, > but maintenance of that is an orders of magnitude worse problem than it > is for the website. > > As far as I'm concerned the wiki is not a valid alternative for the > website until the translation issue has been addressed. So make the www repo writable by group Debian just like debian-glibc CVS used to be. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Wanted: introductory page for all teams
On Sun, May 27, 2007 at 08:13:37AM +0200, Christian Perrier wrote: > How were things working in the debian-glibc CVS? Did accidents or hot > discussions hapen because of the very opened commit access? No more so than happens today with the more closed SVN repo. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Wanted: introductory page for all teams
On Tue, May 29, 2007 at 08:30:23PM +0200, Josip Rodin wrote: > It's not unfair to say that web editing is by and large much a easier thing > compared to coding the C library. Consequently, the number of people who > know how to do it, as well as the people who *think* they know how to do it, > is much larger. There's a much larger probability of problematic situations > in such a setting. I'm not sure I buy that argument. How would you rank debian-kernel work, which seems to be not infrequently rife with ego problems and revert wars? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Wanted: introductory page for all teams
On Wed, May 30, 2007 at 01:02:12AM +0200, Josip Rodin wrote: > Anyway, before we get lost in all this prediction stuff, I'm yet to hear > a good reason why we need complete triviality in the access method, as > opposed to the kind of triviality we have had for years now: all that is > necessary to get webwml access is to send a mail to debian-www saying > you've read some docs and you want access. I don't have a good reason, but for me it's the difference between contributing or not. If I already have access and I get an itch, I will scratch it. If I don't, I will either forget about it or complain. I am unlikely to go through whatever bureaucracy is set up to request access. Whether or not this is a loss for debian-www is not something I feel comfortable asserting. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#494043: ITP: ozymandns -- An experimental DNS server and miscellaneous DNS tools
On Thu, Aug 07, 2008 at 12:48:20AM +0200, Lucas Nussbaum wrote: > Confirmed. And it hasn't been fixed. That's why I run it in a while loop and find it to be reasonable functional that way. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Headsup: ncurses soname bump 5 to 6
On Wed, Sep 17, 2008 at 01:12:04PM +0200, Daniel Baumann wrote: > or in other words: soname 6 in debian will therefore be not compatible, > as it introduces both --enable-ext-mouse and --enable-ext-colors. also, > the wide builds will dissappear. What's the transition plan for those of us using wide builds? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Headsup: ncurses soname bump 5 to 6
On Wed, Sep 17, 2008 at 01:37:29PM +0100, Adeodato Simó wrote: > libncurses5-dev (and libncursesw5-dev as well if appropriate). With Can't do that because the pathnames are different. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What you can do for "Lenny"
On Mon, Oct 06, 2008 at 11:13:22PM +0200, Luk Claes wrote: > We do have experimental... It would be better to have a new place for that so we don't need to abuse experimental. Preferably one that moves everything to unstable post-release. Or call it unstable and resurrect 'frozen' for where the release team wants to restrict people. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight
On Wed, Oct 08, 2008 at 02:30:50PM -0500, Manoj Srivastava wrote: > So I think we need to modify the proposal, not the policy. We need to stop pretending that patent enforcement is one of our responsibilities or that we expose ourself to any kind of liability by distributing code that may or may not be patent-encumbered. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mpeg encoder patents, Was: Bug#501190: ITP: moonlight
On Wed, Oct 08, 2008 at 04:37:26PM -0500, Manoj Srivastava wrote: > So don't. Don't put any of the patent encumbered sources in main > either -- there is nothing that says patent infringement does not > happen as source code. > > That would meet the current policy as well. > > the patent encumbered software would then be treated much like > we do non-free. Might not have much of an OS left, after that, but > hey. We will have stopped pretending that patent enforcement is one of > our responsibilities or that we expose ourself to any kind of liability > by distributing code that may or may not be patent-encumbered. What? No. By identifying and trying to keep out patent-encumbered sources, we do exactly the opposite. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
