Re: Zeroconf Debian?
On Friday 08 August 2003 00:54, Andrew Suffield wrote: > On Fri, Aug 08, 2003 at 01:28:15PM +1000, Andrew Pollock wrote: > > I'm currently at the SAGE-AU annual conference, and Apple presented a > > paper about their Rendezvous technology, which is their implementation of > > Zeroconf[1]. > > My experience of Rendezvous has been that it is a network-thrashing > traffic generator, which *has* to be disabled on a network of any > significant size, just to stop it from flooding everything else out. > > Please be careful never to ship packages in a state which do this by > default; I can't count the number of hours I've wasted just turning > that stuff off. There's got to be a better solution. It's not MEANT for a network of any size. It is intended for home and very small office users who do not have admins or who do not want to admin. If you have an admin who has properly setup DNS, DHCP, etc zeroconf has little practical use.
Re: package name change (moviemate -> mediamate)
On Wednesday 30 July 2003 15:56, Jamin W. Collins wrote: > > In building the new Media Mate package, I've declared a Conflicts with > the moviemate package to effect moviemate's uninstall when the mediamate > package is installed. However, this leaves the question of migrating > the moviemate's configuration to mediamate. For this, I pull the > debconf answers for moviemate's questions and set them as the answers to > mediamate's questions (which are mostly the same), and set the _seen_ > flag to true so the questions will not be asked (much like an upgrade > where the package name has not changed). > you should Conflict, Replace, and provide MovieMate. This will ensure a smooth transition. You instead (may) want to upload a package called moviemate which is a dummy package that depends on MediaMate. Remember, if the user has MovieMate installed they will not get MediaMate without actually asking for it. > Since the package name has changed, the configuration and data files are > now stored in different locations. So, I plan on moving the data files > to their new location. But, what about the old configuration files, and > the old package's state in dpkg? Should these be removed since the new > package is installed (more or less an upgrade) or should these be left > because the old package hasn't been purged and the new one has a > different name? Also, moviemate has asks a question during install > about removing the DB on purge, with the answer stored in debconf's db. > During the upgrade would it be acceptable to clear this answer under > moviemate once it's been migrated to mediamate since the old DB is > upgraded and used by mediamate and a purge of moviemate would then > remove a database that's still in use? Or, should mediamate copy the > old database and and leave it for moviemate to potentially purge? > how much work is involved in hiding this from the user? In general you should try to just make things work. The packaging details are something our users should not need to know about. Remember from their perspective nothing changed. if you can scarf in the old db and make the upgrade just work, that is the preferred approach. Of course that may prove to be too complicated or you may just not have enough time.
Re: default MTA for sarge
On Sunday 13 July 2003 02:24, Sean 'Shaleh' Perry wrote: > > I would lean towards exim4 configured for local delivery only. It is a > sane default for just about every system. The admins who know they want > another MTA can easily replace exim and the users who have no clue what a > MTA does have one installed quietly and securely waiting for the day they > might want more from it. > > Enough of a Linux system assumes that a MTA is present that not installing > any would be wrong. Asking an user which MTA they want is equally wrong > because many users have no clue what one is. I have one more comment about this. In another post I mentioned that the only reason I have a local mail daemon setup on some machines is to allow reportbug to work. It occurs to me that perhaps (*PERHAPS*) during the install we could query: "Hi, are you connected to an ISP that you use for all of your email sending/receiving needs? Or perhaps this is a workstation setup inside a corporate setting? If so in the blanks below please provided the name of the SMTP server as well as the IMAP4 or POP3 server you use." These settings are provided by their ISP or IT staff and asking for them should not be completely confusing. Especially with a bit of sugar text. We could store this value and then *ANY* app that needed the setting could just look it up. Perhaps asking about proxys as well. A few questions like this would go a LONG way to making the initial install much easier for those interested in a functioning desktop. In particular laptop users are a very interesting subset of users who do not want much of a traditional Linux / Unix setup. I suppose this is a side rant/suggestion for "let's have some generic meta configuration questions rather than only tying them to specific packages". Perhaps not a sarge solution but something to consider. Discussions on this probably need to fork off to a new thread but starting here made sense.
Re: default MTA for sarge
On Sunday 13 July 2003 06:26, Sebastian Kapfer wrote: > > I know, but that location (/var/mail/root) is discouraged, isn't it? The > admin shouldn't read his/her mail under uid 0. That's why I think that > exim should ask this question when it is configured for local delivery (or > in "newbie" mode ;-) > > The best solution (at least for the average user which doesn't care about > his MTA) would IMHO be a question along the lines of "Which user account > should receive messages for the system administrator?" I.e. not even > mentioning the technical details. The word "mail" might be misleading > here. > > Just thinking aloud... I have not installed any exim4 yet, and I know how > to get exim3 to do local delivery. But Debian should become a more > user-friendly OS after all, right? > The issue here is what Steve Greenland mentioned directly and I alluded to when I started this thread -- many, many desktop users will use external (ISP, work) provided SMTP and POP/IMAP. So that email goes no where useful. Their MTA won't read the local queue. I am a pretty savvy fellow and I don't even use the local MTA except to send mail via reportbug.
Re: default MTA for sarge
On Sunday 13 July 2003 01:31, Joey Hess wrote: > For sarge we have two options for the default MTA in base: > > a. replace exim with exim4 > b. no MTA installed by default, add a MTA task > > So do we want there to be a MTA by default? I would lean towards exim4 configured for local delivery only. It is a sane default for just about every system. The admins who know they want another MTA can easily replace exim and the users who have no clue what a MTA does have one installed quietly and securely waiting for the day they might want more from it. Enough of a Linux system assumes that a MTA is present that not installing any would be wrong. Asking an user which MTA they want is equally wrong because many users have no clue what one is.
Re: console mode(probally off)
On Monday 02 June 2003 17:47, Adam Borowski wrote:
> On Mon, 2 Jun 2003, Sean 'Shaleh' Perry wrote:
> > On Monday 02 June 2003 04:09, Luiz Rafael Culik Guimaraes wrote:
> > > How to start debian direct on console mode,
> >
> > Eh? I thought Debian always started in console mode unless you both
> > installed xdm (or the gnome/kde equivalent) and enabled it.
>
> Unfortunately, all of these three ({x,g,k}dm) automatically start X when
> the system starts if they are installed, and AFAIK neither of them
> provides a way to disable them other than uninstalling them or editing
> /etc/{rc*.d,init.d}/whatever by hand.
>
hmmm, yes. There are ways to disable them but they are not immediately
obvious to the Debian newbie.
> The things are even worse: a vast majority of novice users use tasksel
> when installing Debian, and the two most often selected tasks ("X window
> system" and "desktop environment") include xdm variants. Thus, questions
> like "How to start debian direct on console mode" have a lot of merit.
> It might be just me, but my eyes hurt more after a few hours of doing
> things in graphics mode than after a 48h straight programming run on a
> text console.
>
your eyestrain may indicate a poorly configured X setup (too low of a refresh
rate) or a need for more contrast in your desktop setup.
Re: console mode(probally off)
On Monday 02 June 2003 04:09, Luiz Rafael Culik Guimaraes wrote: > Dear Friends > > How to start debian direct on console mode, > > Regards > Luiz Eh? I thought Debian always started in console mode unless you both installed xdm (or the gnome/kde equivalent) and enabled it.
Re: Celebrating Debian's 10th birthday?
On Sunday 01 June 2003 18:24, Alexander Neumann wrote: > Hi, > > While digging around in the calendar-files at infodrom.org I suddenly > realized that Debian will have it's 10th birthday at August, 16th > (according to the calendar.infodrom.debian file at > http://www.infodrom.org/projects/calendar/) > > Are there any parties planned already? ;) > > - Alexander That's a week after LinuxWorld in San Francisco so we may celibrate it early (-:
Re: What makes a debconf?
> > Do we need some method of deciding what constitutes 'the' Debconf? Or maybe we need to be more freeform. There is no inherent "betterness" of say the Oslo conference over one held near Washington, DC. Maybe there are 4 of them one year and only one the next. Maybe we start holding one every year in Little Rock, Arkansas and Paris, France. "Debconf" is about Debian developers trying to meet other devels and users. Its about trying to make us a stronger organization. Its about hacking and all of the other reasons we love Debian. Treating it like a Comdex, a Linux World or anything else just seems wrong. Developers should feel encouraged to declare a conference whenever and whereever they can make one. If one of us can organize a meet and people will show up that makes a conference. (hmm, reading this before I hit send the above may sound confrontational. Joe this is not my intent. Just expressing how I feel about the whole debconf idea).
Re: Very uneven distribution of packages per maintainer
> > Not necessarily -- some packages are a lot of work, like xfree, glibc, > apache, some are a decent amount of work, like mailman, cvs and some > are close to zero work, like chrpath and xslide. People also have > different amounts of time available -- those who are paid to do Debian > maintainence at work will have more time than somebody who works 12 > hours/day without any Debian work in there, etc. > > So, why do you think having a more even distribution is a good thing? > Or rather, why is the current situation so bad? > indeed. Some packages are "worth" 10 "normal" packages in the amount of work they require. Also, perhaps the script could deal with items like qa owning orphaned packages and the like.
Re: Bug#148421: kopete =?utf-8?q?0=2E6=2E1a
On Tuesday 29 April 2003 09:59, Michael Meskes wrote: > Package: wnpp > Version: unavailable; reported 2003-04-29 > Followup-For: Bug #148421 > > Since this ITP is almost a year old and there is a package available > under http://kopete.creativa.cl/debian/sid/ and the packages applies for > NM and I am willing to sponsor him, I hope no one opposes us to go ahead > and upload kopete 0.6.1a or a newer version (if available once we > finished the package). > > There are some packaging thing left to be done, but the binary provided > at this URL already works. Just enter > > deb http://kopete.creativa.cl/debian/sid/ ./ > > to sources.list to test. > I have also talked to the person behind these packages. I had promised to sponsor an upload and was waiting on the new KDE. However my time has now become quite limited. He is responsive and capable judging from my dealings.
Re: Bug#188665: RC issue
> I understand that this requires all packages using lex to > massage their lexers to conform to the new behaviour of flex; but the > gains in reduced complexity of the scanner and reentrancy and > standards compliance are well worth it. > and like the gcc 3.2 change over, the upstreams will eventually have to make this change as well so Debian can help out and make this task easier for them. However, are these new lexer files backwards compatible? I would have a hard time getting an upstream to accept a patch that would prevent their source from building anyhere but the new flex.
Re: What should go into "How Software Producers can distribute their products directly in .deb format"?
On Sunday 08 December 2002 20:00, Bernd Eckenfels wrote: > On Sun, Dec 08, 2002 at 07:03:05PM -0800, Sean 'Shaleh' Perry wrote: > > Which is why I ask for the second option -- a tarball. Let Debian, > > Gentoo, BSD, whoever do their own packaging. This includes any of those > > groups' users. > > Debian wont package most of the non free software. > But it gives us the option. It also makes it easier to write installer packages like the real networks one without mucking with rpms.
Re: What should go into "How Software Producers can distribute their products directly in .deb format"?
On Sunday 08 December 2002 18:12, Bernd Eckenfels wrote: > On Sun, Dec 08, 2002 at 06:06:41PM -0800, Sean 'Shaleh' Perry wrote: > > In the end it makes very little sense for a3rd party to provide debs. > > It makes sense for the debian user, dont u think? > Which is why I ask for the second option -- a tarball. Let Debian, Gentoo, BSD, whoever do their own packaging. This includes any of those groups' users.
Re: What should go into "How Software Producers can distribute their products directly in .deb format"?
On Sunday 08 December 2002 13:29, Aaron Isotton wrote: > Hi, > > (sorry for the overlong subject). > > I originally sent this to debian-doc but I got no answers, so I > thought I'd post it here too. > > I'm interested in writing the "How Software Producers can distribute > their products directly in .deb format" manual, as listed on > http://www.debian.org/doc/devel-manuals. I thought to write the > following, more or less: > In the end it makes very little sense for a3rd party to provide debs. The LSB requires rpm support only. Personally I would be happy if they released a rpm for compliance and a tarball (binary or source as they wish) for everyone else.
Re: Locales problems...
On Thursday 28 November 2002 16:02, Bruno Diniz de Paula wrote: > > Another question: is this question proper to this list, or I should have > tried debian-user? Sorry if it is unproper... (in fact, I also sent to > that list) > debian-user is the support list while debian-devel is for the day to day discussions pertaining to creating Debian. Basically if you are asking for help ask on -user if you are offering a patch or want to have a technical discussion about proper solutions it should happen here on -devel. For the most part the people working on Debian do not read -user although some of us try.
Re: Pick a name, any name...
On Wednesday 27 November 2002 02:03, Roland Mas wrote: > Current candidates include: > hey how about something much less cryptic like "forge". Nothing worse than having to guess what woman's name some silly coder named the program I am looking for. And since most of us aren't French the names mean very little. But that is much less important.
Fwd: Love it when a good plan works out!
Great warm and fuzzy mail with an interesting P.S. -- Forwarded Message -- Subject: Love it when a good plan works out! Date: Sun, 1 Sep 2002 16:03:14 -0700 From: Johnny Quazar <[EMAIL PROTECTED]> To: debian-user@lists.debian.org Just completed my first crack at the new Woody 3.0r0 release, and wanted to write and kudos to the team! Wow, smooth as silk, the >only< glitch I experienced was an overloaded security.debian.org server -- and you guys even anticipated that event! I used retry a couple times and blamo -- pain-free Linux install! I've got a few of these under my belt and have never seen it go smoother -- GOOD JOB PEOPLE! Huge Warm Fuzzies!! Thanks again, Rob Leachman [EMAIL PROTECTED] PS: Well I wanted to write one of those really rare messages but cannot click send without finding something to suggest... nowhere in the (i386) install manual does it clearly state: 1. Download compact-rescue and compact-root 2. Make floppies 3. Boot the rescue disk 4. Do the most obvious thing 5. Bask in the glow I had to "go for it" with less certainty than would have been provided with at least step 1 explicitly stated (under the "installing over network" section?). Shrug, whatever. Substitute this suggestion with "how the heck did I get nethack, in a minimal install" if the above doesn't seem important, ha ha. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] ---
Re: graphical installer?
On Friday 30 August 2002 08:57, Josselin Mouette wrote: > Le ven 30/08/2002 à 17:37, Sean 'Shaleh' Perry a écrit : > > On Friday 30 August 2002 08:29, Mateusz Papiernik wrote: > > > > Have a look at PGI: http://hackers.progeny.com/pgi/ > > > > > > It's very nice! I like GTK wizard look very much - so why > > > it isn't integrated with unofficial Sid images? Have You got > > > any other plans ? Or maybe you want to use text installer > > > for ever? > > > > It is currently ia32 (x86) only. There is also some integration work. > > By the next release there will likely be several options available. > > And correct me if I wrong, but it doesn't support internationalization. I believe that is the case or at least was (it may hve been updated recently).
Re: Should we customize apps for a common "debian-look"?
On Friday 30 August 2002 08:29, Vince Mulhollon wrote: > > The problem is, I experiment with and chose window managers by going to the > website and look at the pretty screenshots. > If I like the screenshot, then it's a quick apt-get install somethingwm. I > expect to get what I saw on upstream's screenshots. > If I like the look of ratpoison, and someone themes it to look like W95, > I'm not going to like it when I'm "surprised" with Debian's themed version. > More often than not the screen shots you see are not what the wm looks like by default either.
Re: graphical installer?
On Friday 30 August 2002 08:29, Mateusz Papiernik wrote: > > Have a look at PGI: http://hackers.progeny.com/pgi/ > > It's very nice! I like GTK wizard look very much - so why > it isn't integrated with unofficial Sid images? Have You got > any other plans ? Or maybe you want to use text installer > for ever? It is currently ia32 (x86) only. There is also some integration work. By the next release there will likely be several options available.
Re: Should we customize apps for a common "debian-look"?
On Friday 30 August 2002 08:05, Erich Schubert wrote: > > Provided we *ONLY* muck with things like colors, icons, and root images > > this should be fine. Actually changing code like RH did to remove the > > About box would not be good. > > I never look at about boxes anyway, so why remove them? ;) > This has nothing to do with common look, and all Interface Guidelines > include an about box in the Help menu. > > I didn't follow the discussion why KDE is angry about RedHat, if it was > for the removal of about boxes i think KDE is right to be angry... > There was an "About KDE" box which was removed/hidden/had its text changed, I did not follow closely.
Re: Should we customize apps for a common "debian-look"?
On Friday 30 August 2002 09:03, Yenar Calentaure wrote: > > Please, please, please, do not change the default without asking user > first. Debian users tend to know what they want. > And the clueful user almost never uses the default anyways. But even if they do want to we just provide an option in the theme chooser "Default KDE Look" or somesuch.
Re: Should we customize apps for a common "debian-look"?
On Friday 30 August 2030 06:50, Jérôme Marant wrote: > On Fri, Aug 30, 2002 at 03:43:32PM +0200, Erich Schubert wrote: > > I don't have a real opinion, but i do thing that looks begin to matter > > for linux apps and desktops... > > I agree with you. I think that the default Distribution theme really > matters; RH and MDK have very nice default desktop themes but Debian > doesn't have any. I know that they hired graphic artists. > AFAIK, we don't have any. I'm sure we could find volonteers. > > My 2 cents. > > Cheers, I also agree. There was a moment of "bah we are not a company" but in the end, I think a little help in giving our users a good looking default would go a long way. Of course not being a KDE or GNOME user I would also like to see this extended to the simple window managers as well. Provided we *ONLY* muck with things like colors, icons, and root images this should be fine. Actually changing code like RH did to remove the About box would not be good.
Re: "Bug of the month", or how to get people fixing bugs
On Thursday 29 August 2002 19:45, Andrew Suffield wrote: > [Obey M-F-T or die] > > Here's the basic idea: turn bug-fixing into a game (a counterbalance > to the huge quantities of time which moon-buggy and frozen-bubble have > taken away from Debian development). > > People register to play, and each month, all the players are given > three randomly selected bugs to tackle. Points are awarded to those > whose assigned bugs get fixed during that month, with the idea being > that people would endeavour to ensure their bugs get fixed swiftly, by > whatever means they can (closing spurious bug reports, sending patches > to the BTS, making NMUs, harassing the maintainer, or whatever). > Interesting concept. Does the player score if they post a patch or if the maintainer actually accepts it? Also once you have this more fully fleshed out perhaps announcing this on some place like DebianPlanet would be a good idea. We have plenty of users who have time to fix a bug or two but not become full time devels. Or is this meant as a Debian devels only game?
Re: Is this still valid?
On Thursday 29 August 2002 05:08, Ola Lundqvist wrote: > Hi > > I just wonder if this lintian error is still applicable? > > > Or should I simply ignore it. > > I think that it is due to the /usr/doc /usr/share/doc thing but I'm > not sure. > I never saw this get pushed into policy, joeyh just decided to stop doing it in debhelper.
Re: Is lintian stalled? [Re: Is this still valid?]
On Thursday 29 August 2002 05:14, Jérôme Marant wrote: > On Thu, Aug 29, 2002 at 02:14:12PM +0200, Josip Rodin wrote: > > > Or should I simply ignore it. > > > > You should, for the time being, until Lintian is fixed. > > It seems that Lintian hasn't been updated for a long time now. > However, Sean seems to be responsive in the BTS. > > Sean, are there any plans to update Lintian? > > Thanks. Yes, I am trying to finish up a project so I can devote a good deal of time to lintian. I know it needs it. I hope to be working on lintian by the end of next week. I should have breathing room then.
Re: Dock Apps packaging, round 2
On Friday 23 August 2002 03:05 pm, Josselin Mouette wrote: > Second, there is the famous... TADA ! Packages file size ! > While this shouldn't be a limit for what we package, we can't increase > its size indefinitely. This one of the reasons why the gnome applets > were put in a single package. I think the dockapps problem is a good > example to think about what to do with the Packages file : we can "save" > tens of packages by using bundles, or increase their number by a score. > So we have to decide now what to do : either we begin to save some > packages to avoid a too big Packages file, or we find NOW another way of > downloading the debs list. If we keep the things the way they are going, > APT will probably be unusable in sarge+1. > The problem is most packages in Debian will not benefit from this style of packaging. So you take 10,040 packages and have 10,000 packages. No real win. If we start heading down this road we might as well kill all of the -doc packages and stop splitting libraries into libfoo and libfoo-dev. We could also remove all of the perl modules since CPAN also has them. Or remove all of the Java packages since we still don't have a free Java implementation. Then we could just choose KDE or GNOME and remove the other one along with things like ROX. And so on. But that is not the Debian I joined and I doubt that is really what you want either. I agree there is a problem with how we currently deal with our packages and the archive. But it is a techical problem requiring a technical solution. Making a few bundle packages is just like putting a bandage on a gaping wound.
Re: Dock Apps packaging, round 2
On Friday 23 August 2002 01:12 pm, Bas Zoetekouw wrote: > Hi Sean! > > You wrote: > > Asking maintainers to give up their packages so you can bundle them > > just seems wrong. Why not just make your bundles be meta packages? > > Because people keep complaining about ITP's of packages they consider > crap and that are bloating the Packages files, according to those > people. And as I told Josselin when he started this -- so what. Let the old school group complain all they want. I have always enjoyed that Debian's developers are also its users and largely we are user driven. If I want to package something I will, even if it is small and simple. We have a beautiful packaging system which supports tasks and meta packages and we should use it.
Re: Dock Apps packaging, round 2
On Friday 23 August 2002 11:03 am, Josselin Mouette wrote: > After the little discussion 2 weeks ago about the packaging of dock > apps, I come with a proposal. > > Granularity is good. Until now, all dock apps have been packaged > separately to achieve best granularity. However, this is growing to an > impressive number of packages, which both bloats the archive and lacks > of convenience for users. Furthermore, toy/funny dockapps are often not > packaged, as they are often very simple and qualified as "useless crap" > on this list. > To solve this, an approach similar to that of the gnome-applets package > is proposed, except that, due to the number of dockapps that can be > included, there would be several packages. To put in these bundles, I > have selected a number of dockapps, with these conditions : > 1) Being "popular" : I considered dock apps that are already in the > archive, dock apps that were the most downloaded on > http://dockapps.org/, and also dockapps that I would like to package ;) > Of course, the selection is very subjective, and this is the right place > to flame me if you think some choices are inappropriate, or if you would > like to see other dockapps in these bundles. > 2) Having no dependencies, other than xlibs and libdockapp. Note that, > as many dockapps not using libdockapp share a file named wmgeneral.c, I > will try to make a library with it (I say "try", because many dockapps > use different versions of this file, with sometimes some incompatible > changes). Modifying upstream sources is quite wrong. Now if you would like to tie this in with #3 and become the upstream for many of these and clean them all up, great. > 3) Not being actively maintained upstream. This is the case of most of > dockapps, as they represent a small amount of code and are based on > stable APIs. > Asking maintainers to give up their packages so you can bundle them just seems wrong. Why not just make your bundles be meta packages? I would much rather see a package maintained by someone who actually uses it and is thus capable of dealing with bug reports. That's what Debian has always been about -- the developers using what they package. I used to maintain wmixer and recently gave it over to another devel who is actively working on it. Asking him to give up his work just because you want to make neat, pretty packages is plain silly.
Re: Possible mass filing of bugs, take #2.1
On 20-Aug-2002 Josip Rodin wrote: > On Tue, Aug 20, 2002 at 10:23:29AM -0700, Sean 'Shaleh' Perry wrote: >> >> Rather than mass filing bugs, can you write a lintian check for it >> >> instead? >> > >> > He filed a bug about Upstream Author(s), I fixed it, and then shaleh and >> > others reverted it >:) >> >> I think we have better things to be nitpicky about. Besides, lintian >> tries to only enforce policy. > > Yeah, well, speaking of better things, when can we expect you to integrate > my lab code patches? I've initially sent them back in August 2001. > I just mailed AJ about that. If all goes well I have the month of September for lintian hacking.
Re: Possible mass filing of bugs, take #2.1
On 20-Aug-2002 Josip Rodin wrote: > On Wed, Aug 21, 2002 at 02:14:16AM +1000, Anthony Towns wrote: >> Rather than mass filing bugs, can you write a lintian check for it >> instead? > > He filed a bug about Upstream Author(s), I fixed it, and then shaleh and > others reverted it >:) > I think we have better things to be nitpicky about. Besides, lintian tries to only enforce policy.
Re: GCC 3.2 transition
> > If temporary breakage of some applications is acceptable, you can > spread this over a couple of days, by tsorting the 1000 packages. > or do a staging in experimental or somewhere else. Upload everything there, let people look at it for a day or two then move it over. This staging could also take away the need to finish in one day. All C++ package maintainers could upload to the staging area. Anyone who has not uploaded in a certain time (a week or less sounds right) will hae an NMU done for them.
Re: GCC 3.2 transition
> > If upstream aren't inclined to change their Linux soname for the new gcc, > though, not changing our soname but doing the upgrade anyway seems the > best option. > even if some are willing not all will be. Then we have to worry about dead upstreams too. It seems like changing the sonames to solve this simply won't work. I had forgotten we solved the libc5 issue by moving the libs to a new directory and making ld.so look there. Been a while (-:
RE: GCC 3.2 transition
> * Add a Conflict with the non-`c' version of the package. why can't we have both installed, just like the libfoo6 and libfoo6g situation??
because it isn't said enough
I recently ran into this on my current project (blackbox window manager). Too often as developers the people we talk to are the ones seeking help and guidance. Whether it is a bug, ignorance, stupidity, that crazy genius only they will ever understand, whatever we deal with them, coddle them. But in the end they are usually the only people we deal with regularly. It is a lot like working tech support -- when someone wants to talk to us it is usally not a mutual feeling (-: So, I would just like to remind people to occasionally send a "thank you" to those out there who make your day go by. It really goes a long way to helping us devel types deal with life. In the past I had money and would buy one or two gifts a year for people who really helped me out or did good things. Most of us have experienced "man what a horrible day/week/whatever" a few times in our lives. Think back to one of those days when someone gave you a beer, some chocolate, a hug. Give this to someone who has made your day go easier. Whether it be the awesome new X installer, debhelper making your package creation so painless, make-kpkg being the coolest damn thing on earth, whatever. Say thanks. We all appreciate it. If you need a silly reason to scrounge up $10 or $20 bucks, just remind yourself how much you saved by not purchasing the 400megs of software on your hard drive (-: But as I said, just mailing out a big "thank you, your work is used every day and I love it" is worth more than anything. I now return you to the flame war, may his chosen deity have mercy on his soul. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#141847: O: dupload -- Utility to upload Debian packages.
> > [1] Unless someone actually tries to embed arbitrary pthon in it. dput's config is not python code. It is parsed by ConfigParser which is essentially ini style. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: g++-3.0 library support?
> > So if I wanna link an programm with the gcc-3.0 version, -lfoo-gcc3 has > to be used and for gcc-2.9x, -lfoo. > > Are there any better ideas? > unfortunately not, the ABI is different between the two. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Conference 2 Registration
> > It'd be a very, very bad idea for anybody to start doing or saying > anything non-constructive to Lindows.com. They as a company, and every > person I've dealt with through Lindows.com, employee or otherwise, have > been nothing but corteous and helpful, and have helped make Debconf 2 a > possibility. > if only I could afford to be in Toronto this summer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Spamassassin config files in /usr/share
On 06-Apr-2002 Malcolm Parsons wrote: > On Fri, Apr 05, 2002 at 11:45:08PM -0800, Blars Blarson wrote: >> Currently, I edit the file in /usr/share to implement my site-wide >> policies, but this will be overridden every time spamassassin is >> upgraded. > > Why not use dpkg-divert? > that is obviously a good short term solution. But should a user need to do this for the long term? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Choosing a toolkit
On 12-Jan-2002 [EMAIL PROTECTED] wrote: > There seem to be quite a few gui tookits: > Xlib, GTK+, Tcl/Tk, and Motif just to > name a few. I downloaded GTK+, but it > hasn't had a new stable version since > before 2000. > stable means stable. Why does there need to be a new release if the last one works? If you look at it that way, Motif is a complete waste of time, it hasnt seen a new version in several years. > What is the most common toolkit > that YOU use for x11 development? > Currently, GTK+ and QT are the most common for end user applications like email programs, web browsers, etc. Smaller, simpler programs may be tk, pure X, or other random toolkits. Seeing how Motif is not friendly to open source development it is no longer common to find.
RE: letters in upstream version numbers
On 26-Sep-2001 Noah L. Meyerhans wrote: > Lintian gives errors when looking at a package with letters at the > beginning of the upstream version number. Ch. 4 of policy indicates > that the upstream version can't begin with a letter. However, it > doesn't really indicate what should be done in case an upstream version > does begin with letters. In the case of the latest iputils package, it > is ss010824. Should I just drop the letters from the version number, or > is there some other preferred way of making it comply with policy. > > It might be worth it to add some text to policy clarifying this issue. > A problem here is knowing what is the next version. Is it st010824? maybe ss010825? I think a common solution is to put '0.' or '1.' in front of the upstream.
Re: lintian releases
On 26-Sep-2001 Steve Greenland wrote: > On 25-Sep-01, 17:56 (CDT), Sean 'Shaleh' Perry <[EMAIL PROTECTED]> wrote: >> a) you declare a relation on a package more than once i.e. Depends: >> foo, foo (<< 2.0). Note this check assumes that '|' relations are >> sane, so Depends: foo | bar | baz, foo is ok. > > How is that sane? I'm parsing that as "(foo OR bar OR baz) AND foo", > which is the same as "(bar OR baz) AND foo", right? If so, it should be > flagged as an error. (Yes, the dependendcy resolver should reduce it > correctly, but it should reduce "foo, foo (<< 2.0)" to simply "foo (<< > 2.0)" as well.) > Consider you have a package which wants a utility to parse html and a utility to download webpages. lynx happens to handle both. So you have: Depends: lynx | web-retriever, lynx | web-parser | perl-web-parser. If you left lynx out of either depends you would be forced to install a useless package. So I assume that OR statements are sane and do not parse them.
lintian releases
Seeing how I made DWN I thought I should send an update. 1.20.15 was admitted in this morning and everyone should get it in today's upgrade. It closes around 20 bugs. 1.20.16 was just uploaded due to two bugs submitted by Eduard Bloch. Lintian now has two more errors: a) you declare a relation on a package more than once i.e. Depends: foo, foo (<< 2.0). Note this check assumes that '|' relations are sane, so Depends: foo | bar | baz, foo is ok. b) UPX binaries are flagged as an error. It was discussed on irc and lists several months back that Debian did not want compressed binaries. The other reason for this is lintian's previous behaviour was to fall over due to objdump not giving good error info. Comments, suggestions, and bugs welcome as always.
Re: what happened to the dput package?
> > No, dput doesn't depend on ssh, it only suggest it like rsync. But it > depends on GnuPG now, therefor the change. > why the depends on gpg?
RE: Disappearing task-* packages!
On 25-Sep-2001 Taral wrote: > All the task-* packages seem to be missing from the main Packages file! > Where did they go? > > P.S. If this was announced, perhaps the announcement should have gone to > the debian-devel-announce list? > Task packages are deprecated, tasksel now handles them. This was announced several months back.
Re: what happened to the dput package?
On 25-Sep-2001 Steve M. Robbins wrote: > On Tue, Sep 25, 2001 at 02:10:22PM +0100, Andrew Suffield wrote: >> On Tue, Sep 25, 2001 at 02:07:36PM +0200, Jochen Voss wrote: >> > there used to be a package called "dput", >> > but now I cannot find it anymore. For example >> > visiting >> > >> > http://packages.debian.org/dput >> > >> > shows the message "No responses to your query" >> > and aptitude lists it as an obsolete package. >> > What happened to this package? Was it renamed? >> > Or did a do something wrong? >> >> It's moving to non-us, but is (was?) NEW, pending an overrides update. > > Really? Why? > it likely wants to depend on ssh.
RE: please test this lintian release
On 20-Sep-2001 Sean 'Shaleh' Perry wrote: > http://people.debian.org/~shaleh/lintian. > I have fixed the silly spelling error bug, lather, rinse and repeat.
Re: please test this lintian release
On 21-Sep-2001 Domenico Andreoli wrote: > On Thu, Sep 20, 2001 at 02:17:47PM -0700, Sean 'Shaleh' Perry wrote: >> http://people.debian.org/~shaleh/lintian. >> >> > there is some problem with debian/Debian spell checking, it reports > "spelling-error-in-copyright debian Debian" even if it is (IMHO) ok. > > lintian 1.20.14.1 says nothing about the same package. > > this is my copyright file > I added a check for 'debain' a very common misspelling. When I did I also mistakenly added 'debian' => 'Debian' to the list. I thought I removed it.
Re: please test this lintian release
On 21-Sep-2001 Adam Heath wrote: > On Thu, 20 Sep 2001, Sean 'Shaleh' Perry wrote: > >> http://people.debian.org/~shaleh/lintian. > > It's normally customary to include a brief list of things we should be > testing. It. The package. The thing I uploaded. Run lintian on your packages. Do you get new errors? Do one you think should occur not. You know the standard thing I ask for every time I release. Now I do release it has been 6 months, but come on, who does not know the drill by now.
please test this lintian release
http://people.debian.org/~shaleh/lintian.
RE: Running dpkg -r foo from a postinst script?
On 19-Sep-2001 Ola Lundqvist wrote: > Hi > > I have a simple question. Is it possible to run dpkg -r foo > from within a postinst-script when using dselect or apt? > > What is the result? > > It whould be very helpful when creating the improved harden > packages. :) > You just got nominated as the latest winner in the lintian contest! Soon you too will have a lintian check named after you.
Re: /bin/ls is impure!
> > It works... Something's wrong with your system. > Try strace'ing ls. > what shell are you playing with? I presume most people are using bash.
RE: [Q]: GNU inetutils and debian inetutils not in sync??
On 14-Sep-2001 Francis ANDRE wrote: > Hi DDG > > I check out the www.gnu.org inetutils against debian inetutils and I found > them out of sync?? > > Could anybody tell me why?? GNU inetutils is a FSF implementation, ours is the original BSD. The FSF is re-implementing long existing code so that they can GPL it.
RE: A language by any other name
> > What's the problem? German is spoken outside Germany. That what's > spoken outside Germany is not the same as that what's spoken inside > Germany, but that what's spoken outside is still called German > (officially), as far as I know. That is to say, de_AT.ISO-8859-1 is as > "german" as de_DE.ISO-8859-1. The same goes for French, Portuguese and > Spanish, this being the extreme case since it's spoken in 20+ countries > outside Spain but it's still called "Spanish" in all of them (ignore > "Castellano", please). What makes English different? In fact, after > thinking about this, and given what's stored in that file, I'd change > my bug to "please alias english to en_UK.ISO-8859-1" (or more > appropiately en_UK.ISO-8859-15) > In every app where I was presented the choice I had two -- English(British), English(American). We should do the same in the alias file. Better question is why does gdm expect English there when we don't have it. Are other dists or the upstream locale maint making this choice?
Re: call for lintian patches
On 12-Sep-2001 Edward Betts wrote: > Sean 'Shaleh' Perry <[EMAIL PROTECTED]> wrote: >> The lintian maintainer is back! I am slowly reading up on the new policy >> and >> my bug list. So, if you have any beefs or patches please read the BTS and >> submit accordingly. > > I presume you are looking for patches for lintian 1.x rather than lintian 2. > Am I right? > what is lintian 2.x? (-:
call for lintian patches
The lintian maintainer is back! I am slowly reading up on the new policy and my bug list. So, if you have any beefs or patches please read the BTS and submit accordingly.
Re: rfc1149
On 02-May-2001 Marcin Owsiany wrote: > On Wed, May 02, 2001 at 09:50:01PM +0200, [EMAIL PROTECTED] wrote: >> 11 years ago IETF described a IP protocol to transport IP datagrams using >> pigeons. > > African or European? > pidgeon, not swallow (-:
Re: rfc1149
> Actually, I think it has been implemented recently. I think maybe a > Debian package would have to go into contrib though, unless you can find a > way to squeeze pigeons into a .deb ;-) > > Hmm.."Depends: pigeons (>= 200lb)" > Why? We do not have 'Depends: CAT5 (<< 30m)'.
RE: rfc1149
On 02-May-2001 [EMAIL PROTECTED] wrote: > 11 years ago IETF described a IP protocol to transport IP datagrams using > pigeons. See > > http://www.ietf.org/rfc/rfc1149.txt > > Sadly enough, noone has still implemented this protocol. It would be nice to > make a debian-package of it. Anyone interested drop me a line. > actually, slashdot had an article recently with a LUG doing this in Norway. Most interesting.
RE: Two debconf issues
On 01-May-2001 Simon Richter wrote: > Hi, > > I'm currently debconfizing one of my packages, uptimed. Two quoestions > have arised: > > - At the start of my config script, I import all settings from the real > configuration file, if it exists. For some settings, this is trivial, > for some, I need rather complex text processing. Since perl isn't > essential, writing the script in perl would make the package depend on > perl while this is unnecessary for normal operation. Would this be > acceptable or should I find a better solution? > > - One of the strings should default to the empty string. How do I express > that in a templates file? > If you use debconf you are using perl (-: of course awk is your friend and mine.
Re: ash word-splitting changes break shell scripts
> The autoconf folks try very hard to write portable code. They go to > ridiculous lengths to support every major flavour of OS, compiler, > make, and shell. Indeed, Zack's tests show that only the recent ash > behaves differently. > more importantly (to me anyways) is the question of why do we ship an ash that is completely different from the one the netbsd (upstream) and RH (another packager). For a long time Xu has played games with ash for seemingly his own amusement. Frankly it is growing old.
Re: Are build-dependancies mandatory?
> > I still don't understand why the policy (version 3.5.3.0) > doesn't simply say "must" rather then "may". > Debian is a community which exists for the mutual benefit of its members. Members playing games like 'policy does not say I *HAVE* to do it' do not make Debian a better place. let's all place nicely together. Things like build-depends should be a no brainer to support, required or not.
Re: auditd as logrotate replacement?
> > What it does use for crypto is openssl's libcrypt, > wich is NOT needed when used as a simple (traditional) > rotate system. So Debian can ship audit[d], and if > a user wants it's advanced crypto support, she/he should > install openssl package. > does it dlopen this? in other words, if I have a system without openssl installed will auditd still work? If so, sounds like it can indeed live in main.
Re: auditd as logrotate replacement?
On 25-Apr-2001 Arthur Korn wrote: > Sean 'Shaleh' Perry schrieb: >> as long as lograte can be installed first, then I can later >> install auditd and everything will just work, sure. > > I can't use logrotate with msyslog, it won't work, logrotate is > just too limited. This would mean I have to move msyslog to > non-US, since I will make it depend on auditd. > 100% correct. > So, basically, since auditd does feature encryption, it does not > have any chance to be the default for log rotation, even if it > was a lot better than logrotate? What giant pile of crap. > unfortunately, yes. Maybe in a year. Or maybe 6 months. But not today.
RE: auditd as logrotate replacement?
On 25-Apr-2001 Arthur Korn wrote: > Hi > > I got an offer from the friendly people at Core-SDI to make > auditd (server part of theyer BSD licenced, in development, log > management software) a full (read: better) replacement for > logrotate. > > Will a package in non-US/main have any chance to be accepted as > full replacement for logrotate? As I understand being in non-US > does not mean that anybody can't use it, just that it can't be > distributed from mirrors in certain (braindead) countries. > as long as lograte can be installed first, then I can later install auditd and everything will just work, sure. Since it is in non-us, at least for now that means it will not appear on a official debian cd.
RE: NMUers: STOP BEING STUPID
On 23-Apr-2001 John Goerzen wrote: > OK, I'm rather annoyed. Recently I'm doing "squash bugs on my packages" > and I have had already THREE that have been broken by NMUs that > occured over the past week. > So perhaps we need to come up with some more structure for the bug parties. Perhaps the right thing to do is have those involved create diffs of their work and place these in a repository for some group of devels responsible for the party to look at. Once the patch has been approved, a NMU can happen in short order. This would prevent the NMUers from doing things like debhelper/debconfizing packages without the maintainer's consent, as well as keep NMU bugs down.
Re: finishing up the /usr/share/doc transition
> > I'd be glad to help. How should we proceed? Should we send patches to > the appropiate maintainers or directly upload the NMUs? Honestly, they > had enough time to tranist to /usr/share/doc. > send patch, wait some period of time (maybe a week?) then warn of NMU, then NMU.
RE: finishing up the /usr/share/doc transition
> > There are a total of 645 packages that have not been converted[2]. There > are 16 weeks between December 31st and Aj's projected freeze date for woody. > If 40 people could do one package a week, we would be done. Or 20 people > doing two a week, or just 6 people doing one a day. In other words, it > seems acheivable, especially if we file bugs now on the undone packages, > which would probably wake a fair number of maintainers up.. > > What do you think? > other than perl packages and debconf packages, lintian tests are getting quite close to showing policy complience. Perhaps we should start pinging people whose packages fail in lintian. Either way, yes, it would be nice to kill many many postinsts.
RE: linkchecker lintian warnings
On 22-Dec-2000 Bastian Kleineidam wrote: > Hi, > > if you test my linkchecker .deb package: > I just noticed that lintian gives the following warnings on my 1.2.12 > package of LinkChecker: > W: linkchecker: postinst-does-not-set-usr-doc-link > W: linkchecker: prerm-does-not-remove-usr-doc-link > a mental typo on my part in lintian. I am uploading 1.11.13 in a few minutes. Should be installed during dinstall run tomorrow. (btw it is debhelper, not debconf -- two different things)
RE: mp3 encoding patents.
On 13-Sep-2000 [EMAIL PROTECTED] wrote: > Hi all, > Sorry to bring up this subject again. > I just wanted to know that can't mp3 encoders be distributed from a non-us > site where the policies are much more relaxed ? > the patents are held in Germany. This restricts us because most countries in Europe accept them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: RFA: Gmp3 - Adopt it or remove it right away?
> > It isn't supported upstream anymore. Homepage is gone, > mail to author bounces. Gmp3 isn't very nice and a little > bit buggy for me. I don't have the knowledge and time to > work at the source and don't feel like trying, either. > I say ditch it. No sense filling up Debian with dead code. Especially when there are a billion mp3 players. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Python 1.6 released and GPL incompatible
> > 1) Ignore Python 1.6 and up, as long as the license is not compatible >with the GPL. That's probably the easiest way to go, but is it >justified ? Looks like a deliberate discrimination against a >DFSG-free license, only because it's not GPL compatible. > > 2) Include both Python 1.5.2 and 1.6 in woody/main. The 1.6 packages >would not satisfy the dependencies of existing packages; any maintainer >who'd make a package depend on Python 1.6 would have to make sure that >its license is compatible with the Python 1.6 license. > I think that we are going to see more and more cases of GPL "incompatibilities" as time goes on. I am disappointed that RMS is fighting over something as trivial as a company asking that legal issues be settled in their home state (country). This is common practice. Anyways, back to the issue at hand. What are the chances that ignoring 1.6 for say, 3 months will result in a 2.0 that we can actually use? Python 1.5 is solid and usable, 1.6 is not going to change anything that drastically. Chances are that we won't freeze before then, so you could work out with the rest of the python packagers a coordinated upload. You will likely have to support python 1.5 thru this release and drop it for the next, so adding yet another version would not be too healthy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP hodie
On 03-Sep-2000 Peter Makholm wrote: > "Christian T. Steigies" <[EMAIL PROTECTED]> writes: > >> What does it do? >> It has the same functionality as the date (1) program, only... It >> has it in grammatically correct latin. > > Couldn't this be done with gettext and the normal date comand? > possibly, but the author goes as far as to output time in roman numerals and what not. I am not up on gettext, but I was under the impression you could not run code to get the output. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: My recent bug's and continuing effort to debconf-ize Debian
On 01-Sep-2000 Colin Watson wrote: > "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> wrote: >>I started this afternoon submitting bugs against packages which print >>verbose output in their maintainer scripts. The future that Debian >>must take is to fully support debconf. To further this goal I will >>continue submitting patches to any package which prompts the user in a >>maintainer script. > > Are you also reporting bugs against packages whose priority is higher > than that of debconf? Is the plan eventually to raise debconf's priority > to 'standard' or higher? > currently, any package which uses debconf depends on it. Since most packages need it in their postinst, this is perfectly reasonable. Once debconf gains majority usage, I suspect joey will have it moved up. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: My recent bug's and continuing effort to debconf-ize Debian
> > But then it might interrupt the installation process. Just as debconf > asks all of the preinst questions before any of the packages have > started unpacking, it would be nice to be able to defer any questions > that *have* to wait for the postinst until the very end, when all of > the packages have been installed. > a) choose non-interactive and no debconf questions get asked. You can dpkg-reconfigure any package you need to b) supply debconf with the answers ahead of time c) *eventually* there will be a debconf server(right word?) which network admins can install. This will have the answers stored in it and then when boxes need to know an asnwer, they query debconf and it queries the server. This way, you can do unattended installs of an entire computer lab. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
My recent bug's and continuing effort to debconf-ize Debian
I started this afternoon submitting bugs against packages which print verbose output in their maintainer scripts. The future that Debian must take is to fully support debconf. To further this goal I will continue submitting patches to any package which prompts the user in a maintainer script. If any maintainer would like a) to join in the effort b) me to debconf their package or need help doing so please mail me. With debconf, Debian can have its own kickstart, or unattended installs, and all the other little things that people have been asking for years to have Debian support. This also means that companies using Debian to not have to rip apart packages because they ask too many questions. As for my patches to make maintainer scripts quiet, the days where the messages were useful have passed. They now whiz by during install leaving users wondering if they missed something. Or they scare the newbie. I watched an install yesterday where a package ran a tex function and echoed all the output to screen -- you know what tex output looks like to the unsuspecting? With task packages, users do not always know exactly what packages are being installed. I am not asking for Debian to coddle newbies. But the little things like package installation output can be easily changed.
RE: Machine-specific optimizations
> > So, is there any plan to use them (like recompiling the package on the user's > machine)? > you always have the option of using 'apt-get source' to recompile a package, then place it on hold and we wont touch it. Beyond that, it gets very messy. Not to mention the disk usage. Users who insist that they most optimize packages often are the same ones who compile everything for themselves anyways. The gain for the project as a whole versus time spent is not enough.
RE: BTS not showing my bugs
On 30-Aug-2000 Brian May wrote: > Ok, > > Can somebody explain the following? > >>From http://www.debian.org/Bugs/>, click on > "Index of maintainers of packages with bug reports.", and then > "Brian May <[EMAIL PROTECTED]>" takes you to: > http://www.debian.org/Bugs/db/ma/lBrian_May,bam,debian.org,.html> > > Why is bug #69807, for my diskless-image-secure package not shown??? the BTS is not happy right now. Static pages are not getting updated. See Debian Weekly News for details.
Re: /bin/ksh as a default POSIX shell
> > You cannot use it as a default shell without auditing all scripts. > I have used ash for over a year now as my /bin/sh.
RE: Paradise
> > Please let me know what I need to do or who I need to contact. I should > be on debian-devel but feel free to CC me. > we would like to know what license your software is under. We only place Open Source licensed code into Debian proper. See our web site for details (you will often hear this referred to as DFSG -- Debian Free Software Guidelines -- free. So, that out of the way, you either get an existing member of Debian to package your software or you enroll to be a developer yourself.
Re: how about a real unstable?
> > This is what experimental is for, no? > > Unstable is for unstable Debian, not necessarily unstable software. The > experimental distribution is much more appropriate for unstable upstream > software. > agreed with the addition that experimental must also be apt'able. Getting software from the bottomless pit that is experimental is nearly impossible right now. There is no information on what a package is for, depends on, or otherwise.
RE: Bug#58174
> > I don't think bugs like this should slow down our release cycle at all. IMO > this bug should be downgraded to normal. > > Comments anyone? > sounds fair, and little items (sorry) like metamail should not hold us up.
RE: So whos going to ALS
On 05-Oct-99 Johnie Ingram wrote: > > ... and would be willing to help at the Debian booth (#503, community > pavillion, check it out), or who knows good places to stay at in > Atlanta? Or who wants to planepool with the Novare team from Dallas? > > Joey Hess and myself are going. We have one extra space in the hotel room. Preferably for a Debian developer, preferably one who needs to save the money. We have two double beds and currently three people, a fourth is welcome. If you want a spot on the floor, well that can be arranged as well (-: We arrive Wednesday night at 7:30pm, so room is available from Wednesday night on thru Saturday night.
RE: I need some help during ALS
On 05-Oct-99 Vaidhyanathan G Mayilrangam wrote: > Hi All, > > As you all probably know, ALS is from Oct. 12 - 16 at Atlanta. I am having > trouble running any kernel above 2.2.5 on my machine. If anyone is coming and > would want to help me with this problem, I would appreciate it. I can bring > my machine to the ALS hall. > A laptop is ok, bringing a actual box is rather complicated. We only have so much power, room, monitor space, etc.
Re: SSH never free
On 01-Oct-99 Jason Gunthorpe wrote: > > On 1 Oct 1999, James Troup wrote: > >> [ RSA is no longer included. ] > > Wait wait, doesn't this mean that ssh RSA authentication is gone as well?? > Did they replace it with DSS/DH or what? IMHO ssh would cease to be very > usefull as a security tool without a public key mechism, not to mention > that existin ssh clients would not be able to securely connect to obsd-ssh > servers :< > There is rsa.c written by someone in Finland (I believe the original ssh author).
Re: {R,I[INEW]}TP: free ssh [non-US]
On 01-Oct-99 Jason Gunthorpe wrote: > > On 30 Sep 1999, James Troup wrote: > >> OpenBSD have started working on the last free SSH (1.2.12 was under a >> DFSG free license AFAICT[1]), they also, (again AFAICT [I'm going by >> the CVS commits]), are ripping out the patented algrothims (IDEA, >> etc.). Unfortunately, I'm chronically busy with work and haven't had > > This is very exciting, ssh is one of the few remaining non-free programs > that debian relies on, it would be very nice to get a real replacement. > > Can someone corfirm the DFSGness of it? > The old ssh was free. The license this ships with is very BSD. The code all says it is ok as well. Seems ok, openbsd are fanatics about licenses and security, so I doubt they would do something as stupid as include a non-free ssh.
Re: Packages should not Conflict on the basis of duplicate funct
> > e) Let update-inetd handle this. This might not be enough for standalone > servers like apache and roxen but it would work with a pop3 server - > update-inetd -add should notice that there is already a valid entry enable > with that service and add the new entry with a hash mark. > Not enough. Most pop3 can be either inet or stand alone. As can most other things.
RE: ITP: portsentry
On 29-Sep-99 Rene Mayrhofer wrote: > portsentry is a daemon that listens for port scans (also stealth scans) > and is able to disconnect and remember the attacking hosts in real-time. > It uses ipchains for disconnecting and tcp wrappers for preventing hosts > from further connections. > Please look at http://www.psionic.com/abacus/portsentry/ for a closer > description. > > A beta version of the package is already used at 2 production firewalls > and 3 servers that I administer. > This is already packaged. Please read the d-devel archive.
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?
Re: Packages should not Conflict on the basis of duplicate funct
On 27-Sep-99 Clint Adams wrote: >> 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? > Because as everyone knows the last 10% takes 90% of the work and often ends up hurting the other 90%. The point is Debian needs to work for as many people as possible. We are doing near this currently. One of our strong advantages is that after install, you have a working system. Compared to most other dists, we are far ahead here. To then say "but some people dont want that" and hurt every one is bunk. I used to work at an isp, there is a debian-isp mailing list, and debian's largest use is in the server market. We are currently pleasing most people I talk to in this regard. The point is that supporting what you want runs contrary to how Debian currently works and how most people expect it to. Is it so hard to type: apt-get source qpopper cd qpopper- $EDITOR debian/control s/Conflicts: pop-server// s/Replaces: pop-server// s/Provides: pop-server// save, quit fakeroot debian/rules binary cd .. 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. 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. 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. 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.
Re: Packages should not Conflict on the basis of duplicate funct
> > So what you're telling me is that anyone with a "complex" setup > shouldn't bother using Debian? > a) I would not test a new daemon on a working machine, I would use a separate one. In the case of gnu pop3, it will spin off and consume 99% of your cpu due to poor child management. We (I am one of the developers) are fixing this, but currently it is test quality if not run from inetd. 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. Debian is operating on making the easy case easy. 90+% of our users want to just install a package and go.
RE: debconf for configuring a room full of machines
The bigger issue is that until debconf has a real db, passing the answers an admin would want into packages is rather painful. Yes, this will allow for great power -- in the future. The Debian install procedure is undergoing lots of change.
RE: libwxx-gtk 2.1
On 17-Sep-99 Christian Surchi wrote: > Does a package of these libs exists? > I was supposed to be taking them over. However I am stretched a wee thin at the moment. So, if you or someone else would like to help, feel free. The one requirement being that wxPython also needs to be cleaned up at the same time.
RE: Installing things into run-parts or .d directories.
Or the script could simply test and run like the init.d scripts do. On 09-May-99 Karl M. Hegbloom wrote: > > What if a package is installed, and puts a script in a run-parts > directory or into a .d directory, but isn't configured due to a > missing dependancy? The newbie "sysadmin" doesn't know to look for > it, and leaves it there, then gets email from cron. Per sends off a > tech support question. > > This could be prevented by having a place (/etc/cron.scripts, or > /etc/cron.d/crontabs) to install things to, then require that the > postinst create a symlink during configuration. > > Hmmm... > /etc/crontabs > /etc/crontabs/crontab > /etc/crontabs/cron.d/ > /etc/crontabs/pkg_blah_script > ... > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
