Re: Dogme05: Team Maintenance
Quoting Florian Weimer ([EMAIL PROTECTED]): > Please keep in mind that responsible maintainers do not depend on > unmaintained services such as alioth.debian.org. If you must use it, > make sure that you make periodic copies of archives stored on costa. Well, I'm afraid that I'm not a responsible maintainer, then:-) So is the d-i team, the testing security team and so on. Maybe alioth maintenance does not fit your own admin quality reference system. Then, I see a few solutions to this: -contribute to alioth system administration -make constructive suggestions (constructive suggestions are argumented suggestions and sometimes accept that people do not agree with what you suggest) -do not use it -build a concurrent collaborative development environment and convince people that it's better than alioth As far as I know, Alioth maintenance is handled by the relevant people on their free time, as a volunteer work (just like all work we do in this project). Thus they deserve some respect for the time they invest in it. *Even* if you do not agree with their technical choices or method of work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing /etc/hotplug.d/ support
On Thu, Aug 25, 2005 at 02:31:14PM +0200, Marco d'Itri wrote: > On Aug 25, Thiemo Seufer <[EMAIL PROTECTED]> wrote: > > All those popular mips WLAN devices use still 2.4 kernels, some people > > started to port some of them to 2.6, but the main hindrance are binary > > only (and thus 2.4 only) drivers. > It's not like they are already supported by debian anyway, then. > Is there anything else? > Can somebody comment on the alpha and m68k situations? The current lack of 2.6 support in the installer for alpha shouldn't really be an obstacle, but 2.6 doesn't currently work on my own alpha so I haven't been particularly motivated to fix up d-i to use it until I can usefully test it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: making developer location from ldap public?
Jesus Climent wrote: > At least in Spain and Finland, publishing such information without the consent > of the person would be against the law. True. In fact, our db.d.o database would, as it currently stands, be illegal in Finland, if it were located in Finland. (It'd be fairly easy to fix, actually. The main thing that is missing is formal documentation of the database as required by the law.) signature.asc Description: OpenPGP digital signature
Re: making developer location from ldap public?
On Thu, Aug 25, 2005 at 07:40:23PM -0700, Thomas Bushnell BSG wrote: > > I suppose this is what I mean by "we are talking about Debian > Developers". We're not keeping personal information on customers, or > people with a peripheral relationship; these are *members* of the > organization. It is still personal information, and being private has to be guarded according to the law. At least in Spain and Finland, publishing such information without the consent of the person would be against the law. In Spain, we at Hispalinux have to copy the information the members send into a book and a disconnected database (called member book). -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.6.12|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 I never drink ... wine. --Dracula (Dracula) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dogme05: Team Maintenance
Florian, Le vendredi 26 août 2005 à 11:20 +0200, Florian Weimer a écrit : > Please keep in mind that responsible maintainers do not depend on > unmaintained services such as alioth.debian.org. YOU MUST STOP YOUR ANTI-ALIOTH CAMPAIGN ! As an alioth admin, I feel attacked each time I read one of your mail and it's getting incredingly annoying. > If you must use it, make sure that you make periodic copies of > archives stored on costa. That's a reasonable advice in any case... Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Freexian : des développeurs Debian au service des entreprises http://www.freexian.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help in gcc-4.0.x transition issue
Andreas Tille wrote: > /home/tillea/debian-maintain/packages/arb/arb-0.0.20050506/INCLUDE/awt_canvas.hxx:67: > error: 'AWT_canvas' has not been declared > make[2]: *** [AW_preset.o] Error 1 > make[2]: *** Waiting for unfinished jobs > > > I guess it is a really small problem for people with C++ knowledge and thus > I hope to get a quick answer here. The question is whether friend class AWT_canvas; is a declaration of class AWT_canvas. People used to think it is, but (now) think it only declares it as a friend. So you need to add class AWT_canvas; at the beginning of the header file. Regards, Martin P.S. Disclaimer: the explanation is from memory only, and the solution is not tested. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#325202: ITP: libsql-abstract-limit-perl -- portable LIMIT emulation
Package: wnpp Severity: wishlist Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]> * Package name: libsql-abstract-limit-perl Version : 0.033 Upstream Author : David Baird, <[EMAIL PROTECTED]> * URL : http://search.cpan.org/~davebaird/SQL-Abstract-Limit-0.1/ * License : GPL, Artistic Description : portable LIMIT emulation Portability layer for LIMIT emulation. One of this modules which are needed for use other modules. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-11-amd64-k8 Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) (ignored: LC_ALL set to pl_PL) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: vancouver revisited
Joey Hess <[EMAIL PROTECTED]> writes: > Riku Voipio wrote: >> I've tired using Debian on nfsroot/nbd on a Linksys wap54g. Unfortunatly >> I ran out of ram often, and swapping over nfs patches have disappeared >> into the time, while swapping over NBD gained some serious lockups.. >> An usb-slot seems to be necessary with current memory requirements of >> a fully featured distribution. > > Yes, a 16 mb machine like the wap54g is a bit low on memory. I've not > had any problems running debian on my 32mb WRT54GS, including running > aptitude and the like. My current dream machine is the WL-500G Deluxe, > which has 32 mb ram and 2 usb2 ports. And you didn't install locales. Installing that eats up 64Mb ram easily. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Wednesday 24 August 2005 17.15, Miquel van Smoorenburg wrote: > Make sure you use only POSIX features when doing this. I think > "grep -o" is a GNU extension, FreeBSD doesn't have it for example. Doesn't the 'only POSIX' apply to the shell code only? At least, shouldn't it be judged on a per-tool basis? While awk is (was?) usually mawk on Debian, and not gawk, I don't think anybody uses a BSD grep on their Debian system. Please don't standardise on a minimal future set only for the corner case that somebody cripples his system beyond every reassonable limit. The 'POSIX shell' rule is here for a reason: there are people with /bin/sh being not bash. For other tools, this rule can be relaxed, imho. cheers -- vbi -- Ich kenne niemanden, der so oft Recht hat wie ich. -- Arno Schmidt pgpiwgHowvhar.pgp Description: PGP signature
Re: Debian shared libs use far more memory than required
Stephane Chauveau wrote: > Thiemo Seufer wrote: > > > >The whole thing sounds like the result of hiding _GLOBAL_OFFSET_TABLE_ > >and _PROCEDURE_LINKAGE_TABLE_ in newer binutils. > > > > I assume that you mean that the problem the problem is solved by using > the latest binutils (and not that it was introduceed by them). That was my guess, but Kurt says the binutils version was the same in both cases. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian shared libs use far more memory than required
On Fri, Aug 26, 2005 at 10:25:15AM +0200, Thiemo Seufer wrote: > > I checked the content of the .data section in libgtk and the > > unexpected data appears to be composed of all exported > > symbols aligned to a multiple of 16. Obviously a symbol > > table of some kind. > > The whole thing sounds like the result of hiding _GLOBAL_OFFSET_TABLE_ > and _PROCEDURE_LINKAGE_TABLE_ in newer binutils. Just for reference, from the buildd log of the package in question: Toolchain package versions: libc6-dev_2.3.2.ds1-22 linux-kernel-headers_2.6.13+0rc3-1 gcc-4.0_4.0.1-3 g++-4.0_4.0.1-3 binutils_2.16.1-2 libstdc++6-4.0-dev_4.0.1-3 libstdc++6_4.0.1-3 And binutils_2.16.1-2 is still the latest version. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Debian shared libs use far more memory than required
Thiemo Seufer wrote: The whole thing sounds like the result of hiding _GLOBAL_OFFSET_TABLE_ and _PROCEDURE_LINKAGE_TABLE_ in newer binutils. I assume that you mean that the problem the problem is solved by using the latest binutils (and not that it was introduceed by them). Is there an easy way to ugrapde the binutils used by the build system? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: vancouver revisited
On Tue, 23 Aug 2005, Riku Voipio wrote: > Hi Joey, > > Your response was very much what I needed to hear. I'll have to retract > most of my worries. > > On Mon, Aug 22, 2005 at 07:20:07PM -0400, Joey Hess wrote: > > - A personal interest shared by me, tbm, and taggart is to get Debian > >working on the various types of cheap mips wireless access points that > >are now available in the < $100 price range, many of which now sport a > >usb interface, so should be able to run a real Debian system. I imagine > >it will be useful to have preinstalled images to load into the flash > >and/or a USB drive, but that users will also find it useful to install > >Debian on these from scratch using an installer they are comfortable > >with from installing their PCs. > > I've tired using Debian on nfsroot/nbd on a Linksys wap54g. Unfortunatly > I ran out of ram often, and swapping over nfs patches have disappeared > into the time, while swapping over NBD gained some serious lockups.. > An usb-slot seems to be necessary with current memory requirements of > a fully featured distribution. gradall:/tmp/s# apt-cache show kernel-patch-nfs-swap Description: patch to linux to enable swapping over nfs This kernel patch modifies linux, so that it can have swapfiles that reside in an nfs filesystem. This is useful for machines that boot from nfs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Documentation of alioth?
=?ISO-8859-1?Q?Rapha=EBl?= Hertzog writes... > I know Wichert is a bit disappointed because despite all the > money/sponsors we have, we're waiting for more than a year for a new > machine. The main problems appears to be DSA who must give an approval > that they're willing to admin the machine before we can decide to buy > it/accept the donation... and since DSA are always overwhelmed with more > urgent issues (new ftpmaster and so on), we're getting nowhere. Actually the problem is that HP promised hardware for alioth but before we could order it a company spending freeze happened. I'm glad to report that it looks like we're going to be able to order things again and it will get ordered soon. This still means we're at least a month from having the hardware arrive, assembled, installed, shipped to a hosting sponsor, and ready to transition. Then the transition will take some time too... Sorry for the delay, thanks for you patience. -- Matt Taggart [EMAIL PROTECTED] aka [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[no subject]
Frederik Minnaert Verantwoordelijke Ruwbouw Tel 09/272.50.14 Fax 09/272.50.10 gsm 0496/59.50.14 [EMAIL PROTECTED] oledata.mso Description: oledata.mso
Bug#325173: ITP: queuegraph -- a RRDtool frontend for Postfix queue-statistics
Package: wnpp Severity: wishlist Owner: "Conall O'Brien" <[EMAIL PROTECTED]> * Package name: queuegraph Version : x.y.z Upstream Author : Ralf Hildebrandt <[EMAIL PROTECTED]> * URL : http://www.stahl.bau.tu-bs.de/~hildeb/postfix/queuegraph/ * License : GPL Description : a RRDtool frontend for Postfix queue-statistics Queuegraph is a simple mail statistics RRDtool frontend for Postfix that produces daily, weekly, monthly and yearly graphs of Postfix's active, deferred, incoming and bounce queues. It is designed to compliment mailgraph, which is already packaged and accepted into Debian -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-386 Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#325164: ITP: docbook-css -- Cascading Stylesheet for DocBook/XML
Package: wnpp Severity: wishlist Owner: "W. Borgert" <[EMAIL PROTECTED]> Package name: docbook-css Version : 0.4 Upstream Author : David Holroyd URL : http://www.badgers-in-foil.co.uk/projects/docbook-css/ License : "free to use/modify/distribute, no warranty" Description : view DocBook/XML files styled in the web browser This Cascading Stylesheet allows you to directly view a styled XML document in software that supports XML styled with CSS2 (e.g. a recent Mozilla browser). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making developer location from ldap public?
On Fri, 2005-08-26 at 13:50 +0200, Javier Fernández-Sanguino Peña wrote: > On Fri, Aug 26, 2005 at 01:54:16AM -0500, Ron Johnson wrote: [snip] > the paragraph above. And when I'm talking about GIS data I'm not refering to > the information in db.debian.org on developers, I'm talking about a GIS > database with latitude/longitude coordinates of regions and cities > all over the world. Ah, ok. -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." Brian W. Kernighan signature.asc Description: This is a digitally signed message part
Re: Documentation of alioth?
On Fri, Aug 26, 2005 at 12:51:41PM +0200, Florian Weimer wrote: > Some developers have a few EUR on their bank accounts and could buy > hardware for the project, too. We speak about server hardware. > But I fail to see how more machines make system administration easier. > I'd expect that additional machines put only more load on our various > administration teams, not less. Debian currently have 3 powerpc machines, one powerstack 2 and 2 dual g4. They can easily replaced with on the openpower machines. So the count drops from 3 to 2 if some backup is wanted. Bastian -- Time is fluid ... like a river with currents, eddies, backwash. -- Spock, "The City on the Edge of Forever", stardate 3134.0 signature.asc Description: Digital signature
[EMAIL PROTECTED]: Debian/Ubuntu keyring maintainer issues]
- Forwarded message from Jason Harris <[EMAIL PROTECTED]> - From: Jason Harris <[EMAIL PROTECTED]> To: Marco Nenciarini <[EMAIL PROTECTED]>, sks-devel@nongnu.org Cc: Jason Harris <[EMAIL PROTECTED]> Subject: Debian/Ubuntu keyring maintainer issues (was: Re: [Sks-devel] Sks and mailsync) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at prato.linux.it On Mon, Aug 22, 2005 at 08:39:28PM +0200, Marco Nenciarini wrote: > I think we must help pks network to remain in sync most as possible > (but without flooding it). Last I checked, all (active) SKS servers were doing their part except keyserver.ubuntu.com, which still doesn't send mailsyncs to any onak/OpenPKSD/pks keyservers: http://keyserver.ubuntu.com:11371/pks/lookup?op=stats Also, a Debian keyring: rsync://keyring.debian.org/keyrings/keyrings/debian-keyring.pgp has the (in)famous problem (w/GPG 1.4.2): gpg: mpi larger than indicated length (2 bytes) gpg: keyring_get_keyblock: read error: invalid packet gpg: error reading keyblock: invalid keyring and can't be (armored and) fed through keyserver(s) with the rest of the Debian keyrings, as I occasionally do because it always turns up new data. Finally, pushing these keyrings through my SKS keyserver just now resulted in 78 hash updates, meaning that despite ongoing _queries_ from keyring.debian.org (via lwp-trivial/1.41, to subkeys.pgp.net), nobody is properly pushing these updates _to_ the well-synchronized keyservers. IIRC, the same person is responsible for all these issues. -- Jason Harris | NIC: JH329, PGP: This _is_ PGP-signed, isn't it? [EMAIL PROTECTED] _|_ web: http://keyserver.kjsl.com/~jharris/ Got photons? (TM), (C) 2004 - End forwarded message - -- - |Marco Nenciarini| Debian/GNU Linux Developer - Plug Member | | [EMAIL PROTECTED] | http://www.prato.linux.it/~mnencia | - Key fingerprint = FED9 69C7 9E67 21F5 7D95 5270 6864 730D F095 E5E4 signature.asc Description: Digital signature
Re: making developer location from ldap public?
Quoting Javier Fern�ndez-Sanguino Pe�a <[EMAIL PROTECTED]>: > presents themselves and suggest meeting for a beer. They don't walk to > your house, knock on your door and say "Hi! I just got your coordinates > from db.debian.org, wanna meet and keysign?". And I wouldn't want that. I do not understand this discussion. Why on earth is someone so interested in the public availability of DDs location? This would only make sense when cross-connecting with other things, like belief, gender, sexual preferences and phantasies etc. Are those fields of db.debian.org already public or not? Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Documentation of alioth?
Le vendredi 26 août 2005 à 12:51 +0200, Florian Weimer a écrit : > * Bastian Blank: > > > On Fri, Aug 26, 2005 at 12:23:14PM +0200, Raphaël Hertzog wrote: > >> Maybe a brief status of the "hardware donations" people would be nice ? > > > > IBM loaned 2 OpenPower machines for Debian but noone wants them. Okay, > > they have one problem, only 4x 73 GB disk space. > > Some developers have a few EUR on their bank accounts and could buy > hardware for the project, too. > > But I fail to see how more machines make system administration easier. > I'd expect that additional machines put only more load on our various > administration teams, not less. In our case we want to merge costa/haydn on a single machine. And that's even more important since Gforge 4.5 has a subversion module. It would be bad if we have SVN repo on two different machines... while access to all repo is handled by the same way (alioth projects). Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Freexian : des développeurs Debian au service des entreprises http://www.freexian.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Documentation of alioth?
Le vendredi 26 août 2005 à 11:26 +0200, Florian Weimer a écrit : > * Raphaël Hertzog: > > > Le dimanche 07 août 2005 à 11:39 +0200, Florian Weimer a écrit : > >> What's the benefit of diagnosing the problem if it isn't fixed? > > > > It lets people with the required privileges fix the problem without > > having to investigate it first. > > For the record: The bug hasn't been fixed yet. Fwiw, the bug is now fixed. I prodded Wichert once more and it got resolved. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making developer location from ldap public?
On Fri, Aug 26, 2005 at 09:59:37AM +0200, Robert Lemmen wrote: > On Thu, Aug 25, 2005 at 07:42:12PM -0700, Thomas Bushnell BSG wrote: > > I don't understand why making it possible to find fellow Debian > > Developers this way should in effect make the information public. > > > > Why not simply hide it behind the password screen? > > because it's not only targeted at debian developers, but also at new > maintainers, contributors who are not even in the nm queue (there are > many of them), and even interested users or people who want to become > more involved People who want to get more involved usually first target a local LUG (linux user group) or attend free software events or whatever to meet people involved in FLOSS (including Debian developers). They might even use a i18n mailing list (there are some localised debian-devel- lists), presents themselves and suggest meeting for a beer. They don't walk to your house, knock on your door and say "Hi! I just got your coordinates from db.debian.org, wanna meet and keysign?". For what I know, not even Debian developers traveling use db.debian.org to get the coordinates of people near by and contact them through e-mail. They send a [VAC] announcement to debian-private and suggest people in the area contact them to arrange a meeting. Regards Javier signature.asc Description: Digital signature
Re: making developer location from ldap public?
On Fri, Aug 26, 2005 at 01:54:16AM -0500, Ron Johnson wrote: > > Pondering: Can you easily easily convert latitude/longitude into > > those "regions"? Do _you_ have a very good GIS available? You might > > be able to do it for some countries (US, probably) but not for most > > other DDs. Or have I missed something and all this GIS data is publicly > > available (and free) somewhere? > > Yes, but us non-d-ds don't have access to it. Sorry, can't parse that. 'Yes' to what? There were three questions in the paragraph above. And when I'm talking about GIS data I'm not refering to the information in db.debian.org on developers, I'm talking about a GIS database with latitude/longitude coordinates of regions and cities all over the world. Regards Javier signature.asc Description: Digital signature
Re: making developer location from ldap public?
On Fri, Aug 26, 2005 at 08:34:22AM +0200, Petter Reinholdtsen wrote: > [Javier Fernández-Sanguino Peña] > > Any free GIS anyone? > > Lots of Free GIS software around. Check out > http://pkg-grass.alioth.debian.org/cgi-bin/wiki.pl>. :) I was actually talking about the GIS data, not the GIS software itself. You can probably map long/lat coordinates to the most proximate city (if you have the long/lat of cities worldwide) but mapping to regions worldwide (i.e. a province or a state) requires a log of GIS data I'm sure is not current _and_ freely available somewhere. But then again, somebody might surprise me with an effective solution. Regards Javier signature.asc Description: Digital signature
Re: better init.d/* : who carres ?
On Thu, Aug 25, 2005 at 12:17:56PM -0300, Henrique de Moraes Holschuh wrote: > On Thu, 25 Aug 2005, Marc Chantreux wrote: > > that is a point which surprise me : i understand the dash for a posix > > and lightweight attitude but why use bash as "modern shell" ? why not > > perl or zsh (which are both more powerfull) ? > > Well, as long as you don't start using stuff that breaks often, or that > loads a ton of crap dynamically, or (even worse) is in /usr instead of /bin > or /sbin... > > Note that using dash is probably MUCH faster than perl. I don't know about > zsh. Well, writing scripts that use /bin/sh or perl means that the init script will run without any dependencies on optional packages. zsh is Priority: optional... And while dash is also optional, all *correctly* written /bin/sh scripts should work with dash too. Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: get-orig-source target in debian/rules
On Friday 26 August 2005 14:03, George Danchev wrote: > Hello, > > I would like to ask if it is a good idea to have some code in cdbs > implementing the get-orig-source target which could then be included in > debian/rules. Over ;-) Marc Haber was extremely fast pointing to the right package The code for doing so has already been invented, see dpatch-get-origtargz from the dpatch package. Greetings Marc -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
get-orig-source target in debian/rules
Hello,
I would like to ask if it is a good idea to have some code in cdbs
implementing the get-orig-source target which could then be included in
debian/rules.
Rationale:
* Since it is a common target I think it could be provided by cdbs or
any similar package and should not be reinvented every now and then.
* This target is optional, but providing it if possible is a good idea
as
said in Policy 4.8.
* Could be handy for the pkg-* projects keeping *only* their debian/
directories on a SCM to get the orig-source ... just a target away.
The bad thing is that it (cdbs) should depend on some fetching tool like wget
or probably http or ftp methods (/usr/lib/apt/methods) of apt could be used as
downloaders to fetch the tarballs ?
Here is a sample illustrating /*not tested and probably insane*/ code.
These variables should be set in debian/rules
( if any of these is not set we can stop ?:
# debuild expects to find orig tarball in ../
UDIR = ..
UPATH=url://host/dir
UFILE=file1.tar.gz
UFILE_ORIG=file1.orig.tar.gz
MD5TRU=af8f830baf081e3a1cf39e9299cf1b86
MD5CUR=`md5sum $(UDIR)/$(UFILE) | awk '{print $$1}'`
This target could be provided by some cdbs file and included in debian/rules:
get-orig-source:
if [ ! -f $(UDIR)/$(UFILE_ORIG) ] ; then \
wget -O $(UDIR)/$(UFILE_ORIG) $(UPATH)/$(UFILE) ; \
else \
echo "Upstream source tarball have been already downloaded" ; \
fi
if [ "$(MD5CUR)" != "$(MD5TRU)" ] ; then \
echo "md5sum mismatch!" ; \
false ; \
else \
echo "md5sum is ok!" ; \
fi
Again, I'm not sure if cdbs is the best place to provide this target, and if
not which other package could be considered as well.
P.S. Also sent to cdbs ML.
--
pub 4096R/0E4BD0AB 2003-03-18
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Documentation of alioth?
* Bastian Blank: > On Fri, Aug 26, 2005 at 12:23:14PM +0200, Raphaël Hertzog wrote: >> Maybe a brief status of the "hardware donations" people would be nice ? > > IBM loaned 2 OpenPower machines for Debian but noone wants them. Okay, > they have one problem, only 4x 73 GB disk space. Some developers have a few EUR on their bank accounts and could buy hardware for the project, too. But I fail to see how more machines make system administration easier. I'd expect that additional machines put only more load on our various administration teams, not less.
Re: Documentation of alioth?
On Fri, Aug 26, 2005 at 12:23:14PM +0200, Raphaël Hertzog wrote: > Maybe a brief status of the "hardware donations" people would be nice ? IBM loaned 2 OpenPower machines for Debian but noone wants them. Okay, they have one problem, only 4x 73 GB disk space. Bastian -- Dammit Jim, I'm an actor, not a doctor. signature.asc Description: Digital signature
Re: Documentation of alioth?
Le vendredi 26 août 2005 à 12:04 +0200, Martin Schulze a écrit : > Hi Raphaël, Hi Joey, > I'm sorry, but I have to tell you that you're wrong in your assertion. I've been corrected by Wiggy on IRC too. Although what I said before was not invented, I've read part of it in #debian-devel in the mouth of Overfiend (Branden)... It looks like the actual problem is more lack of donors and the fact that Branden is not willing to spend money on it. Maybe a brief status of the "hardware donations" people would be nice ? > Also DSA does not have anything to do with ftpmaster work. The > ftpmaster people organise themselves on their own. Right, it's so easy to confuse with common people on the various teams ... :-) Cheers, PS: Good news, I actually have root rights now, I'll take some time this WE for treating the easy issues in the support request. -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Documentation of alioth?
Raphaël Hertzog wrote: > I know Wichert is a bit disappointed because despite all the > money/sponsors we have, we're waiting for more than a year for a new > machine. The main problems appears to be DSA who must give an approval > that they're willing to admin the machine before we can decide to buy > it/accept the donation... and since DSA are always overwhelmed with more > urgent issues (new ftpmaster and so on), we're getting nowhere. Hi Raphaël, I'm sorry, but I have to tell you that you're wrong in your assertion. All Alioth machines (currently haydn and costa) are not in the domain of DSA but of Wichert alone. The only active part DSA is taking in this is the export of Debian developer accounts to haydn. Also DSA does not have anything to do with ftpmaster work. The ftpmaster people organise themselves on their own. Regards, Joey -- WARNING: Do not execute! This call violates patent DE10108564. http://www.elug.de/projekte/patent-party/patente/DE10108564 wget -O patinfo-`date +"%Y%m%d"`.html http://patinfo.ffii.org/ Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#324179: ITP: quake3 -- a famous first person shooter by ID-Software
On Sat, 2005-08-20 at 20:16 +0200, Bastian Venthur wrote: > Package: wnpp > Severity: wishlist > Owner: Bastian Venthur <[EMAIL PROTECTED]> > > * Package name: quake3 > Version : x.y.z > Upstream Author : ID-Software > * URL : http://www.idsoftware.com/ > * License : GPL > Description : a famous first person shooter by ID-Software > > This is the GPL'ed version of id's famous first person shooter quake3. Note that this first release of Quake3 source is not fully GPL, it has a few issues, see the README and its nice license map. There is also no GPL data available right now. The GNU/Linux packager and maintainer at Id is 'TTimo'. He is a Debian user and will certainly have better answers about upstream mainenance and such things (for instance Id does have a forge for its GPL'ed tools). I'm CC'ing him. TTimo: for the record, here is the thread : http://lists.debian.org/debian-devel/2005/08/msg01042.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Documentation of alioth?
[ I keep the discussion because I want Wichert to read it ] Le vendredi 26 août 2005 à 11:26 +0200, Florian Weimer a écrit : > > It lets people with the required privileges fix the problem without > > having to investigate it first. > > For the record: The bug hasn't been fixed yet. > > > If life was that easy... please stop whining and see the reality. > > The reality is that alioth is unmaintained. > > > Many packages have easy to fix bugs that languishes ... > > Packages are NMUed if their breakage causes too much suffering. > > > it's the same with alioth. > > No, it's not. You are quite immune to pressure from your peer group > (or maybe you think your fellow developers aren't peers, I don't > know). > > > We appreciate any help... > > Oh, to cut the discussion short: Where can I apply for root access on > costa, so that I can fix the bug we are talking about? Wichert is root and edits /etc/sudoers on his liking. Even if I requested root rights several times, I only got rights to call the script to create SVN repo. I tried to do as much as possible on this issue, I've filed the required information in the support tracker, I reassigned the request to Wichert, increased the priorities and asked him to check his top-level support requests. I pestered him on IRC twice or thrice without results. Sorry, I can't do more. I know Wichert is a bit disappointed because despite all the money/sponsors we have, we're waiting for more than a year for a new machine. The main problems appears to be DSA who must give an approval that they're willing to admin the machine before we can decide to buy it/accept the donation... and since DSA are always overwhelmed with more urgent issues (new ftpmaster and so on), we're getting nowhere. Of course, that's not a reason to not act on the problems you indicated, but hey I want to give people a broader overview of what's happening. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Documentation of alioth?
* Raphaël Hertzog: > Le dimanche 07 août 2005 à 11:39 +0200, Florian Weimer a écrit : >> What's the benefit of diagnosing the problem if it isn't fixed? > > It lets people with the required privileges fix the problem without > having to investigate it first. For the record: The bug hasn't been fixed yet. > If life was that easy... please stop whining and see the reality. The reality is that alioth is unmaintained. > Many packages have easy to fix bugs that languishes ... Packages are NMUed if their breakage causes too much suffering. > it's the same with alioth. No, it's not. You are quite immune to pressure from your peer group (or maybe you think your fellow developers aren't peers, I don't know). > We appreciate any help... Oh, to cut the discussion short: Where can I apply for root access on costa, so that I can fix the bug we are talking about?
Re: Dogme05: Team Maintenance
* W. Borgert: > A fine way to do this, is by having a pkg- project at > alioth.debian.org. Please keep in mind that responsible maintainers do not depend on unmaintained services such as alioth.debian.org. If you must use it, make sure that you make periodic copies of archives stored on costa. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#322282: ITP: swapspace -- Dynamic swap space manager
On Thu, Aug 18, 2005 at 03:28:39AM -0500, Peter Samuelson wrote: > You've got it. That was the point of contention. The real objection Thanks for a lucid explanation, and my apologies for a late followup. > If you think your package really is only useful on Debian-like systems, > it may be ok to treat it as a debian-native package - that is, not to > bother releasing "upstream" tarballs but only Debian source packages > with tarballs in them. However, it sounds like your package really > could be useful on other Linux systems, in which case it'll make > everyone's workflow simpler in the long run to decouple the upstream > and Debian release processes. That makes sense. We really only care about the Debian packages here, but somebody else might want changes for e.g. a Fedora version. I've built it as a native package so far merely because it was enough to suit our needs and anying else was best left to someone more familiar with Debian packaging. From our point of view it will remain a Debian package with an option to install on other GNU/Linux platforms. That does not mean it has to be a real Debian-native package. I do see your point about territoriality. I would assume that some packaging changes that flowed logically from upstream changes, such as the recent deletion of the TODO file from the documentation, are not worth bothering the Debian maintainer about--better to make the change and be done with it. Conversely I'd trust the maintainer to make any changes that were valid for all systems, and apply good sense in doing so. I normally notify people when I modify their work, regardless of who owns the repository, to avoid not just unnecessary hard feelings but also merge conflicts and choices that the other would have made differently. What matters most on our end is the ability to roll up-to-date Debian packages during development--i.e. containing both the very latest working packaging and the source code we just modified--even if slight changes to the packaging are required just to keep things working. > And in the latter case, it doesn't make much sense to stick debian/ > inside the tarball, even if the Debian maintainer is on your same team. No problem there; once again, we have no intention of including a debian/ in any tarballs. It was only there so far because (1) the Debian tools generated tarballs with debian/ included, and (2) people might want to roll Debian packages for themselves. Otherwise, the only issue is as described above--that I'd like to have the packaging and the source code in the same repository to minimize communication latencies. Jeroen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian shared libs use far more memory than required
Stephane Chauveau wrote: > Thiemo Seufer wrote: > > >Andreas Barth wrote: > >[snip] > > > > > >>>DEBIAN PACKAGE FROM REPOSITORY: > >>>11 .rodata 000840cb 0021a180 0021a180 ... > >>>21 .data 000233c0 003f1d60 003f1d60 ... > >>> > >>>MY OWN RECOMPILED DEBIAN PACKAGE: > >>>11 .rodata 000a43ad 001f3180 001f3180 ... > >>>21 .data 0748 003f3460 003f3460 ... > >>> > >>>That's 0x0233c0-0x748 = 140KB moved from shared to non-shared > >>> > >>>140KB of non shared memory per GTK application is HUGE!!! > >>> > >>> > > > >Fortunately it is not as bad as it sounds iff the constant data is > >collated together in larger chunks. The kernel does copy-on-write, > >if a .data page is never written, the memory usage is effectively > >the same. > > > > > > I checked the content of the .data section in libgtk and the > unexpected data appears to be composed of all exported > symbols aligned to a multiple of 16. Obviously a symbol > table of some kind. The whole thing sounds like the result of hiding _GLOBAL_OFFSET_TABLE_ and _PROCEDURE_LINKAGE_TABLE_ in newer binutils. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making developer location from ldap public?
On Fri, Aug 26, 2005 at 08:32:32AM +0200, Javier Fernández-Sanguino Peña wrote: > Generally speaking, you can't turn something that everybody thought > it was private into a public thingy without asking them to confirm > that they don't mind it. And, no, not every DD will read this thread > so a field in the database saying "yes, make this public" is the _only_ > way to go if you want to go that way. ok, that's why i asked. obviously there are quite some people around who want their location to stay hidden from the general public while making it available to registered debian developers, so opt-in is the only way to go. thanks for the feedback, no reason to discuss this any further, i'll see if it's possible to implement it that way. cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: making developer location from ldap public?
On Fri, Aug 26, 2005 at 08:41:42AM +0200, Petter Reinholdtsen wrote: > There are ways to use this information without making the location > public. We could add a geo-location search field, and then show the > developers with geo-location closest to the point of interest, and > their distance to this location. This way the actual location of the > DDs are still not public, but you can easily find the DDs to contact > by searching for the position of the place you are visiting, and send > emails to the closest ones. as you can see from the prototype [0] (the only entries right now are in munich, germany) this is hwo it works, it never shows the exact location. BUT this DOES still disclose the real position as you can simply do multiple queries with different locations and do the maths. we will therefore change the system to round the locations in the database to half a degree (or so), so you only get rough answers in the sense of "in this city". [0] http://debian.semistable.com/geoloc.pl -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: making developer location from ldap public?
On Thu, Aug 25, 2005 at 07:42:12PM -0700, Thomas Bushnell BSG wrote: > I don't understand why making it possible to find fellow Debian > Developers this way should in effect make the information public. > > Why not simply hide it behind the password screen? because it's not only targeted at debian developers, but also at new maintainers, contributors who are not even in the nm queue (there are many of them), and even interested users or people who want to become more involved cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: better init.d/* : who carres ?
Henrique de Moraes Holschuh a écrit : Anyway, just make triple sure to never use anything from /usr in a script that otherwise only needs / to work. If you find anything like that, report it as a important (usually whatever it is starts after /usr is mounted) or grave (it starts befure /usr is mounted). yes! a can report some useless bashisms too ( the script can be dash compliant so). regards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making developer location from ldap public?
Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> writes: > Generally speaking, you can't turn something that everybody thought > it was private into a public thingy without asking them to confirm > that they don't mind it. And, no, not every DD will read this thread > so a field in the database saying "yes, make this public" is the _only_ > way to go if you want to go that way. Of course debian-devel is not adequate notification. But that's a separate question from whether opt-in is mandatory. As yet, however, I haven't seen any good reason for opening the information anyway. My address is on my public web page; but many peoples' is not.
Re: better init.d/* : who carres ?
Henrique de Moraes Holschuh a écrit : Note that using dash is probably MUCH faster than perl. I don't know about zsh. it's not always true : it just depends on your problems and solutions : write a dash script to open a lot of pipes between grep,sed,awk and other filters to treat a lot of files or long ones will require more ressources than lauchning perl, compiling perlscript and running it faster than all those filters. for init scripts, we can suppose you're almost always true. regards mc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making developer location from ldap public?
On Fri, 2005-08-26 at 08:41 +0200, Petter Reinholdtsen wrote: > [Robert Lemmen] > > db.debian.org contains (optional) fields for the location of each > > developer, an information which currently is only used to generate > > edwards's fancy maps. there are other potential uses for this, like > > making it possible to find fellow debian developers at some place that > > you are going to for business or a vacation, and inviting them to a > > drink and some keysigning. imho this would be pretty cool, but brings > > with it a small problem: it would in effect make that information > > public, in the moment it is only accessible to debian developers. > > [Thomas Bushnell] > > I don't understand why making it possible to find fellow Debian > > Developers this way should in effect make the information public. > > There are ways to use this information without making the location > public. We could add a geo-location search field, and then show the > developers with geo-location closest to the point of interest, and > their distance to this location. This way the actual location of the > DDs are still not public, but you can easily find the DDs to contact > by searching for the position of the place you are visiting, and send > emails to the closest ones. Like, "list all of the D-Ds within (the hard coded) 30km of the center of London". That way, the data is not passively sitting there waiting to be sucked in by Google, but must be actively queried by a human. Sounds good to me. > I believe mapserver is able to provide such search system, or > something based on grass, but have not tried it myself. > > And for the record, I am opposed to making my geo-location information > public, and will require answer no to an opt-in. Out of curiosity, why? You put your home address, phone number and even your cell phone number on your home page, which was trivial to find, and didn't even need a search engine. http://www.hungry.com/~pere/ -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. "Treaties, you see, are like girls and roses; they last while they last." Charles de Gaulle signature.asc Description: This is a digitally signed message part
Help in gcc-4.0.x transition issue
Hi, I tried to build arb packages (non-free) with gcc 4.0.1 (testing) and 4.0.2 (unstable) but failed. Upstream is currently busy and is not able to care for this issue in the time I plan a new upload. (This does not mean that upstream is dead but people are happy with gcc 4.0.0 so this problem is no big issue at the moment.) To start building arb you need the following small patch: --- Makefile.orig 2005-05-06 12:21:05.0 +0200 +++ Makefile2005-08-26 08:05:14.0 +0200 @@ -91,7 +91,7 @@ ALLOWED_GCC_295_VERSIONS=2.95.3 # 2.95.4 is supposed to work, but not known to be tested yet ALLOWED_GCC_3xx_VERSIONS=3.2 3.3.1 3.3.3 3.3.4 3.3.5 3.4.0 3.4.2 3.4.3 -ALLOWED_GCC_4xx_VERSIONS=4.0.0 +ALLOWED_GCC_4xx_VERSIONS=4.0.0 4.0.1 4.0.2 ALLOWED_GCC_VERSIONS=$(ALLOWED_GCC_295_VERSIONS) $(ALLOWED_GCC_3xx_VERSIONS) $(ALLOWED_GCC_4xx_VERSIONS) GCC=gcc If I use testing with gcc 4.0.1 or my unstable chroot with 4.0.2 the build ends with: ... g++ -W -Wall -DLINUX -DHAVE_BOOL -pipe -DNO_REGEXPR -DGNU -fPIC -O -DNDEBUG -DARB_OPENGL -DFAKE_VTAB_PTR=char -D_ARB_WINDOW -c AW_status.cxx -I. -I/home/tillea/debian-maintain/packages/arb/arb-0.0.20050506/INCLUDE -I/usr/X11R6/include g++ -W -Wall -DLINUX -DHAVE_BOOL -pipe -DNO_REGEXPR -DGNU -fPIC -O -DNDEBUG -DARB_OPENGL -DFAKE_VTAB_PTR=char -D_ARB_WINDOW -c AW_preset.cxx -I. -I/home/tillea/debian-maintain/packages/arb/arb-0.0.20050506/INCLUDE -I/usr/X11R6/include AW_status.cxx:85: warning: non-local variable ' aw_stg' uses anonymous type AW_status.cxx:1355: warning: non-local variable ' aw_help_global' uses anonymous type /home/tillea/debian-maintain/packages/arb/arb-0.0.20050506/INCLUDE/awt_canvas.hxx:67: error: 'AWT_canvas' has not been declared make[2]: *** [AW_preset.o] Error 1 make[2]: *** Waiting for unfinished jobs I guess it is a really small problem for people with C++ knowledge and thus I hope to get a quick answer here. Sorry for the inconvience Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
