Re: [PROPOSAL] cron.* scripts should be quiet
Hi Joey Hess schrieb: > Julian Gilbey wrote: > > On Fri, Oct 06, 2000 at 10:43:09AM +0200, Arthur Korn wrote: > > > Probably it should be clearly stated in policy that the cron.* > > > scripts may be quiet if no errors are encountered. > > What do people think of this suggestion (s/may/MUST/)? > > I dislike it. It's possible some package will exist that is _designed_ > to fire off daily status reports by cron. We shouldn't prohibit such > things without reason. I suggested this to be a "should". > Cron jobs seem to be quieted down very nicely when they accidentially > become too verbose, just by user complaints and bug reports. A little paragraph in policy could make maintainers have a look at the logging behaviour of the software they package (it tend's to be ignored since it isn't showing on STDERR). ciao, 2ri -- Use the source...
Re: Frozen distribution?
On Fri, Feb 16, 2001 at 02:04:24PM +1100, Brian May wrote: > What is the benefit of this new frozen stage, instead of just freezing > the testing stage? That people who want to be almost bleeding edge will be held back for three months of freeze. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Frozen distribution?
Julian Gilbey wrote: > Santiago Vila wrote: > > There is no "current practice" yet, really. > > I propose two different ways to do the freeze: > > > > 1. Create frozen between testing and unstable, > >initially as a copy of testing. > > 2. Create frozen between testing and unstable, > >initially as a copy of unstable. > > Surely 2 defeats the whole purpose of testing? Not at all. The idea is that whatever you uploaded for unstable before day D of the freeze will be part of Debian 2.3 unless it *actually* has serious bugs, as we *wanted* to do before testing existed, but without the risks testing eliminates. I think testing is compatible with a freeze. If we do not have a proper freeze, developers could upload something which is bug-free to testing and it still may end up not being part of Debian 2.3 because there was no time to recompile it for other archs or there were complex dependency chains which were not satisfied at release time. This may create a lot of frustration among developers. Please note that this proposal means that testing and frozen will progressively become more and more similar as packages in frozen which are recompiled are being moved to testing. A freeze would also have benefits for autobuilders, since they could concentrate their efforts in the frozen packages only.
help on a request that lintian know about libtool's .la files
bug #71581 asks that lintian complain about packages that fail to ship .la files as policy 11.2 requires. I am not against this per se. However, how am I to know that a package should ship a .la file? When policy refers to libs needing libltdl does it mean they dynamically link it? So I could use objdump to discover this? It seems that discovering the use of libltdl should not be hard. But the other case of 'package used libtool and makes .la files which should appear in the -dev package' is a lot harder.
call for lintian help
I would greatly appreciate it if some of you would read the lintian bug list and supply comments, either in favor of the suggestions or against. Some of the open bugs need policy updates to fully fix in my opinion. Also, now is the time to submit your own lintian requests and bugs. I am preparing to finish the 1.20.x series and move it into maintenance mode as I contemplate a rewrite and reorganization of lintian. New features will not appear in the 1.20.x series for much longer. Please everyone, help lintian do its job so Debian developers have something they can trust.
Linux Professional Institute
On behalf of the Linux Professional Institute, I invite anyone interested to participate in our current survey of Linux professionals. We are in the process of developing our next level of tests for our certification process. We need the help of Linux professionals and system adminins to develop a strict standard for testing. Based on the feedback in the study, a polymetrician will develop the tests to be taken worldwide. Furthermore, we could use the experience and professionalism of many Debian developers to develop the next series which will deal with hacking the kernel and much more advanced techniques. Please explore the LPI web site, and see if there isn't someway your organization can help us out. We truly would like your participation in this endeavor. Also, we would like to spread the word to all your lists, that we are certifying individuals who have passed our first series of exams. The LPIC-1 is currently being issued after passing two exams costing a total of $200.00. The tests are available worldwide through VUE. We look forward to your participation. Visit the web site at www.lpi.org for more information on the survey and getting involved. We appreciate your assistance in this matter. Thank you. Ray Ferrari 650.322.3137 [EMAIL PROTECTED] P.S.: This is not spam mail. I have also written to Wichert and Joey Hess to help us with this. I have participated in Debian mailing lists, and also helped Debian at Linux World/San Jose a couple of times. smime.p7s Description: S/MIME Cryptographic Signature
suggestion
This suggestion could probably be sent to a number of different departments of Debian, but it is most likely a general policy decision on how to support your product. I am recommending to several distribution packagers that the newsgroup comp.os.linux.* could benefit from a comp.os.linux.distributions.*, among which comp.os.linux.distributions.debian would be one. This would allow reduction of support costs at the individual packagers while allowing some of the users to better aid in helping each other with problems that are specific to individual distributions. D. Stimits, [EMAIL PROTECTED]
Re: suggestion
D, while I don't want to reject the idea out of hand (noting that my only affiliation with Debian is enjoying it on my own computers, and spending far too much time helping people on the mail lists) I don't see any reason for changing our current system. Perhaps if you would point out the faults of the current system, and why you think usenet will solve those faults, your suggestion may be taken more seriously. The positive points to our current system is that all information is currently located at one point: http://lists.debian.org. One can use the archives for historical research, seeing what problems have been solved recently and how, and participate in active communities. Changing to usenet would decentralize sources of information; a user would no longer know ``lists.debian.org has the answer'' -- instead, users would be reduced to trying the various usenet archives, which, despite trying, are never quite complete nor intuitive to use. Often attachments are stripped on such services. This is setting aside two of the worst problems of usenet -- not all users have easy access to usenet news, while email is ubiquitous. #2 is the horrors of spam. When on a debian-controlled server the email lists can be kept free of spam. On usenet, only moderated groups are free of spam, and being a moderator for the amount of traffic debian does in a day would quite simply be hell for the moderator. I just don't see how using a newsgroup could possibly be better than reading debian-user@lists.debian.org for typical user support. Debian is not like most distributions. It is a very close-knit group and while it may make it difficult to attract new users (I went four years running Linux before trying Debian) once a user is `converted' to the Debian way-of-doing-things, few want to go back. In my humble opinion the lists are the glue that cements the distribution into one cohesive body. * D. Stimits <[EMAIL PROTECTED]> [010216 17:04]: > This suggestion could probably be sent to a number of different > departments of Debian, but it is most likely a general policy decision > on how to support your product. I am recommending to several > distribution packagers that the newsgroup comp.os.linux.* could benefit > from a comp.os.linux.distributions.*, among which > comp.os.linux.distributions.debian would be one. This would allow > reduction of support costs at the individual packagers while allowing > some of the users to better aid in helping each other with problems that > are specific to individual distributions. -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
Re: Frozen distribution?
> "Julian" == Julian Gilbey <[EMAIL PROTECTED]> writes: Julian> On Fri, Feb 16, 2001 at 02:04:24PM +1100, Brian May wrote: >> What is the benefit of this new frozen stage, instead of just >> freezing the testing stage? Julian> That people who want to be almost bleeding edge will be Julian> held back for three months of freeze. Why? You can just use unstable like you currently do. There is no reason why unstable should change just for the freeze. -- Brian May <[EMAIL PROTECTED]>
Re: Frozen distribution?
On Sat, Feb 17, 2001 at 01:46:46PM +1100, Brian May wrote:
> > "Julian" == Julian Gilbey <[EMAIL PROTECTED]> writes:
> Julian> On Fri, Feb 16, 2001 at 02:04:24PM +1100, Brian May wrote:
> >> What is the benefit of this new frozen stage, instead of just
> >> freezing the testing stage?
> Julian> That people who want to be almost bleeding edge will be
> Julian> held back for three months of freeze.
> Why?
> You can just use unstable like you currently do.
> There is no reason why unstable should change just for the freeze.
Actually there are two reasons why unstable should change just for the
freeze. They're complementary.
If you don't fork frozen (ie, maintain unstable and frozen independently),
then if you upload major changes to unstable, you've stopped yourself
from being able to upload minor bugfix updates to frozen (since they're
not forked, you'd have to upload it to unstable, which has already been
majorly changed).
OTOH, if you do fork frozen, then you cause problems on "other"
architectures. Uploads that are sent to both places ("frozen unstable"
uploads), tend to get autobuilt twice (once for frozen, once for unstable,
which no longer works with katie), or misautobuilt (built with unstable
libs on the unstable autobuilder and uploaded to frozen as well), or not
built at all on one or the other. Uploads that are (mistakenly?) sent
to just one or the other (we've had both) either break in the current
release we're trying to get out, or end up broken in the next release when
we find the .deb is outdated or not at all present in unstable anymore.
The easiest solution that I can think of (ie, that doesn't cause difficult
to detect breakage, and that doesn't involve further significant changes
or too much awkwardness) is, during the freeze, to just upload major
changes to experimental, and bugfix updates to unstable.
Thanks to the changes James has already made, uploading to experimental
should be pretty easy (no waits for NEW processing unless the package
really is new), and experimental tends not to be autobuilt so shouldn't
cause problems there.
Once the freeze is over and the release is made, it'd be fairly easy to
move packages from experimental to unstable on request, if nothing else.
I'd like to avoid manually processing uploads where possible though (which
is what traditional freezes involve), and ideally use a minimum number of
suites (stable, testing, unstable, experimental). But if people have other
suggestions, or, even better, clever tweaks to the above, that'd be cool.
This may or may not be appropriate to this list at this point, feel free
to move it to... -devel, I guess?
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]>
Re: Frozen distribution?
* Anthony Towns [010216 19:43]: > The easiest solution that I can think of (ie, that doesn't cause difficult > to detect breakage, and that doesn't involve further significant changes > or too much awkwardness) is, during the freeze, to just upload major > changes to experimental, and bugfix updates to unstable. Someone recently (in the last month or two?) asked ``why not use dpkg to handle the distributions?'' though I am sure it was more eloquent. And, given AJ's response in this thread, I am beginning to think that fellow had the right idea, now that we have package pools in place. [Remembering, of course, that although I am not 'in' Debian, I still think of it as a 'we' situation. Call me nuts.] Given that we now have packages located on our servers with names such as: /pub/debian/main/packagepool/a/alphapackage-3.4-5-i386.deb These names will allow us to keep several different versions of each package in the package pools. This is important. We generate several meta-packages -- lets call them debian-release-slink, debian-release-potato, debian-release-woody, debian-release-sarge, etc, as well as debian-frozen and debian-unstable. The debian-release-* meta-package will Depend or Suggest or Recommend the packages that were ``known-good'' at the time of release. debian-unstable would Depend/Suggest/Recommend on the bleeding edge packages. debian-frozen would D/S/R on the packages intended to go into the next debian-release-* package. Changing the dependencies for the various metapackages would 'upgrade' a package -- unstable's dependencies could jump large versions, while incremental bug fixes intended for debian-release-* (security patches), debian-frozen would just cause the dependies to increment small versions. This way, unstable can remain that way, and the other two have some semblence of stability. Of course, apt would need a switch (heck, it probably already has one, it does so much already :) that would allow it to upgrade/change packages only if the version number in the D/S/R of the appropriate meta-package is updated (rather than follow the information it knows about newer versions packages). Also, it would need to be modified to not require that all packages listed in the D/S/R line be installed, but if any versions of installed packages are updated, update those. I don't think these changes would be difficult. (Ah, the joys of not being the guy in charge of whatever it is I suggest be changed..) An alternate strategy is to include in each package description (in the _Packages lists) a header claiming the distribution it is intended for. Listing three versions of a package in the one file, each one tagged with Flavor: stable or Flavor: unstable or Flavor: frozen, with an apt variable to choose which of the three to install. (Global variable is probably the best idea.) This alternate strategy would also allow major version number increases in unstable, and minor version number increases in frozen and stable. The downside of course is that this list would be huge, and each user would be required to download the whole mess daily (if the user is like all the users I know :) -- some sort of diff or delta version would be splendid. Though to tell the truth, I don't know why the old system (`old' meaning `about six months ago') couldn't handle this. Completely unrelated: I think some people could go for a ``stable-unstable'' version of Debian. If the _Packages lists would include the date the package was installed (epoch time would be easiest though not very human-readable) into the archives, then apt could be configured to install only packages that have been in unstable for X days, where X is probably about 7. This way, only packages that haven't been removed in X days due to some strange error are installed. (Strange error being ``mutt linked against non-existant library'' that plagued Marco the other day; Marco quickly replaced mutt, and users running the stable-unstable version would never have noticed.) Is it possible to roll both ideas into one elegant solution that doesn't cause the apt team to want me dead? :) -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
