Re: Recherche d'un sponsor pour adopter distributed-net
Essaie debian-mentors... Simplement, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpnVHJLR1VD4.pgp Description: PGP signature
Re: Recherche d'un sponsor pour adopter distributed-net
Le 26 mai 2003, Pierre THIERRY, à bout, prit son clavier pour taper sur son écran: Essaie debian-mentors... Déjà essayé. @+ -- JabberID: [EMAIL PROTECTED] Pixar Animation Studios: Reality is not our business. Pixar's Toy Story $184,849,036 domestic, $117.5M overseas and counting. That makes it number 21 in box office figures of all films ever released. pgp4cOOcGtn2G.pgp Description: PGP signature
Re: Recherche d'un sponsor pour adopter distributed-net
Quoting Loïc Le Guyader ([EMAIL PROTECTED]): Le 26 mai 2003, Pierre THIERRY, à bout, prit son clavier pour taper sur son écran: Essaie debian-mentors... Déjà essayé. Le pb, c'est que le cas est loin d'être simple : comme tu le dis dans le bogue que tu cites, ce que tu proposes est un précédent dans Debiansi j'ai bien compris. Pour un parent adoptif en puissance, ça fait réfléchir.. :-). J'avoue avoir regardé ce matin en voyant ton mail un peu désespéré...mais je recule. D'abord, il y a pas mal de domaines que je ne maitrise pas forcément bien sur ce type de paquetet, du coup, je ne me sens personnellement pas à la hauteur. La difficulté, c'est que le paquet que tu proposes de reprendre demande, amha, une bonne et solide expérience...En tout cas, cela va à mon sens au delà de ce que je sais personnellement faire.
Re: Debian conference in the US?
On Sun, 25 May 2003, Sven Luther wrote: So let me get this straight. Instead of a country where people are occasionally subject to bureaucratic hassles, (assuming Russell and Geordies' sources amount to anything more than innuendo which is not clear.) you would rather go to a place where the immigration policy consists of shooting people? And you do have proof of that claim, do you ? Or did you only gather that from a bunch of James Bond movies ? Friendly, Sven Luther I could swear there are more examples but a very quick google search only turned up this[1] from 1993. Perhaps now things have changed and now you only get shot for staying _in_ Cuba[2]. [1] http://www.fiu.edu/~fcf/us.rips.cruelty.html [2] http://www.guardian.co.uk/cuba/story/0,11983,944925,00.html -- Jaldhar H. Vyas [EMAIL PROTECTED] La Salle Debain - http://www.braincells.com/debian/
Re: Debian conference in the US?
Jaldhar H. Vyas wrote: The West coast may be more expensive to get to for foreign visitors. But I like the other suggestion of Florida. Lot's of cheap flights to there. i live on the west coast (san diego, specifically), but if there was a debconf held in southern florida (fort lauderdale, specifically) i would do my damndest to get there. -john, one of the rarest of breeds: a native floridian
Re: Debian conference in the US?
John H. Robinson, IV [EMAIL PROTECTED] writes: this is entirely off topic for -devel, let's move it to -politics or -curiosa or somewhere else more appropriate. But you just _had_ to get your bitter little rant in first, huh? -Miles -- Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.
Re: Bug#194155: ITP: ehnt -- Extreme Happy Netflow Tool - Obtains useful information out of netflow data
On Sat, May 24, 2003 at 12:55:33PM +0200, Marc Haber wrote: On Wed, 21 May 2003 21:40:04 +1000, Craig small [EMAIL PROTECTED] wrote: The flow reports come out in text and show flow summaries (such as top n ASes, protocols, etc per m minutes). NetFlow is a packet protocol that is used by routers such as Cisco and Juniper. Is there any tool that enables a Linux router to generate netflow data, coexisting with Cisco and Juniper generated data? There is a program (MeTraNet?). AFAIK not packaged for Debian. Sorry I don't have a URL. A quick google search reveals no useful results. Last time I tried it, I had problems trying to understand the basic concept of NetFlows, so didn't get far; possibly if I tried it again, I would get further this time. -- Brian May [EMAIL PROTECTED]
Re: Bug#194705: ITP: yavipin -- daemon for creating secure tunnels
On Sun, May 25, 2003 at 08:49:06PM -0500, Graham Wilson wrote:
* Package name: yavipin
How does it differ from OpenVPN?
--
:(){ :|:};:
Re: Help wanted for packaging postgresql application
On Sun, 25 May 2003, Matt Zimmerman wrote: For python, you only need to declare Depends: python to ensure that python is installed and configured when your postinst runs. Are you sure that the python interpreter is working if python is just installed at the same time (apt-get run) in which GnuMed is installed. You just negated the predepends-question and thus I think you have thought about that when writing this answer. postgresql is more complex, because (presumably) you want to allow for a remote database. If so, you must prompt the user for the hostname, authentication information, etc. and fail if you are unable to connect to it. If you only support a local database, you can just depend on postgresql-server or whatever is appropriate. I will split the GnuMed package into several binary packages. Currently I'm talking about the server package which installs a database on localhost. But I have to relay that postgresql-server is up and running when the postinst of gnumed-server is starting. I believe someone is working on a python debconf interface, but I do not know its status. You can probably find out with some searching and email. There was an announcement and ... silence. If you store the password in a temporary file, make sure that you do it securely, using e.g. $(tempfile -m 0600) so that it is created with O_EXCL and secure permissions before you try to put any data into it. Yes, this is what I just implemented. This will do the trick as long I will wait for the Python interface. (Sorry I just wait because I'm not competent enough to push the development.) I guess this Python interface will be ready right in time before GnuMed reaches production state. This ends in psql: FATAL: IDENT authentication failed for user mytestuser Now I would llike to know the following two things: 1. How to change the postgresql configuration in a way which just adds minimum off additional rights? 2. How to accomplish this change? Presumably you use a GRANT command as in ANSI SQL92. The specifics may be slightly different for postgresql's unix socket authentication; I am not so familiar with it. I guess this is not the reason for the problem. It is an authentication problem as some further tests I tried show clearly. Some magic has to be done in /etc/postgresql/pg_hba.conf but I did not found a reasonable way to continue enabling the prefered ident method with password/crypt for this single (and perhaps further) users. Kind regards Andreas.
Re: Help wanted for packaging postgresql application
Hi, Andreas Tille wrote:
1. How to change the postgresql configuration in a way which just
adds minimum off additional rights?
I'd say don't. The user should be able to set up a new postgresql user
by themselves, or maybe they'd like to reuse an existing account, or maybe
they want to use their own account creation script.
You might want to offer a re-enter and retry step if the setup fails
(misspelled password?).
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
As nations improve, so do their gods.
[G. C. Lichtenberg (1742-1799)
German physicist, writer]
Re: Help wanted for packaging postgresql application
On Mon, 26 May 2003, Matthias Urlichs wrote: Hi, Andreas Tille wrote: 1. How to change the postgresql configuration in a way which just adds minimum off additional rights? I'd say don't. The user should be able to set up a new postgresql user by themselves, or maybe they'd like to reuse an existing account, or maybe they want to use their own account creation script. Creating a system account matching the postgresql user is definitely no option. The GnuMed system creates more than one database user and this would mean in the end bloating server and client boxes with unused system accounts. You might want to offer a re-enter and retry step if the setup fails (misspelled password?). No, I just tried a Python-Script doing the job using the very same variable for creating the account with password and opening the connection. Thus the postgresql server has to allow connections of non system users from localhost and also from other hosts (GnuMed clients) in the next step while keeping the possibility to authenticate via ident. Kind regards Andreas. PS: CC to debian-postgresql which seems apropriate for this part of the question.
Re: Unofficial projects related with Debian.
Enrico Zini wrote: On Fri, May 23, 2003 at 09:55:33PM -0400, David B Harris wrote: http://www.debian.org/devel/, Projects section: * Debian Web Pages [...] * Alioth: Debian GForge Certainly seems that they're listed. The Debian Usability Research seems to be missing: http://deb-usability.alioth.debian.org Fixed. Regards, Joey -- If you come from outside of Finland, you live in wrong country. -- motd of irc.funet.fi Please always Cc to me when replying to me on the lists.
Re: debian-exim mailing list?
Josip Rodin [EMAIL PROTECTED] wrote: I'm perplexed about the mailing list request about Exim. As Marc already noted this special request should simply be ignored now, we have alioth now and currently there isn't much traffic on exim4debian. On one hand, exim is an important package, and there are already ample precedents like debian-apache, debian-ssh and debian-tetex-maint; but on the other hand, there's alioth.debian.org which allows for easier creation and maintenance of per-package mailing lists. lists.debian.org has its merits: Very official, easy to find, webarchives, gating to newsgroups via linux.debian.*, _working_ Anti-Spam measures. I really do not know how alioth's lists compare, because I have not subscribed to one yet. It would be nice if there were documented mechanisms to move a list /painlessly/ from alioth to lists and vice versa, i.e. keeping the subscriber list and redirections for the old list addresses. cu andreas
Re: Help wanted for packaging postgresql application
Andreas Tille (2003-05-25 21:56:04 +0200) : For the next problem I have no real clue for a solution. The bootstrap method does access the database as the newly created user this requires a change of the PostgreSQL configuration. [...] Now I would llike to know the following two things: 1. How to change the postgresql configuration in a way which just adds minimum off additional rights? 2. How to accomplish this change? You might like to have a look at how the gforge-db-postgresql package (available from http://people.debian.org/~lolando/) does it. Basically, prepare a new pg_hba.conf, and ask the user whether to replace the existing one. Default to no, of course. Roland. -- Roland Mas Ace of clubs? Let's see that. European Juggling Convention -- Svendborg, Denmark. http://ejc2003.dk
Re: debian-exim mailing list?
Bernd Eckenfels wrote: On Sun, May 25, 2003 at 11:03:36PM +0200, Josip Rodin wrote: but on the other hand, there's alioth.debian.org which allows for easier creation and maintenance of per-package mailing lists. we should generally decide to migrate (all) mailinglists, or only create new project mailinglists and not user support lists, or whatever. In fact I dont mind about which solution/decision is done, I just dont think it is a good idea to suddenly point people to alioth like it always existed, and it is the only reasonable way to go. There are quite a lot of reasons to not host a list on alioth. Most prominent the fact, that it is not visible on the mailinglist page. Cannot talk about the QOS. lists.debian.org will run major lists of general interest. Alioth is very good for small projects, small lists and the like. Any Debian developer can set up lists and projects there. If the project has become large and a list at lists.debian.org is wanted, a move can be discussed. -- If you come from outside of Finland, you live in wrong country. -- motd of irc.funet.fi Please always Cc to me when replying to me on the lists.
Re: Debian conference in the US?
On Fri, May 23, 2003 at 10:03:38AM -0700, John H. Robinson, IV wrote: that north america contains not one, but three countries: Candada, USA, and Mexico Candada? Is that near Canadia? --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: debian-exim mailing list?
Marc Haber (2003-05-25 23:53:31 +0200) : We actually discussed on the internal exim mailing list whether to move the existing mailing list to alioth and decided against doing so for lack of a web archive. Point of information: lists on Alioth are managed by Mailman, which does provide a web archive. Admittedly, not the same interface as what's on http://lists.debian.org, and no search engine, but still present. I have no idea (nor desire to get one) on what you're debating, though. Just pointing out a fact. I really don't care whether you create a list on Alioth, or on lists.debian.org, or not at all. Roland. -- Roland Mas Êtes vous sûr ? (O/N) -- Derniers mots d'un ordinateur
Re: Debian conference in the US?
On Mon, May 26, 2003 at 12:05:02AM -0400, Jaldhar H. Vyas wrote: On Sun, 25 May 2003, Sven Luther wrote: So let me get this straight. Instead of a country where people are occasionally subject to bureaucratic hassles, (assuming Russell and Geordies' sources amount to anything more than innuendo which is not clear.) you would rather go to a place where the immigration policy consists of shooting people? And you do have proof of that claim, do you ? Or did you only gather that from a bunch of James Bond movies ? Friendly, Sven Luther I could swear there are more examples but a very quick google search only turned up this[1] from 1993. Perhaps now things have changed and now you only get shot for staying _in_ Cuba[2]. No more than you get shot by living in the US. I know people who have been in cuba, and they report no such things, and they also don't just stayed in the hotels. The articles you mention was about people dying when trying to leave their country to emigrate to the US. It was an isolatedact, even the US official cited in the article told this, and still, are you sure it was so or is it just desinformation ? Friendly, Sven Luther
Bug#190302: Misusage of changelog!
reopen 190302 thanks Hi! imagemagick (4:5.5.7.3-1) unstable; urgency=low * New upstream version. * Upstream fix: closes: #194306, #129990, #161422, #186610 * This is not ImageMagick bug. : closes: #190302 -- Ryuichi Arafune [EMAIL PROTECTED] Fri, 23 May 2003 20:44:23 +0900 You are plainly misusing your changelog for closing #190302. This has *nothing* to do in the changelog, there are no *changes* in this upload that address this. Rather send a mail to [EMAIL PROTECTED] explaining why you close them. Btw., your line for Upstream fix: closes: is not very helpful for the bug submitters neither. They'd have to check their records to see what this bug really was. Please add informations on what was fixed so it can be seen offline, too. Have fun, Alfie -- 'oder?' heisst wohl, dass Sie es nicht so genau wissen. Vielleicht sollten Sie sich erst einmal kundig machen. -- unknown XxXX-Employee pgpWwM7J5lSSH.pgp Description: PGP signature
Re: Bug#190302: Misusage of changelog!
On Mon, May 26, 2003 at 11:16:51AM +0200, Gerfried Fuchs wrote: You are plainly misusing your changelog for closing #190302. This has *nothing* to do in the changelog, there are no *changes* in this upload that address this. Rather send a mail to [EMAIL PROTECTED] explaining why you close them. I agree on this, but Btw., your line for Upstream fix: closes: is not very helpful for the bug submitters neither. They'd have to check their records to see what this bug really was. Please add informations on what was fixed so it can be seen offline, too. I really don't see the point in this. Submitters always have a copy of their report, so they have evrything they need. New upstream closes: #1, #2, #3 implyes an update of the upstream changelog file so it's worth of checking: listing changes already documented would be redundant and not so helpful. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language.
Re: Help wanted for packaging postgresql application
On Mon, 2003-05-26 at 08:19, Andreas Tille wrote: Thus the postgresql server has to allow connections of non system users from localhost and also from other hosts (GnuMed clients) in the next step while keeping the possibility to authenticate via ident. In 7.3, you can specify connection/database/user combinations with associated authentication methods. If you want to use ident where possible and fall back on password, pg_hba.conf should look something like this: CONNECTION DATABASE USER IPADDR IPMASK METHOD OPTION localallpostgres identsameuser localdb1fred identsameuser localdb1george identsameuser localdb2@db2.listidentsameuser localallall md5 host allall0.0.0.0 255.255.255.255 md5 So system logins fred and george can connect to db2 without a password; any system user listed in $PGDATA/db2.list can similarly connect to db2; postgres can connect to any database (necessary for backups) and any other connection/database/user combination needs an md5-encrypted password. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C Let nothing be done through strife or vainglory; but in lowliness of mind let each esteem other better than themselves. Philippians 2:3
Re: Help wanted for packaging postgresql application
On Sun, May 25, 2003 at 09:56:04PM +0200, Andreas Tille wrote: The bootstrap routine creates a postgres user where the user is asked for a password. I would like to ask via debconf for the password. Is there any method to access the debconf database with Python? Currently I have the plan to use a shell procedure to You could execute the following commands via os.system /usr/share/debconf/frontend '. /usr/share/debconf/confmodule \ db_get bla-blup/my_secret_passwd \ db_stop echo $RET /tmp/bla' where /tmp/bla is either a temporary file or a named pipe. Not nice but should work, you'll have to make sure you create /tmp/bla in a secure manner though. -- Guido
Re: Bug#190302: Misusage of changelog!
Luca - De Whiskey's - De Vitis [EMAIL PROTECTED] a tapoté : On Mon, May 26, 2003 at 11:16:51AM +0200, Gerfried Fuchs wrote: You are plainly misusing your changelog for closing #190302. This has *nothing* to do in the changelog, there are no *changes* in this upload that address this. Rather send a mail to [EMAIL PROTECTED] explaining why you close them. I agree on this, but Btw., your line for Upstream fix: closes: is not very helpful for the bug submitters neither. They'd have to check their records to see what this bug really was. Please add informations on what was fixed so it can be seen offline, too. I really don't see the point in this. Submitters always have a copy of their report, so they have evrything they need. New upstream closes: #1, #2, #3 implyes an update of the upstream changelog file so it's worth of checking: listing changes already documented would be redundant and not so helpful. Not necessarily. People that submitted these bugs will receive by mail a notice with the debian changelog, not the original changelog. -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Re: Bug#190302: Misusage of changelog!
On Mon, May 26, 2003 at 01:17:23PM +0200, Mathieu Roy wrote: I really don't see the point in this. Submitters always have a copy of their report, so they have evrything they need. New upstream closes: #1, #2, #3 implyes an update of the upstream changelog file so it's worth of checking: listing changes already documented would be redundant and not so helpful. Not necessarily. People that submitted these bugs will receive by mail a notice with the debian changelog, not the original changelog. Yes. And the very same mail will include the original mail that created the bugreport. That, to the very least, should give them a little explanation as to what is going on... -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts.
Re: Bug#190302: Misusage of changelog!
On Mon, May 26, 2003 at 04:58:01AM -0500, Luca - De Whiskey's - De Vitis wrote: On Mon, May 26, 2003 at 11:16:51AM +0200, Gerfried Fuchs wrote: [...] Btw., your line for Upstream fix: closes: is not very helpful for the bug submitters neither. They'd have to check their records to see what this bug really was. Please add informations on what was fixed so it can be seen offline, too. I really don't see the point in this. Submitters always have a copy of their report, so they have evrything they need. [...] Which does not help everybody else at all, who have just the meaningless changelog and are using apt-listchanges to read it before installation. Putting just numbers in the changelog makes it list of links, that is completely useless if you are offline. cu andreas
Re: Bug#190302: Misusage of changelog!
On Mon, May 26, 2003 at 01:56:27PM +0200, Wouter Verhelst wrote: I really don't see the point in this. Submitters always have a copy of their report, so they have evrything they need. New upstream closes: #1, #2, #3 implyes an update of the upstream changelog file so it's worth of checking: listing changes already documented would be redundant and not so helpful. Not necessarily. People that submitted these bugs will receive by mail a notice with the debian changelog, not the original changelog. Yes. And the very same mail will include the original mail that created the bugreport. That, to the very least, should give them a little explanation as to what is going on... Yes, but there's still no bloody point in making the submitter hunt around for information that the maintainer already knows and for which it takes them full 10 seconds per bug to list (15 if they type very slowly). -- 2. That which causes joy or happiness.
Re: Bug#190302: Misusage of changelog!
On Mon, May 26, 2003 at 02:26:10PM +0200, Andreas Metzler wrote: Which does not help everybody else at all, who have just the meaningless changelog and are using apt-listchanges to read it before installation. I don't see even this: are you warried about grave bugs? Use apt-listbugs. BTW, you can always grep the upstream changelog from the deb file using dpkg-extract. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language.
Re: Bug#190302: Misusage of changelog!
On Mon, May 26, 2003 at 02:45:16PM +0200, Josip Rodin wrote: Yes, but there's still no bloody point in making the submitter hunt around for information that the maintainer already knows and for which it takes them full 10 seconds per bug to list (15 if they type very slowly). Submitter receive a mail from bts which include the message that opened the bug: what should he hunt for exactly? ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language.
Re: Help wanted for packaging postgresql application
Andreas,
For the next problem I have no real clue for a solution. The
bootstrap method does access the database as the newly created user
this requires a change of the PostgreSQL configuration. To make the
problem clear look at the following shell script:
#!/bin/sh
TUSER=mytestuser
PASSW=jippi
HASUSER=`echo SELECT count(*) FROM pg_user WHERE usename = '${TUSER}'
| \
psql template1 | \
grep ^[[:space:]]*[0-9]\+ | \
sed s/^[[:space:]]*\([0-9]\+\)/\1/`
if [ $HASUSER -eq 0 ] ; then
echo CREATE USER ${TUSER} WITH PASSWORD '${PASSW}' CREATEDB | \
psql template1
else
echo User $TUSER exists.
fi
psql --username ${TUSER} --password template1 EOF
SELECT COUNT(*) FROM pg_tables
EOF
This ends in
psql: FATAL: IDENT authentication failed for user mytestuser
This does not fail because mytestuser has insufficient
rights inside PostgreSQL but beecause PostgreSQL tries to
verify general access rights to the database by trying to
match up the *database* user to the current *system* user via
identd. Since they don't match the access fails. Adding a line
to pg_hba.conf that allows database users other than the
executing system user to access the needed databases
restricted to, say, the local machine should alleviate this
problem. The auth_type must be set to passwd, crypt, md5 or some
such. Just not to IDENT or TRUST. (Well, TRUST should work but
we don't want that.)
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Re: security in testing
* Sven Luther [EMAIL PROTECTED] [2003-05-16 13:33]: Such a package should be as close to possible to the version actually in testing, and not depend on packages and/or versions that are not yet in testing. So, you request more or less that every developer should backport fixes themself from the usual new upstream version that fixes the problem (and mostly always have new features too) to the version in testing, which might even be older than just one upstream release, due to usual holdups in the transition. It sounds like you like to have every developer be able to do what the security team does. That requires much skill -- much more than most of us possess! I for my part don't think that I could spend enough efforts in doing this correct, and I don't think that I'm that far below average in skills of the usual debian developer. What _is_ needed to do it correct to make it work is having people that are *willing* to do such backport fixes -- and still people only keep repeating that it is needed and needed, but still noone is stepping forward to do the actual work. I for my part would be pleased to be of help when it's needed, but I'm afraid that I lack of skill to be in the core team (hell, I'm JAPH, with some C knowledge, but when it comes to python, C++, java or whatever I'm out of luck), left aside the time constraints I'm currently facing. Also, we could add 2 things, first the RM assitants, which are debian developers who have voluntereed to help the RM in this, and have the right to give the green light to uploads. Off topic: I haven't seen it on d-d-a, are they decided yet? Just curious. Second, what could be done about NMUs. Maybe a small group of apprentice security team members could scan the security announcements, and prepare NMU of such security holed packages, in close contact with the maintainer and the RM or his assistants, or maybe even the security team, especially if the problems are also present in stable packages. This is nothing new and was said over and over again -- just that noone yet seem to have raised interest to do the work! Sorry for my pessimism but I doubt that this thread will really make anyone step forward this time I'd love to be told otherwise! So, with such an announcement, everyone wins Noone wins if noone likes to do the work, like I said before in this thread. It would just make us look even more awkward, I guess. the maintainer will be able to fix things in testing more easily I've I understand you correct it wouldn't be easy, for backporting fixes seldom is easy. So long! Alfie -- Alfie I have a little problem with a bug-report I received... *scratch* doogie Alfie: I send those to /dev/null -- #debian-devel pgp0KALJpZWCE.pgp Description: PGP signature
Re: What makes a debconf?
On Sunday, May 25, 2003, at 08:10 PM, Jonathan Oxer wrote: Maybe a reasonable compromise would be to have 2 'official' debconfs / year, as 'Debconf North' and 'Debconf South' (as in Northern and Southern hemisphere). I've got no problem with this. I wouldn't really even have any problem with a Debconf East and West, either. The conflict occurs, though, when two such conferences (or opportunities for them) come up in the same area. Such is the issue with the bid for a conference in D.C. vs. my bid for one in Vancouver.
Re: Bug#190302: Misusage of changelog!
On Mon, May 26, 2003 at 08:12:51AM -0500, Luca - De Whiskey's - De Vitis wrote: On Mon, May 26, 2003 at 02:45:16PM +0200, Josip Rodin wrote: Yes, but there's still no bloody point in making the submitter hunt around for information that the maintainer already knows and for which it takes them full 10 seconds per bug to list (15 if they type very slowly). Submitter receive a mail from bts which include the message that opened the bug: what should he hunt for exactly? Perhaps the submitter might like to know what was changed to fix the bug? I don't know about you, but I usually actually go and confirm the fix rather than blindly accepting it. -- Colin Watson [EMAIL PROTECTED]
Re: Bug#190302: Misusage of changelog!
On Mon, May 26, 2003 at 08:12:51AM -0500, Luca - De Whiskey's - De Vitis wrote: Yes, but there's still no bloody point in making the submitter hunt around for information that the maintainer already knows and for which it takes them full 10 seconds per bug to list (15 if they type very slowly). Submitter receive a mail from bts which include the message that opened the bug Uh, no, they don't. Let me find an example... ah, here's one: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193974msg=8 -- 2. That which causes joy or happiness.
Re: debian-exim mailing list?
On Sun, May 25, 2003 at 11:03:36PM +0200, Josip Rodin wrote: I'm perplexed about the mailing list request about Exim. On one hand, exim is an important package, and there are already ample precedents like debian-apache, debian-ssh and debian-tetex-maint; but on the other hand, there's alioth.debian.org which allows for easier creation and maintenance of per-package mailing lists. What do others think? I'd prefer that we didn't migrate everything to alioth as the easy way out, but I don't have any good reasons for that preference. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: What makes a debconf?
On Mon, 26 May 2003 23:43, Joe Drew wrote: On Sunday, May 25, 2003, at 08:10 PM, Jonathan Oxer wrote: Maybe a reasonable compromise would be to have 2 'official' debconfs / year, as 'Debconf North' and 'Debconf South' (as in Northern and Southern hemisphere). I've got no problem with this. I wouldn't really even have any problem with a Debconf East and West, either. The conflict occurs, though, when two such conferences (or opportunities for them) come up in the same area. Such is the issue with the bid for a conference in D.C. vs. my bid for one in Vancouver. Having a single debconf was a good idea when it was first started in Bordeaux. Since then things have changed, there is more apparent demand for conferences and more reluctance to travel. There's no reason why you couldn't have Debian conferences in both places. Both Canada and the US have decent populations for local attendance and for each one you should get enough people attending from other countries. If you can get a venue, arrange suitably priced accomodation, organize a team of people to do the work of running it, and find enough celebrity speakers then you can run a conference regardless of what else happens. It would be nice if we could have a Debian day before or after OLS... -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: security in testing
On Mon, May 26, 2003 at 03:24:49PM +0200, Gerfried Fuchs wrote: * Sven Luther [EMAIL PROTECTED] [2003-05-16 13:33]: Such a package should be as close to possible to the version actually in testing, and not depend on packages and/or versions that are not yet in testing. So, you request more or less that every developer should backport fixes themself from the usual new upstream version that fixes the problem (and mostly always have new features too) to the version in testing, which might even be older than just one upstream release, due to usual holdups in the transition. It sounds like you like to have every developer be able to do what the security team does. That requires much skill -- much more than most of us possess! Well, that would be the ideal thing, but then, notice that i said 'should' and not 'must'. Clearly each debian developer is the person to take the decision on which version should go into testing-proposed-updates, it is just that by minimizing the changes, it makes it easier for the RM or his assitant to feel secure about this. If the package maintainer sense that the same version as the unstable one should be uploaded, then he can, but it should be with a lower version number than the unstable has. I for my part don't think that I could spend enough efforts in doing this correct, and I don't think that I'm that far below average in skills of the usual debian developer. Notice that in most case, the version in testing and in unstable should be very close, especially once we have this scheme working, and will often differ only in debian revision. If this is such, applying a bugfix to the unstable version and applying it to the testing version is the same work, if there is a new upstream release that fix the bug, then this should be built for unstable, provided it is buildable in testing. What _is_ needed to do it correct to make it work is having people that are *willing* to do such backport fixes -- and still people only keep repeating that it is needed and needed, but still noone is stepping forward to do the actual work. I for my part would be pleased to be of help when it's needed, but I'm afraid that I lack of skill to be in the core team (hell, I'm JAPH, with some C knowledge, but when it comes to python, C++, java or whatever I'm out of luck), left aside the time constraints I'm currently facing. No, i don't think that the same strenous version restriction that e have for stable also apply for testing. So a maintainer is much more qualified to do the job, and can also easily do it. Also, we could add 2 things, first the RM assitants, which are debian developers who have voluntereed to help the RM in this, and have the right to give the green light to uploads. Off topic: I haven't seen it on d-d-a, are they decided yet? Just curious. No, i think it has fallen in forgoteness (or something such, there must be a english sentence to express this properly). Second, what could be done about NMUs. Maybe a small group of apprentice security team members could scan the security announcements, and prepare NMU of such security holed packages, in close contact with the maintainer and the RM or his assistants, or maybe even the security team, especially if the problems are also present in stable packages. This is nothing new and was said over and over again -- just that noone yet seem to have raised interest to do the work! Sorry for my pessimism but I doubt that this thread will really make anyone step forward this time I'd love to be told otherwise! As said, it has fallen in forgeteness, but then, since developers cna now do this for their packages, maybe some of them will like this and step forward ? So, with such an announcement, everyone wins Noone wins if noone likes to do the work, like I said before in this thread. It would just make us look even more awkward, I guess. I think the maintainers are responsible enough and care enough about their packages to do it themselves, i certainly would, if they can get past the frustration of having all their effort stalled in unstable because this or that packages current brokeness. the maintainer will be able to fix things in testing more easily I've I understand you correct it wouldn't be easy, for backporting fixes seldom is easy. No, it is just a matter of backporting the unstable package to testing dependencies and have it built in testing environment. It is not a full testing-security, but would at least make testing as secure as unstable is, and not orders of magintude less. But again, the RM has not commented on this plan, and has he has the ultimate decision on this, nothing happened. That said, since testing is becoming more and more in a releaseable shape, it may not be as important at it was previously. Friendly, Sven Luther
Re: debian-exim mailing list?
Hamish Moffatt [EMAIL PROTECTED] a tapoté : On Sun, May 25, 2003 at 11:03:36PM +0200, Josip Rodin wrote: I'm perplexed about the mailing list request about Exim. On one hand, exim is an important package, and there are already ample precedents like debian-apache, debian-ssh and debian-tetex-maint; but on the other hand, there's alioth.debian.org which allows for easier creation and maintenance of per-package mailing lists. What do others think? I'd prefer that we didn't migrate everything to alioth as the easy way out, but I don't have any good reasons for that preference. Maybe it means that preference is not so good. :) I'm not at all familiar with alioth but it seems to be pretty comparable to Savannah, which I know well. The most complicated thing in Savannah was, IMHO, the migration of the GNU projects over Savannah. Because you had to deal with 340 way to do a same thing. According to me, it works better when the migration is plainly done - and correctly done, which means it does not suppress legitimate ways to do things. For instance, to manage SSH access, it way way easier to have everybody getting access via ssh or kerberos. But aside from that, it's great to let projects admins giving write access to someone by themselves than asking everybody to send a mail to [EMAIL PROTECTED] to get an access, to wait 3 week, to waste someone time. Creating a mailing list per package is surely irrelevant. But if people can create a subproject on alioth, they'll get the freedom to create such mailing-list without wasting time of other people. If they think it's needed, as DD, IMHO, they should be trusted. And since it's automated, it's completely harmless. In the worst case, the mailing list will be unused, which does not consume bandwith, harddisk or time - so which is not a real issue. -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
(no subject)
how can i make my own profile
Re: Bug#190302: Misusage of changelog!
Hi! On Mon, May 26, 2003 at 08:12:51AM -0500, Luca - De Whiskey's - De Vitis wrote: On Mon, May 26, 2003 at 02:45:16PM +0200, Josip Rodin wrote: Yes, but there's still no bloody point in making the submitter hunt around for information that the maintainer already knows and for which it takes them full 10 seconds per bug to list (15 if they type very slowly). Submitter receive a mail from bts which include the message that opened the bug: what should he hunt for exactly? There are people other than submitter, maintainer and upstream ... Example: 1. detect bug 2. run reportbug 3. sees, other person was faster and reported bug 42. 4. wait for new version 5. read changlog 6. what the heck was bug 42, was it mine ? Or do you expect everbody to file duplicate bugs or subscribe to existing bugs ? BYtE Philipp -- Philipp Matthias Hahn [EMAIL PROTECTED] GPG/PGP: 9A540E39 @ keyrings.debian.org
Re: Bug#190302: Misusage of changelog!
* Luca - De Whiskey's - De Vitis [EMAIL PROTECTED] [2003-05-26 13:12]: Submitter receive a mail from bts which include the message that opened the bug: what should he hunt for exactly? Not only does the mail from bts _not_ include the message (like you were told by others already), also other people reading the changelog might be interested in it. I for my part am. Is it really asked for too much to write _what_ is fixed? I rather thought this must be common sense So long! Alfie -- ohne speicher, tastatur, mouse, pladde, monitor, also nur die Hardware... -- _DeadBull_ in #debian.de pgp1I18Nks3HM.pgp Description: PGP signature
Re: Bug#194550: ITP: libemail-mime-encodings-perl -- A unified interface to MIME encoding and decoding
* Kai Henningsen [EMAIL PROTECTED] [2003-05-24 15:10]: * Package name: libemail-mime-encodings-perl Version : 1.0 Upstream Author : [EMAIL PROTECTED] * URL : http://search.cpan.org/CPAN/authors/id/S/SI/SIMON/Email-MIME-Encodings-1.0.tar.gz * License : Same as Perl. Description : A unified interface to MIME encoding and decoding Could you *kindly* add a long-description for the package, too? (for your other ITPs, too). Additional informations on what makes it more useful/better than libmailtools-perl in this special case wouldn't be wrong neither. Please, don't simply massfile ITPs without thinking on their impact and without any deeper informations Are you ITPing them because you need them for another package that depends on all of them? Do you think they will be used? What makes them good to have in the pool? So long! Alfie -- Linux. Auf die Verpackung kommt's nicht an! -- http://www.sloganizer.de/ pgpIdAttfeBDG.pgp Description: PGP signature
Re: Menu's 24 color policy
* Gustavo Noronha Silva [EMAIL PROTECTED] [2003-05-24 05:48]: Does this mean that the, IMHO brain-dead, 24-color limit has been droped? From menu's changelog: * No more require icons to use the colors from cmap.xpm. Closes:#193231, #175430, #192218, #97080 * No more install cmap.xpm. Closes:#172092 If you take a look at /usr/share/doc/menu/menu.txt.gz Section 3.4. it seems like that part was removed, yes. It was formerly point 3. in the list in that section (at least it is in the menu.txt.gz included in woody). HTH HAND! Alf*cool :)*ie -- #include signature.h pgpQsllx365do.pgp Description: PGP signature
Re: Bug#190302: Misusage of changelog!
On Mon, May 26, 2003 at 02:37:21PM +0100, Colin Watson wrote: Perhaps the submitter might like to know what was changed to fix the bug? I don't know about you, but I usually actually go and confirm the fix rather than blindly accepting it. I don't know you, but i usually actually go and read the upstream changelog to know haw it was fixed: if i'm not satisfied (that may happen), i go trough reading the source if i like. I'm not blind, i can read. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language.
Re: Bug#190302: Misusage of changelog!
On Mon, May 26, 2003 at 05:15:48PM +0200, Philipp Matthias Hahn wrote: Example: 1. detect bug 2. run reportbug 3. sees, other person was faster and reported bug 42. 4. wait for new version 5. read changlog 6. what the heck was bug 42, was it mine ? $ w3m http://bugs.debian.org/42 I'm not so bothered by writing 32 characters to know what was it. Off-line? Wait until on-line.. Do you know how not to bother maintainers? Ask to the apt-listchanges developers to add a feature to download bugs report for each bug closed in changelog. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language.
Re: Bug#190302: Misusage of changelog!
Hi, Am Mon, 2003-05-26 um 17.15 schrieb Philipp Matthias Hahn: Or do you expect everbody to file duplicate bugs or subscribe to existing bugs ? AFAIK you can't subscribe to single bugs (at least I was told that a few month ago). But this is one thing I'd like to change at debcamp in Oslo... Joachim -- Joachim Breitner e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189 Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?+ V? PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+* h! z? Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge. Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bug#190302: Misusage of changelog!
Luca - De Whiskey's - De Vitis [EMAIL PROTECTED] a tapoté : On Mon, May 26, 2003 at 05:15:48PM +0200, Philipp Matthias Hahn wrote: Example: 1. detect bug 2. run reportbug 3. sees, other person was faster and reported bug 42. 4. wait for new version 5. read changlog 6. what the heck was bug 42, was it mine ? $ w3m http://bugs.debian.org/42 I'm not so bothered by writing 32 characters to know what was it. Off-line? Wait until on-line.. Do you know how not to bother maintainers? Ask to the apt-listchanges developers to add a feature to download bugs report for each bug closed in changelog. Or maybe the maintainers can just spend 14 seconds to add a comment for each bug closed. Is that so complicated, so awful? This way, users can all be satisfied and you do not requires all user to spend 14 seconds each. -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Re: Bug#190302: Misusage of changelog!
Luca - De Whiskey's - De Vitis [EMAIL PROTECTED] wrote: On Mon, May 26, 2003 at 02:26:10PM +0200, Andreas Metzler wrote: Which does not help everybody else at all, who have just the meaningless changelog and are using apt-listchanges to read it before installation. I don't see even this: are you warried about grave bugs? Use apt-listbugs. BTW, you can always grep the upstream changelog from the deb file using dpkg-extract. No, I am not worried. I just want to know What was fixed in this release? without going online. I want debian/changelog to be a file with contents instead of links_to_fixed_bugreports_without_real_content.html It really is no effort to write * new upstream version: - escape and de-escape lines starting with a dot correctly (Closes: #178492) instead of * new upstream version. (Closes: #178492). cu andreas
Re: Help wanted for packaging postgresql application
On Mon, May 26, 2003 at 08:39:01AM +0200, Andreas Tille wrote: On Sun, 25 May 2003, Matt Zimmerman wrote: For python, you only need to declare Depends: python to ensure that python is installed and configured when your postinst runs. Are you sure that the python interpreter is working if python is just installed at the same time (apt-get run) in which GnuMed is installed. You just negated the predepends-question and thus I think you have thought about that when writing this answer. See section 7.2 of the policy manual. -- - mdz
Re: Bug#190302: Misusage of changelog!
On Mon, May 26, 2003 at 02:26:10PM +0200, Andreas Metzler wrote: On Mon, May 26, 2003 at 04:58:01AM -0500, Luca - De Whiskey's - De Vitis wrote: On Mon, May 26, 2003 at 11:16:51AM +0200, Gerfried Fuchs wrote: [...] Btw., your line for Upstream fix: closes: is not very helpful for the bug submitters neither. They'd have to check their records to see what this bug really was. Please add informations on what was fixed so it can be seen offline, too. I really don't see the point in this. Submitters always have a copy of their report, so they have evrything they need. [...] Which does not help everybody else at all, who have just the meaningless changelog and are using apt-listchanges to read it before installation. Putting just numbers in the changelog makes it list of links, that is completely useless if you are offline. Also, keep in mind that the bug submitter is NOT the only person who cares about the bug! Other people need and want to know what changes were made from version to version--this is the purpose of the changelog, not just a convenient way to close bugs! -- - mdz
Re: Bug#190302: Misusage of changelog!
On Mon, May 26, 2003 at 08:08:28AM -0500, Luca - De Whiskey's - De Vitis wrote: On Mon, May 26, 2003 at 02:26:10PM +0200, Andreas Metzler wrote: Which does not help everybody else at all, who have just the meaningless changelog and are using apt-listchanges to read it before installation. I don't see even this: are you warried about grave bugs? Use apt-listbugs. BTW, you can always grep the upstream changelog from the deb file using dpkg-extract. The purpose of a changelog is to _log_ the _changes_ which were made to a package, not just a bug-closing mechanism. -- - mdz
Re: Bug#190302: Misusage of changelog!
On Mon, May 26, 2003 at 11:04:42AM -0500, Luca - De Whiskey's - De Vitis wrote: On Mon, May 26, 2003 at 05:15:48PM +0200, Philipp Matthias Hahn wrote: Example: 1. detect bug 2. run reportbug 3. sees, other person was faster and reported bug 42. 4. wait for new version 5. read changlog 6. what the heck was bug 42, was it mine ? $ w3m http://bugs.debian.org/42 I'm not so bothered by writing 32 characters to know what was it. Off-line? Wait until on-line.. The bug report and the bug fix are separate things, and looking at the bug report often does not tell you how it was fixed. Changelog entries help users to deduce which package introduced a new bug, follow the history of a package to find out when a change was introduced. Looking back over a year's worth of versions by downloading bug reports from the BTS is not useful. A changelog entry which says only Closes: #bug is worthless; it is the same as leaving the changelog empty and closing the bug by hand. Do you know how not to bother maintainers? Ask to the apt-listchanges developers to add a feature to download bugs report for each bug closed in changelog. This is not a bother to maintainers, and no amount of enhancement to apt-listchanges relieves the maintainer's responsibility to document his changes. -- - mdz
Re: Bug#190302: Misusage of changelog!
Luca - De Whiskey's - De Vitis [EMAIL PROTECTED] writes: I really don't see the point in this. Submitters always have a copy of their report, so they have evrything they need. New upstream closes: #1, #2, #3 implyes an update of the upstream changelog file so it's worth of checking: listing changes already documented would be redundant and not so helpful. Not all software has a detailed changelog. Most of the time, changelogs simply state add feature foo or various bugfixes. You cannot ask upstream authors to refer to debian bug numbers in their changelogs (one of mine does that, but he's neat), nor do describe all bugs they close. Moreover, this allow users to browse the BTS to seek for more information in case they see a description of the fix looking like a problem they encounter. Cheers, Benjamin -- .''`. ; ;' ; Debian GNU/Linux | Benjamin Drieu `. `'http://www.debian.org/ | [EMAIL PROTECTED] `- pgpzmrLuNyKLy.pgp Description: PGP signature
Re: debian-exim mailing list?
On Mon, 26 May 2003 09:15:30 +0200, Andreas Metzler [EMAIL PROTECTED] wrote: It would be nice if there were documented mechanisms to move a list /painlessly/ from alioth to lists and vice versa, i.e. keeping the subscriber list and redirections for the old list addresses. I would like to see a possibility to import existing mailman archives as well. For a single case like exim4debian, it would probably be possible to manually move the archive subtree from the current mailman to alioth. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: Debian conference in the US?
On Sun, May 25, 2003 at 03:36:39PM -0400, Jaldhar H. Vyas wrote: On Sat, 24 May 2003, Adam Majer wrote: PS. Personally, I would prefer to travel for a DebConf in Cuba than in US. Really. So let me get this straight. Instead of a country where people are occasionally subject to bureaucratic hassles, (assuming Russell and Geordies' sources amount to anything more than innuendo which is not clear.) you would rather go to a place where the immigration policy consists of shooting people? No need for innuendo :). My sources are recent news reports of journalists covering a trade show who were jailed and removed from the country, in four cases out of six *after* they had been granted admission to the US. This is of interest to someone organizing a similar conference in the US. You'd at least want to warn journalists that they had best hire an immigration lawyer to ensure that their papers were in order. My preferences for a location for a DebConf are Vancouver and Seattle. Cuba would be a nice place for a vacation. I doubt I would be able to attend, although it would be a snap to organize a charter flight from Montreal or Toronto. Geordie.
Re: Bug#194705: ITP: yavipin -- daemon for creating secure tunnels
On Mon, May 26, 2003 at 08:42:52AM +0300, Tommi Virtanen wrote: On Sun, May 25, 2003 at 08:49:06PM -0500, Graham Wilson wrote: * Package name: yavipin How does it differ from OpenVPN? nothing, apparently. i will play with both in the next couple of days and see if i still think packaging yavipin is worth packaging. thanks for pointing openvpn out. -- gram pgppUhGVkk83z.pgp Description: PGP signature
Re: Bug#190302: Misusage of changelog!
On Mon, May 26, 2003 at 01:13:06PM -0400, Matt Zimmerman wrote: A changelog entry which says only Closes: #bug is worthless; it is the same as leaving the changelog empty and closing the bug by hand. We are not speaking of a generic line with a Closes: #1...; we are speaking of one of the most common chages: new upstream source close some bugs. I don't realy see the point in bothering the maintainer in further explanation of what happened: it is obvious and anyone has _all_ the information he may need to find it for himself. Should it ever happen to me, i would exactly think: I do spend my time maintaing, fixing upgrading the software, keep in touch with the upstream, forwarding report or any othern thing needed, so how do you now dare to bother me because i did not write a verbose, futil and redundant changelog entry? How could you tell me that writing what you wanted, would have taken me only few minutes? Are you teling me that what i do isn't enough? Your comment is only a waste of time for me that read the mail and for you who wrote it: you would surely have spent less time seeing it for yourself then reopening that bugs. This is not a bother to maintainers, and no amount of enhancement to apt-listchanges relieves the maintainer's responsibility to document his changes. I do think that complining because a maintainer worte New upstream closes: #1..., do not lead anywhere: it only bother the maintainer. Should i ever write such an entry, please don't waste your time and mine. Do you know what? I've more important things to do than spending my time reading the last, never ending thread, about the most stupid issue in the open source world. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language.
Re: Maintaining kernel source in sarge
On Mon, May 26, 2003 at 09:25:42PM +0200, Yann Dirson wrote: Matt wrote: The ideal solution would be to be able to share tarballs between source packages. Then, all of the kernel-image packages could be built as if they had a complete kernel source tree as their source package (which simplifies things a lot), and yet we would only need one such tarball in the archive. Of course, I have little idea how much work this would be to implement, except that it would touch a lot of different tools. The way I understand it was intended to work would be to have one single kernel-source-X-Y-Z package somewhat like what we have today, and having the various kernel-image-whatever build-depend on this kernel-source and any necessary kernel-patch packages. If this understanding is correct, I admit I don't see why the practice has diverged from this idea. The part you seem to have missed is the distinction between a source package and a binary package in what I wrote above. I do not think this is a practical idea to work toward at this time, however. -- - mdz
Re: X Strike Force SVN commit: rev 69 - branches/4.3.0/sid/debian
On Mon, May 26, 2003 at 08:48:23AM -0500, X Strike Force SVN Admin wrote:
Author: daniel
Date: 2003-05-26 08:48:12 -0500 (Mon, 26 May 2003)
New Revision: 69
Modified:
branches/4.3.0/sid/debian/control
Log:
Changed references to libstdc++5-dev to libstdc++5-dev | libstdc++-dev,
allowing
libstdc++5-3.3-dev to satisfy the dependency, and thus gcc3.2 to be deleted.
(closes: #194136)
This is a changelog-worthy commit, so please commit a change to the
changelog as part of the same changeset in the future.
More importantly, when this bug was first reported, several old timers
and I had a long conversation on OPN's #debian-devel channel about what
dependencies of -dev packages really mean. There are at least three
possibilities, and no Policy on which is controlling:
1) just what the package actually needs to install successfully (which
is usually nothing);
2) just packages containing header files referenced by the headers in
the package;
3) 2), plus -dev packages of any libraries that would necessarily be
linked against when people compile something linked with an object in
the -dev.
Questions for debian-{x,devel}:
1) Should libstdc++-dev dependencies be made artificially strict in
packages destined for sid so that it's harder for packages built
against, say, libstdc++3 to accidentally sneak in and start regressing
the C++ ABI transition progress?
2) Is libstdc++5-3.3 ABI-compatible with libstdc+5? Does the former
have any symbols that the latter lacks?
--
G. Branden Robinson| There is no gravity in space.
Debian GNU/Linux | Then how could astronauts walk
[EMAIL PROTECTED] | around on the Moon?
http://people.debian.org/~branden/ | Because they wore heavy boots.
pgp12OV0AWKaI.pgp
Description: PGP signature
Re: Debian-IN
Jaldhar H. Vyas wrote: Now that GNOME (via pango) and KDE (via the upcoming Qt 3.2.0) have viable support, I wonder if there is any interest in a sub-project for increasing I have only noticed Tamil support so far, at least in KDE and GNOME. Do I need to get any packages at all to enable the Devnagri languages like Hindi and Marathi. If so, I would be grateful if you could list them. It would be super cool to have KDE running in Hindi like my other friends who run it in their native languages (Portugese, French etc.) -- Harshwardhan Nagaonkar Electrical Engineering Sysop Brigham Young University, UT-84602
Re: Maintaining kernel source in sarge
Matt wrote: The ideal solution would be to be able to share tarballs between source packages. Then, all of the kernel-image packages could be built as if they had a complete kernel source tree as their source package (which simplifies things a lot), and yet we would only need one such tarball in the archive. Of course, I have little idea how much work this would be to implement, except that it would touch a lot of different tools. The way I understand it was intended to work would be to have one single kernel-source-X-Y-Z package somewhat like what we have today, and having the various kernel-image-whatever build-depend on this kernel-source and any necessary kernel-patch packages. If this understanding is correct, I admit I don't see why the practice has diverged from this idea. -- Yann Dirson[EMAIL PROTECTED] |Why make M$-Bill richer richer ? Debian-related: [EMAIL PROTECTED] | Support Debian GNU/Linux: Pro:[EMAIL PROTECTED] | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check http://www.debian.org/
Re: Maintaining kernel source in sarge
Matt wrote: It would be a significant gain if kernel modules could always be built against kernel-headers, without requiring full kernel-source. Since recently there are also kernel-build packages, which appear to be made precisely for that. I take it to mean the kernel-headers packages have proven deficient in some way, but I probably missed many things - I am even under the impression their construction is not even done by make-kpkg itself. Could someone elaborate on that ? (Herbert ? Manoj ?) Regards, -- Yann Dirson[EMAIL PROTECTED] |Why make M$-Bill richer richer ? Debian-related: [EMAIL PROTECTED] | Support Debian GNU/Linux: Pro:[EMAIL PROTECTED] | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check http://www.debian.org/
Re: Debian-IN
On Mon, 26 May 2003, Harshwardhan Nagaonkar wrote: I have only noticed Tamil support so far, at least in KDE and GNOME. Do I need to get any packages at all to enable the Devnagri languages like Hindi and Marathi. If so, I would be grateful if you could list them. For GNOME check out www.indlinux.org. Their software as distributed is geared towards Red Hat but it should take little effort to Debianize it. (If you do, be sure to write down all the steps.) It would be super cool to have KDE running in Hindi like my other friends who run it in their native languages (Portugese, French etc.) The Debian maintainer said it might be some time before it is officially packaged so I went and made my own .debs of Qt 3.2.0 beta 1. I'll put them up somewhere public when I get home tonight. Using this instantly enables all KDE applications to use Indian languages though as you note the localization support is very meager at the moment. This is a place where Debian users could make a valuable contribution. My personal interests are Gujarati and Sanskrit. -- Jaldhar H. Vyas [EMAIL PROTECTED] La Salle Debain - http://www.braincells.com/debian/
Re: Bug#190302: Misusage of changelog!
On Mon, May 26, 2003 at 01:36:15PM -0500, Luca - De Whiskey's - De Vitis wrote: On Mon, May 26, 2003 at 01:13:06PM -0400, Matt Zimmerman wrote: A changelog entry which says only Closes: #bug is worthless; it is the same as leaving the changelog empty and closing the bug by hand. We are not speaking of a generic line with a Closes: #1...; we are speaking of one of the most common chages: new upstream source close some bugs. I don't realy see the point in bothering the maintainer in further explanation of what happened: it is obvious and anyone has _all_ the information he may need to find it for himself. It is _not_ obvious, and closes: #... gives no clue to someone reading the changelog what might have been changed. Internet access, knowledge of debbugs, etc. are not prerequisites for being able to make use of a changelog. Should it ever happen to me, i would exactly think: I do spend my time maintaing, fixing upgrading the software, keep in touch with the upstream, forwarding report or any othern thing needed, so how do you now dare to bother me because i did not write a verbose, futil and redundant changelog entry? I do not understand how anyone can complain so much over something which takes so little effort, and yet adds value to the package for users, other developers and future maintainers. How could you tell me that writing what you wanted, would have taken me only few minutes? Are you teling me that what i do isn't enough? Your comment is only a waste of time for me that read the mail and for you who wrote it: you would surely have spent less time seeing it for yourself then reopening that bugs. Clearly you have me confused with someone else. I didn't reopen any bugs. Do you know what? I've more important things to do than spending my time reading the last, never ending thread, about the most stupid issue in the open source world. For instance, documenting your changes. -- - mdz
Re: Maintaining kernel source in sarge
Herbert wrote: * The kernel-source binary contains all bug fixes as is. Guido raised a good point that if we separated the patches from the kernel-source, then users may miss out on the bug fixes. This is especially important in light of the current speed of upstream releases. * The pristine kernel-source is available in the binary archive. Many people have asked for this in the past and this makes it available in the form of a source tar ball plus a patch. On the other hand, I would find it somewhat non-intuitive that the pristine source would only be available as the result of the application of a patch - and I tend to see that as an indication that it'd be more logical the other way round, with a pristine tarball and a real diff. We could get around Guido's point mentionned above by having a list of default patches to apply, which would by default contain the debian patch. Additionally, with things done this way, we're not even forced to update the whole kernel-source-2.4.20 seven times or more, we just have to update kernel-source-debian-2.4.20, which I believe would be good for the health of our network pipes. Regards, -- Yann Dirson[EMAIL PROTECTED] |Why make M$-Bill richer richer ? Debian-related: [EMAIL PROTECTED] | Support Debian GNU/Linux: Pro:[EMAIL PROTECTED] | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check http://www.debian.org/
Re: Bug#190302: Misusage of changelog!
* Matt Zimmerman [EMAIL PROTECTED] [030526 21:41]: On Mon, May 26, 2003 at 01:13:06PM -0400, Matt Zimmerman wrote: A changelog entry which says only Closes: #bug is worthless; it is the same as leaving the changelog empty and closing the bug by hand. We are not speaking of a generic line with a Closes: #1...; we are speaking of one of the most common chages: new upstream source close some bugs. [...] It is _not_ obvious, and closes: #... gives no clue to someone reading the changelog what might have been changed. Internet access, knowledge of debbugs, etc. are not prerequisites for being able to make use of a changelog. Then why do you limit your critic to the bug closed. Which bugs are closed are often the least interisting item of a new version. While I agree a New version is quite a short changelog entry, and most likely would be better if describing the new version, upstream changes have quite often much things changed. And I'd rather prefer more important changes described there, than that one specific bug was fixed. In this situation there is little to do about the bug otherwise, than closing the bug with a message, that this was fixed upstream and this version was uploaded. And the mail generated when putting a (closed:# ...) after a changelog entry describes this with nice words and with much less chance to make additional errors. Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Re: Maintaining kernel source in sarge
Arnd wrote: Ok, but I still would love to see single patches instead of one big patch containing all the common stuff. You can't really avoid situations where you want a patch on all architectures except one or two. This may be either because a patch breaks on one architecture (which should be of course be fixed, but you might not want to rebuild all kernels and modules on all other architectures because of it), or because the same fix is contained both in the debian collection and in the patch set published by the upstream arch kernel maintainer. I'm not sure if dh-kpatches already solves this problem, but it should be possible to add. If you mean, whether it can handle something like Architecture: !ia64, !hppa, well, not yet, although it could be done. But that would mean stopping the use of make-kpkg-level architecture support, just like it does not use make-kpkg-level kernel-version support. Although that may not look like a big deal, that seems to show that at some time a redesign of the interface between make-kpkg and the patches themselves would be a good idea. Regards, -- Yann Dirson[EMAIL PROTECTED] |Why make M$-Bill richer richer ? Debian-related: [EMAIL PROTECTED] | Support Debian GNU/Linux: Pro:[EMAIL PROTECTED] | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check http://www.debian.org/
Re: Maintaining kernel source in sarge
Matt wrote: The part you seem to have missed is the distinction between a source package and a binary package in what I wrote above. Not completely, although the time between reading and answering did not help me to be 100% clear with this :) I do not think this is a practical idea to work toward at this time, however. Yes, a new generation of source packages is needed, but if we could settle the kernel-packaging issue without this, that would at least help to get it running for sarge... Regards, -- Yann Dirson[EMAIL PROTECTED] |Why make M$-Bill richer richer ? Debian-related: [EMAIL PROTECTED] | Support Debian GNU/Linux: Pro:[EMAIL PROTECTED] | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check http://www.debian.org/
Re: Bug#190302: Misusage of changelog!
Em Mon, 26 May 2003 04:58:01 -0500, Luca - De Whiskey's - De Vitis [EMAIL PROTECTED] escreveu: Btw., your line for Upstream fix: closes: is not very helpful for the bug submitters neither. They'd have to check their records to see what this bug really was. Please add informations on what was fixed so it can be seen offline, too. I really don't see the point in this. Submitters always have a copy of their report, so they have evrything they need. New upstream closes: #1, #2, #3 implyes an update of the upstream changelog file so it's worth of checking: listing changes already documented would be redundant and not so helpful. It's very helpful to read nice comments on what is fixed when apt-listchanges sends me email with the debian changelogs... []s! -- [EMAIL PROTECTED]: Gustavo Noronha http://people.debian.org/~kov Debian: http://www.debian.org * http://www.debian-br.org Dúvidas sobre o Debian? Visite o Rau-Tu: http://rautu.cipsga.org.br
Re: X Strike Force SVN commit: rev 69 - branches/4.3.0/sid/debian
Branden Robinson writes:
Questions for debian-{x,devel}:
1) Should libstdc++-dev dependencies be made artificially strict in
packages destined for sid so that it's harder for packages built
against, say, libstdc++3 to accidentally sneak in and start regressing
the C++ ABI transition progress?
A dependency on the libstdc++-dev package is not (yet) needed, as
every new major version of gcc comes with a new libstdc++XXX-dev
package. Maybe it's better to depend on g++ (= 3:3.3-1) or a specific
g++ version if yoou need it. I'll file a report on build-essential to
tighten this dependency.
2) Is libstdc++5-3.3 ABI-compatible with libstdc+5? Does the former
have any symbols that the latter lacks?
Yes. No (modulo bugs). You can check this by comparing
/usr/share/doc/libstdc++5-dev/README.libstdc++5-baseline
and
/usr/share/doc/libstdc++5-3.3-dev/README.libstdc++5-3.3-baseline
Matthias
Re: Bug#194550: ITP: libemail-mime-encodings-perl -- A unified interfa
[EMAIL PROTECTED] (Gerfried Fuchs) wrote on 26.05.03 in [EMAIL PROTECTED]: Please, don't simply massfile ITPs without thinking on their impact and without any deeper informations Please don't assume someone jasn't thought about something just because you haven't been personally informed about every detail. As for the long descriptions, I really don't see what the use is in an ITP. The packages will of course have them. MfG Kai
Re: Maintaining kernel source in sarge
On Sun, May 25, 2003 at 11:00:34AM +1000, Herbert Xu wrote: But the pristine kernel source and the Debian patch are already available to the architecture maintainers: apt-get --tar-only source kernel-source-2.4.xx apt-get --diff-only source kernel-source-2.4.xx So I don't think having a kernel-patch-debian by itself is of any value to the merging process. It also doesn't solve the problem that a new kernel-patch-debian may break the building of old kernel-image packages. The diff for kernel-source-xx contains more than just the Debian-specific changes to the source; for example, it contains the debian/ directory. Also, source packages are much less straightforward to work with than binary packages. For example, they cannot be used in dependency relationships. If the current system works fine for the kernel package maintainers, it is, of course, not my place to say how it should be done. I'll leave this to the people doing the work. There is also the suggestion of a complete break down of all Debian changes should be made available. Unfortunately that is simply unmaintainable and unusable as the number of changes grows as the dependencies between the patches are complex. A breakdown meaning separate patches, right? Some maintainers manage to do this, but I agree that it is definitely more work than maintaining a unified tree. I think perhaps we could find a middle ground. We can keep kernel-source as it is with all the patches applied. In addition to that, we can have a kernel-patch-debian package which depends on the kernel-source of the same upstream version containing patches that will take the kernel-source to the following source trees: [...] This approach has the following benefits: * The kernel-source binary contains all bug fixes as is. Guido raised a good point that if we separated the patches from the kernel-source, then users may miss out on the bug fixes. This is especially important in light of the current speed of upstream releases. I agree; simply untarring /usr/src/kernel-source... should give most users what they expect. * The pristine kernel-source is available in the binary archive. Many people have asked for this in the past and this makes it available in the form of a source tar ball plus a patch. * Per-arch kernel-image will no longer be made unbuildable by new kernel-source updates. This has always been a problem for those architectures using the main kernel-source archive. * The incremental patches should ease the merging process of those architectures that wish to incoporate Debian changes. * The incremental patches should also allow people to get only the updated kernel-patch packages if they wish. All definite benefits. The one thing which seems to be missing is to ensure that the arch-specific kernels do not miss out on important fixes (such as security) to the main kernel source tree. -- - mdz
Re: security in testing
Gerfried == Gerfried Fuchs [EMAIL PROTECTED] writes: Gerfried * Sven Luther [EMAIL PROTECTED] [2003-05-16 Gerfried 13:33]: Such a package should be as close to possible to the version actually in testing, and not depend on packages and/or versions that are not yet in testing. Gerfried So, you request more or less that every developer Gerfried should backport fixes themself from the usual new Gerfried upstream version that fixes the problem (and mostly Gerfried always have new features too) to the version in testing, Gerfried which might even be older than just one upstream Gerfried release, due to usual holdups in the transition. It Gerfried sounds like you like to have every developer be able to Gerfried do what the security team does. That requires much skill Gerfried -- much more than most of us possess! I'd actually hope that you would be capable of doing this sort of back porting for any package you maintain. You should certainly be doing this for packages in stable, giving the security team tested patches, rather than having them do the job of maintaining your packages for you. Sure, that's an ideal. And perhaps you don't have these skills yet and are still working on gaining significant skill with your packages and with the languages they are written in. If so, then you should look for co-maintainers who do have the necessary skill sets to provide security updates for your packages. Even if you completely ignore testing security, anything you can do to reduce the work load on the security team will mean that Debian is less behind on publishing security updates and will better help us serve our users. --Sam
Re: X Strike Force SVN commit: rev 69 - branches/4.3.0/sid/debian
On Mon, May 26, 2003 at 01:54:57PM -0500, Branden Robinson wrote: 1) Should libstdc++-dev dependencies be made artificially strict in packages destined for sid so that it's harder for packages built against, say, libstdc++3 to accidentally sneak in and start regressing the C++ ABI transition progress? Well, this isn't a problem for buildds, because I made libstdc++5-dev the preference. 2) Is libstdc++5-3.3 ABI-compatible with libstdc+5? Does the former have any symbols that the latter lacks? I *believe* it's completely ABI-compatible, but I could be wrong. -- Daniel Stone [EMAIL PROTECTED] [EMAIL PROTECTED] KDE: Konquering a desktop near you - http://www.kde.org pgphpDyejfWsS.pgp Description: PGP signature
Re: Maintaining kernel source in sarge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 26 May 2003 22:20, Yann Dirson wrote: If you mean, whether it can handle something like Architecture: !ia64, !hppa, well, not yet, although it could be done. But that would mean stopping the use of make-kpkg-level architecture support, just like it does not use make-kpkg-level kernel-version support. Actually, I was thinking of a different concept with a 'Replaces: tag, something like: | Patch-name: Debian base patch | Patch-id: debian | Architecture: all | Kernel-version: 2.4.20 | Depends: ptrace, isdnbonding, binfmtmisc, ethernetpadding, ... | Patch-name: Pre-patch 2.4.21-pre7 | Patch-id: patch-2.4.21-pre7 | Architecture: all | Kernel-version: 2.4.20 | Replaces: ptrace, ethernetpadding | Patch-name: AMD64 CVS snapshot | Patch-id: amd64-20030417 | Architecture: i386, amd64 | Kernel-version: 2.4.20 | Depends: debian, patch-2.4.21-pre7, simicsfs | Replaces: aic7xxx Although that may not look like a big deal, that seems to show that at some time a redesign of the interface between make-kpkg and the patches themselves would be a good idea. Yes, in my amd64 kernel-patch package, the first thing I did was introducing an additional layer to make that interface more flexible. I'll probably change it to use dh-kpatches, but I wasn't aware of it when I made the package. Do you think that make-kpkg and dh-kpatches could/should be merged, making the dh-kpatches information evaluated by make-kpkg if available, or do we need changes beyond that? Arnd -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+0oLg5t5GS2LDRf4RAk9sAJ9mXkdo1Ecktj5vjtN+0xsjY8LXTgCdExGU kwPFctma5TMf2Qv4anlB854= =uGo9 -END PGP SIGNATURE-
Re: Maintaining kernel source in sarge
On Mon, May 26, 2003 at 10:00:06PM +0200, Yann Dirson wrote:
We could get around Guido's point mentionned above by having a list of
default patches to apply, which would by default contain the debian
patch.
Yes, but then the problem is that unsuspecting users could be
building kernels using the kernel-source package thinking that
it contained all the security fixes.
I believe that distributing a binary package that may contain
known security problems is a very serious problem.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: X Strike Force SVN commit: rev 69 - branches/4.3.0/sid/debian
Daniel Stone writes: On Mon, May 26, 2003 at 01:54:57PM -0500, Branden Robinson wrote: 1) Should libstdc++-dev dependencies be made artificially strict in packages destined for sid so that it's harder for packages built against, say, libstdc++3 to accidentally sneak in and start regressing the C++ ABI transition progress? Well, this isn't a problem for buildds, because I made libstdc++5-dev the preference. for this to work, you have to explicitely build using g++-3.2 (build dependency and setting of CC/CXX). using g++ means building with libstdc++5-3.3-dev.
Re: X Strike Force SVN commit: rev 69 - branches/4.3.0/sid/debian
On Monday, May 26, 2003, at 02:54 PM, Branden Robinson wrote: what dependencies of -dev packages really mean. There are at least three possibilities, and no Policy on which is controlling: 1) just what the package actually needs to install successfully (which is usually nothing); 2) just packages containing header files referenced by the headers in the package; 3) 2), plus -dev packages of any libraries that would necessarily be linked against when people compile something linked with an object in the -dev. I'm a very strong believer that any header file which requires another header file should include it. I think that most Debian developers are with me on this issue; the old-style make the client include what I need headers are losing favour, I think. So, given this idea of making header files include what they need, it seems pretty natural to extend that idea to -dev packages. Thus, -dev packages should depend on what they need to work; this includes all header files they include. I imagine a dpkg-shlibdeps workalike could be created for this purpose if it became an issue. w.r.t point 3, I think it's pretty natural to extend earlier ideas to symbols needed at link time. In most cases this will probably have a fairly large intersection with the set of packages depended upon for their headers. I think it makes sense to Depend upon -dev packages which are required (most of the time?) when building a program using the library in question. The idea is to make -dev packages as useful as possible, so a person doesn't get a rude shock when they have to install a whole whack of other packages just to get their GLU-using programs to compile.
Bug#194812: ITP: libsendmail-pmilter-perl --
Package: wnpp Severity: wishlist [Note: The package has already been uploaded. Sorry about this.] * Package name: libsendmail-pmilter-perl Version : 0.4.0-1 Upstream Author : Todd Vierling [EMAIL PROTECTED] * URL or Web page : http://www.duh.org/pmilter * License : BSD Description : A Perl implementation of the Sendmail Milter protocol PMilter is an attempt to reimplement Sendmail's milter (mail filter) protocol in pure Perl. There are many reasons for this, including independence from Sendmail's libmilter, as well as freedom from POSIX threads (helps stability for Perl filters), etc. . Most of PMilter's Sendmail::Milter interface is a clone of the frontend functions in PMilter::Server. However, this compatibility package also includes some methods specific to the Sendmail MTA, which are deliberately not included in PMilter::Server.
Bug#194813: ITP: libsendmail-milter-perl --
Package: wnpp Severity: wishlist [Note: The package has already been uploaded. Sorry about this.] * Package name: libsendmail-milter-perl Version : 0.18-1 Upstream Author : Charles Ying [EMAIL PROTECTED] * URL or Web page : http://sendmail-milter.sourceforge.net/ * License : Sendmail Description : Interface to Sendmail's Mail Filter API Sendmail::Milter is a Perl extension to sendmail's Mail Filter API (Milter). . With this module, Perl callbacks can be defined and registered with the Milter engine. This module calls those perl callbacks using interpreters from a threaded persistent interpreter pool.
Re: Very uneven distribution of packages per maintainer
On Sat, May 24, 2003 at 09:15:39AM -0400, Ben Collins wrote: Even that is little indicator. I know folks who's job has nothing to do with Debian, but they do more work than people who are paid to work on Debian. It's all about motivation, and no person is doing anything wrong. It's a personal choice how much time and energy you devote to Debian. As long as that number isn't zero, then you are welcome to stay. Amen. Michael
Bug#194816: ITP: linksysmon -- Tool for monitoring Linksys routers
Package: wnpp Version: unavailable; reported 2003-05-26 Severity: wishlist * Package name: linksysmon Version : 1.1.2 Upstream Author : Michael J. Wohlgemuth [EMAIL PROTECTED] * URL : http://woogie.net/linksysmon/ * License : GPL Description : Tool for monitoring Linksys routers Tool for monitoring Linksys BEFSR41 and BEFSR11 routers. It accepts log mesages from the Linksys, and logs the messages to /var/log/linksys.log. It handles the standard activity logs, as well as the secret extended logging, and can handle logs from multiple routers. When using extended logging, it can detect external IP address changes (if using either DHCP or PPPOE) and can call an external program to process the change. -- System Information: Debian Release: testing/unstable Architecture: i386
Re: LDAP adduser/deluser
On Mon, 26 May 2003, Zed Pobre wrote: I have written code (in Perl) that replicates much of the behaviour of adduser and deluser (down to command-line switch compatibility), but modifies user information in a LDAP database instead of flat files like /etc/passwd. Erm, did you check over the open adduser bugs? There was a request for this some time ago, and I've come up with patches to integrate all of the necessary functionality into LDAP. I'm just giving it some time for people to test and report breakages before I give the patch to Roland for inclusion in the official adduser package. It's nowhere near complete (it is missing most notably group handling, system account handling, documentation, config file parsing, and sanity checking on option combinations), but the portions that actually add and delete users are finished and in some cases actually work better than the original adduser, so I'm contemplating making it Could you elaborate on what ways yours works better than the original adduser? I'm sure Roland would love to hear about functionality improvements, and I'd certainly be keen for any improvements to the LDAP-specific code... public as it is and inviting patches. I could make an entirely separate package out of it (ldapusertools, or some such), but I thought I'd ask here first if the project would rather have me work with either the adduser or ldap-utils folks to merge these scripts It's an adduser thing, best to keep it there. There's no need for totally separate adduser and adduser-ldap programs - the two co-exist quite nicely. -- --- #include disclaimer.h Matthew Palmer, Geek In Residence http://ieee.uow.edu.au/~mjp16
Re: Bug#190302: Misusage of changelog!
I demand that Andreas Metzler may or may not have written... [snip] It really is no effort to write * new upstream version: - escape and de-escape lines starting with a dot correctly (Closes: #178492) No argument there from me. instead of * new upstream version. (Closes: #178492). No argument there either from me, so long as the bug being closed is about there being a new upstream version, and the uploaded package is that or a newer version. -- | Darren Salt | linux (or ds) at | nr. Ashington, | woody, sarge, | youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | URL:http://www.youmustbejoking.demon.co.uk/progs.packages.html Your computer account is overdrawn. Please reauthorise.
Re: Quando criar um pacote pacote-doc?
Rodrigo Tadeu Claro [EMAIL PROTECTED] writes: Andei lendo uma discussão na debian-devel sobre com que tamanho uma documentação deve virar um pacote e pelo que eu entendi, não se chegou a uma conclusão de tamanho exato, é tudo uma questão de bom senso. No debian-reference, também fica na questão do bom-senso. Na opinião de vocês um diretório com 250K de html deve virar um pacote? Sim, na minha opinião deve virar um pacote pois, torna-se muito mais fácil para a manutenção do mesmo. Já que este terá um mantenedor! Acho que houve um engano por minha ou por sua parte. Eu entendi que seria: Quando uma documentacao de um programa deve tornar-se um pacote separado? Isso seria equivalente ao samba nao ter o samba-doc. Gostaria de aproveitar para informar à todos que contatei o atual mantenedor do Debian GNU/Linux Dictionary e informei-o que estou interessado em manter essa documentação. Seria a pessoa que estaria centralizando as informações enviadas pelos nossos colaboradores. Opa! Legal sua iniciativa. Realmente gostei! :-) Gostaria de dizer que estou a disposição ok! Tive um retorno positivo de Oliver (mantenedor do DDP) uma vez que o mesmo está afastado à 4 anos do projeto. Rodrigo, Se voce tiver autorizacao eu me proponho a ser o sponsor para o pacote se este for complacente com a policy, claro ;-) []s -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio -
Re: Quando criar um pacote pacote-doc?
Em Mon, 26 May 2003 11:32:45 -0300 Otavio Salvador [EMAIL PROTECTED] escreveu: Acho que houve um engano por minha ou por sua parte. Eu entendi que seria: Quando uma documentacao de um programa deve tornar-se um pacote separado? Isso seria equivalente ao samba nao ter o samba-doc. A minha dúvida é essa. O pacote no qual estou trabalhando tem 250K de documentação, não compactada. O James Troup barrou um pacote-doc que tinha 500k. Ele achou pequeno e que deveria ser fornecido junto com o pacote original. O Maçan me disse no IRC que, somente deve virar pacote-doc se tiver mais de 600k. Se ninguém se posicionar contra, vou empacotar tudo junto mesmo. Abraços, -- -- Michelle Ribeiro Consultoria em Software Livre Campinas - SP
