Re: conditional dependency?
[Stephen Gran] I really hope that's not true. There are many useful use cases for static linking when you're building for constrained or otherwise not quite sane environments that IMHO we should continue to support. Since in the main it's not that hard to do the right thing, it's also of limited value to discourage it. It is worth to note that glibc do not work properly with static linking. All functions using PAM and NSS do not work, so binaries using such functions will fail when presented with incompatible modules on disk. This normally make static linking useless to make sure binaries keep working independently of the shared libraries available on disk. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Configuration Packaging System
Timothy G Abbott tabbott at MIT.EDU writes: On Mon, 25 Feb 2008, Frank Küster wrote: Uh, you can dpkg-divert conffiles, but not generally configuration files, since many won't even be known to dpkg. I must admit I'm a bit sceptical about a proposal on configuration, written by someone who lets this important distinction slip by... No, I really meant configuration files. While our system certainly applies to all conffiles, it also applies to various other classes of files: But in these cases you can't use dpkg-divert. 3) Scripts that are not marked as conffiles but which cannot be configured in any way other than by modifying the script. If those scripts live below /etc, they definitely should be marked as conffiles. If they live elsewhere, no package should edit them. I probably should have said this explicitly earlier, but our system is currently only an 80% solution, because it cannot override any package's configuration file handling system that does not preserve manual changes. Such a package has a RC bug anyway. It turns out that these are fairly rare, and can be handled with some annoyance (e.g. releasing a new version of our configuration package whenever a new release of such a package comes out, so that the configuration package wins). Of file a bug... So, yes, our system uses both symlinks and dpkg-divert. Ah, I understand. I think here you have a much larger problem than with the small number of RC-buggy packages that don't keep manual changes: Larger because I fear there are more packages with such problems, because less people are aware that it is a problem, and maybe even because there might be some debate whether respecting a symlink state actually is required by policy. One idea [...] would be for dpkg to run postinst scripts in a special environment that rewrites filenames according to the diversion database I would rather contemplate a new interface for configuration packages, something like a hook which has to be executed by each postinst script and allows the configuration package to bring its settings into effect. If you want to be able to remove configuration packages, the original file needs to be preserved somehow, but the current dpkg-divert is not sufficient for this: Consider someone installing the configuration package in stable+0, then upgrading to stable+1 and keeping it, and then upgrading to stable+2 and subsequently removing the configuration package. Any special code in the maintainer scripts which dealt with incompatible conf(iguration )file changes in the stable-to-stable+1 upgrade is likely to have been removed by now, so the old, incompatible, file from stable+0 will be used after the removal, and the package is in a broken state. Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
On Tue, 2008-02-26 at 08:22 +0100, martin f krafft wrote: also sprach Anibal Avelar [EMAIL PROTECTED] [2008.02.26.0805 +0100]: http://fixxxer.cc/images/mascot/Penguin_Fat.gif http://fixxxer.cc/images/mascot/Jhas.png http://fixxxer.cc/images/mascot/little_pinguin.jpg http://fixxxer.cc/images/mascot/calimero.jpg http://fixxxer.cc/images/mascot/Akubuntu.png I will vehemently oppose to anything penguin-related for Debian. Debian != Linux. What about a bug... Bugs are our pets : we take care of them. Pixar's A Bug's life : http://www.pixar.com/featurefilms/abl/tale.html http://imdb.com/media/rm1614715136/tt0114709 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
also sprach Franklin PIAT [EMAIL PROTECTED] [2008.02.26.0936 +0100]: What about a bug... Bugs are our pets : we take care of them. I guess I just repeat myself when I question why we need to join the free software zoo. Is it hip? Are we hip? What's the gain? Why bother? A fluffy pillow with a swirl on it sounds like a good idea, for when you're feeling down and need some FOSS lovin'. A fluff animal, on the other hand, is for kids. Debian is not. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems n3tg0d has /usr/bin/emacs been put into /etc/shells yet? :P digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
On Tue, Feb 26, 2008 at 5:56 PM, martin f krafft [EMAIL PROTECTED] wrote: A fluff animal, on the other hand, is for kids. Debian is not. Debian is for everyone, kids included! -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
also sprach Paul Wise [EMAIL PROTECTED] [2008.02.26.1007 +0100]: A fluff animal, on the other hand, is for kids. Debian is not. Debian is for everyone, kids included! Yes. What I meant to say was: a stuffed animal might belittle Debian. The Swirl is way more mature, albeit perceived less cool. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems the condition of perfection is idleness. the aim of perfection is youth. -- oscar wilde digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
On ti, 2008-02-26 at 10:15 +0100, martin f krafft wrote: also sprach Paul Wise [EMAIL PROTECTED] [2008.02.26.1007 +0100]: A fluff animal, on the other hand, is for kids. Debian is not. Debian is for everyone, kids included! Yes. What I meant to say was: a stuffed animal might belittle Debian. The Swirl is way more mature, albeit perceived less cool. I don't think a stuff Tux belittles Linux. I don't think a stuffed animal would belittle Debian. (A stuffed rubber chicken as a Debian mascot might be wholly inappropriate, though.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
also sprach Lars Wirzenius [EMAIL PROTECTED] [2008.02.26.1018 +0100]: I don't think a stuff Tux belittles Linux. I don't think a stuffed animal would belittle Debian. Fine. I have other arguments: it would make it yet another FOSS project with an animal mascot. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems i'd rather be riding a high speed tractor with a beer on my lap, and a six pack of girls next to me. digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
On ti, 2008-02-26 at 10:20 +0100, martin f krafft wrote: also sprach Lars Wirzenius [EMAIL PROTECTED] [2008.02.26.1018 +0100]: I don't think a stuff Tux belittles Linux. I don't think a stuffed animal would belittle Debian. Fine. I have other arguments: it would make it yet another FOSS project with an animal mascot. I'm not advocating stuffed animals for Debian mascots. I'm fine with a pillow, a tie, and a tutu. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467549: ITP: simutrans-pak64 -- data set for simutrans
Package: wnpp Severity: wishlist Owner: Ansgar Burchardt [EMAIL PROTECTED] * Package name: simutrans-pak64 Version : 99.18 (from SVN) Upstream Author : Simutrans Team [EMAIL PROTECTED] * URL : http://www.simutrans.com/ * License : Artistic License, GPL Programming Lang: none Description : data set for Simutrans This package provides the PAK64 data set for Simutrans (ITP #437627). Simutrans is a free transportation simulator: The player operates a transportation company and has to transport goods and passengers between factories and different cities. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Practical solutions to: the new style mass tirage of bugs
On Mon, Feb 25, 2008 at 06:02:59AM +0100, Lucas Nussbaum wrote: For many users of other bug tracking systems such as bugzilla, the meaning of priority vs severity is totally unclear. I don't think that it would be a good idea to impose such a thing to all packages by default. Well, you don't need to impose it. It can have a default value and developers can change it. Personally I do find priority in bugzilla unclear wrt severity, but only because the user which is submitting the bug is required to set it. That's totally dumb, a priority is something only for the developers which want to organize their, well, priorities. As Don pointed, it is relatively easy to emulate priorities using I agree that is possible to emulate priorities with what we already have. But expressivity does not necessarily make things straightforward. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: conditional dependency?
On Mon, Feb 25, 2008, Steve Langasek wrote: Conventionally, library -dev packages do depend on other -dev packages that they require for static linking; and certainly, tools like pkg-config and libtool (and other home-grown foo-config scripts) tend to encourage this behavior. Nowadays, with a proper .pc file I would argue that this could be reduced to a Recommends. Cannot be reduced: pkg-config needs to be able to go down Requires.private modules to compute Cflags and hence you have to Depend on Requires.private modules (as if they are missing, pkg-config calls simply fail). -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
On Mon, Feb 25, 2008, Nikita V. Youshchenko wrote: And what if somebody will try to link statically? Your -config binary should gain a --static flag to distinguish between the two uses. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Practical solutions to: the new style mass tirage of bugs
On Sun, Feb 24, 2008 at 11:58:49AM -0800, Don Armstrong wrote: It almost sounds like you want a user setable severity-like field. That could be implemented, but the problem is that it's far less flexible than usertags because it would only have a single value. (Note that I did not ask for that, I just followed the line of thought I've read on the post I replied to. But indeed yes, I think a priority field, which is severity-like would be a good idea, of course the value space would be different, can even just be a number or something such.) Yes, it would be less flexible, but what meaning has a priority field with multiple values? I think that such a field would be meaningful only to sort upon it, and go looking for sorting of multiple valued fields seems to be looking for trouble to me. In fact, assuming the assignment to usercategories was done properly, it wouldn't matter if a bug had multiple priority tags, as a bug that had the higest tag would be separated from the other tags even if it still had a lower tag. Sounds like hackish, doesn't it? Anyhow, another point for preferring a non-user priority tag is that you don't need to set a user, which IMO makes a lot easier to deal with bug reports since you don't risk to forget what the right user for the tag/category you're setting is (which frequently happens to me). Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: conditional dependency?
This one time, at band camp, Petter Reinholdtsen said: [Stephen Gran] I really hope that's not true. There are many useful use cases for static linking when you're building for constrained or otherwise not quite sane environments that IMHO we should continue to support. Since in the main it's not that hard to do the right thing, it's also of limited value to discourage it. It is worth to note that glibc do not work properly with static linking. All functions using PAM and NSS do not work, so binaries using such functions will fail when presented with incompatible modules on disk. That's pretty much always been the case with at least NSS, by design. That being said, the interface to nss hasn't particularly changed in so long I'm not sure this is an issue, in practice. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version
Hello Raphael, Raphael Geissert [EMAIL PROTECTED] wrote: Jörg Sommer [EMAIL PROTECTED] jed (U) This is a SVN snapshot. There's no release of it. I fail to see how to point to a changelog file in a SVN repository. How should I handle this situation? Bye, Jörg. -- Prof. in der Mathematikvorlesung zu einem vergessenen φ in der Gleichung: „Klein‐φ macht auch Mist.“ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
On Tue, Feb 26, 2008 at 12:03:06PM +, Stephen Gran wrote: This one time, at band camp, Petter Reinholdtsen said: [Stephen Gran] I really hope that's not true. There are many useful use cases for static linking when you're building for constrained or otherwise not quite sane environments that IMHO we should continue to support. Since in the main it's not that hard to do the right thing, it's also of limited value to discourage it. It is worth to note that glibc do not work properly with static linking. All functions using PAM and NSS do not work, so binaries using such functions will fail when presented with incompatible modules on disk. That's pretty much always been the case with at least NSS, by design. That being said, the interface to nss hasn't particularly changed in so long I'm not sure this is an issue, in practice. Broken glibc due to static linking is an issue at least weekly on embedded linux mailing lists (eg buildroot). ie it's still an issue. What are the constrained environments where you think static linking would be useful? I'm developing embedded systems and I prefer shared libraries - unless you have only one application using a particular library then you will save space. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Looking for co-maintainer for mercurial
On Tue, Feb 26, 2008 at 1:20 AM, Edward Allcutt [EMAIL PROTECTED] wrote: On Tue, Feb 26, 2008 at 12:05:46AM +, Stephen Gran wrote: This one time, at band camp, Aaron M. Ucko said: Julian Andres Klode [EMAIL PROTECTED] writes: BTW, I think that hg is now the only VCS package which is not maintained in its own VCS format. (or are there other packages, too?) $ apt-cache showsrc rcs | grep Vcs Vcs-Browser: http://git.debian.org/?p=users/rfrancoise/rcs.git Vcs-Git: git://git.debian.org/git/users/rfrancoise/rcs.git cvs is IIRC maintained in svn. So that would make hg the only VCS package maintained in a VCS inferior to itself? :P That's because hg-buildpackage is not really used much in Debian and also it seems noone is interested in it much, see also this bug or rather a wish: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448444 that I reported 4 months ago with no response at all. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On the subject of watchfiles (was Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version)
Is it worth investing much effort into debugging watch file issues? In my experience, watchfiles are seldom useful. There was the whole problem with getting at HTTPS URLs; the sourceforge workarounds (that broke); etc. One of the packages I maintain (deutex) does not have the latest upstream version linked to from a website (it's referenced in a mailing list post somewhere). I've read several other examples of situations (unpredictable version number schemes etc.) where it falls short. Also, if a package is being looked after by an active maintenance team, you'd hope that they would be aware that a new upstream version was available: in many cases you'd hope they were aware one was *due*, often with pre-releases in experimental to catch issues for the larger suites. If a package is not being looked after by an active maintenance team, there's a bug in the package maintenance (or the package should be on it's way out); which won't be solved by tweaking the watch file. -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On the subject of watchfiles (was Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version)
Hi Jon, On Tue, Feb 26, 2008 at 11:20 AM, Jon Dowland [EMAIL PROTECTED] wrote: Is it worth investing much effort into debugging watch file issues? In my experience, yes. I can cite the example of the perl group: 679 packages group maintained. You'll guess that there's no way in earth a small group of people can track such amount of packages manually. We heavily rely on the watchfiles for detecting new upstream releases, and the tool we use (http://pkg-perl.alioth.debian.org/cgi-bin/qareport.cgi) automates that for us. We go to great lengths to make every package have the correct watch information. Of course, we have luck, because CPAN (99% of our packages come from there, and we have only 4 unsolvable watch problems) is pretty well-behaving and consistent, compared to other upstreams. But chances are that watchfiles can be useful for the majority of people. -- Martín Ferrari
Re: Looking for co-maintainer for mercurial
Steve Gran wrote: This one time, at band camp, Aaron M. Ucko said: [migrating to -curiosa] Julian Andres Klode [EMAIL PROTECTED] writes: BTW, I think that hg is now the only VCS package which is not maintained in its own VCS format. (or are there other packages, too?) $ apt-cache showsrc rcs | grep Vcs Vcs-Browser: http://git.debian.org/?p=users/rfrancoise/rcs.git Vcs-Git: git://git.debian.org/git/users/rfrancoise/rcs.git cvs is IIRC maintained in svn. Yup, absolutely. :-) -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] There's no sensation to compare with this Suspended animation, A state of bliss -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea of Debian mascot
Lars Wirzenius wrote: [...] I'd really rather see something nicer than an ant as a mascot. :) How about a cockroach? Beautifully engineered, indestructable, and they're *everywhere*... -- David Given [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
martin f krafft [EMAIL PROTECTED] writes: also sprach Lars Wirzenius [EMAIL PROTECTED] [2008.02.26.1018 +0100]: I don't think a stuff Tux belittles Linux. I don't think a stuffed animal would belittle Debian. Fine. I have other arguments: it would make it yet another FOSS project with an animal mascot. I hope that there are still a few other things about Debian that distinguish us from other FOSS projects. FWIW, I think the swirl is wonderful as logo. It can be read as sign for everlasting expansion, or, in the other direction, converging to one common goal [1]. On the other hand, I like the idea of a fluffy stuffed animal [2], simply because Debian is not only a machine running with german efficiency, but a community of like-minded people. I don't think a stuffed animal paying tribute to this more social side of Debian would belittle the project. Marc Footnotes: [1] ... albeit people might argue that Debian is running in circles around that common goal #-) [2] That would make it easier for me to find something nice for Pia [3] [3] http://blog.zobel.ftbfs.de/debian/assimilated -- BOFH #448: vi needs to be upgraded to vii pgpQGM0bzmSDI.pgp Description: PGP signature
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
Hi, * martin f krafft [EMAIL PROTECTED] [2008-02-26 12:26]: also sprach Lars Wirzenius [EMAIL PROTECTED] [2008.02.26.1018 +0100]: I don't think a stuff Tux belittles Linux. I don't think a stuffed animal would belittle Debian. Fine. I have other arguments: it would make it yet another FOSS project with an animal mascot. I strongly agree, also because we already have a logo it would be nice if the new fancy logo would be related to the existing ones. I really like the genie in http://www.openpuppets.com/fondos/8c.png :) Cheers Nico -- Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. pgpNQWEBHc4XP.pgp Description: PGP signature
Re: Idea of Debian mascot
2008/2/26, David Given [EMAIL PROTECTED]: Lars Wirzenius wrote: I'd really rather see something nicer than an ant as a mascot. :) How about a cockroach? Beautifully engineered, indestructable, and they're *everywhere*... No thanks, I preferred the Weasel idea to this :P Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: the new style mass tirage of bugs
On Thu, Feb 21, 2008 at 04:19:14PM +0100, Rene Engelhard wrote: If you give me some time and a co-maintainer at hand... I am barely keeping up with *new* bugreports and updating the packages, keeping them buildable, backporting fixes from upstream etc. You are demonstrating another fairly serious problem with bugs in Debian, and that is you are taking this too personally. If you are unable to manage with the quantity of bugs coming in, that's because *more people are needed*, not because you are personally inadequate. That doesn't change John's experiences, and the problem still needs addressing. I have OOo installed and I use it infrequently. I'd be very daunted if I were involved in it's maintenance. I must be one of hundreds of people who give a silent vote of confidence in your maintainership by installing and using the package -- try to bear that in mind when you're drowning in bugs and everything seeems grim :-) -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Dual-boot setup, incorrect time in Debian's side
I am running a dual boot system with Windows XP and Debian just upgraded to unstable installed. As usual Windows sets the hardware clock to local time. To compensate for this I have UTC=no in /etc/default/rcS as specified. However this setting seems to be ignored. Debian seems to always think that the hardware clock is set to UTC, so when running Debian the clock is one hour ahead. My timezone is Europe/Madrid, just checked... # date -R Tue, 26 Feb 2008 15:46:42 +0100 # cat /etc/timezone Europe/Madrid # md5sum /usr/share/zoneinfo/Europe/Madrid /etc/localtime9adedd59faaf242a67cdfcdc9e7020fa /usr/share/zoneinfo/Europe/Madrid 9adedd59faaf242a67cdfcdc9e7020fa /etc/localtime I see the suggestion of trying... # hwclock --localtime --show select() to /dev/rtc to wait for clock tick timed out Yes, as told somewhere --directisa is required for some systems. # hwclock --localtime --show --directisa Tue Feb 26 15:48:08 2008 -0.881809 seconds The option now is setting HWCLOCKPARS=--directisa in /etc/init.d/hwclock.sh directly or use /etc/default/rcS instead. But no matter what I try, when rebooting the clock is still one hour ahead. Should a bug to libc6 --owner package for /usr/bin/tzselect-- or tzdata be fired? Any ideas welcome... Cordially, Ismael -- Ismael Valladolid Torres GnuPG key: DE721AF4 SHS Polar (3.4.3) Google Talk/Jabber/MSN Messenger: [EMAIL PROTECTED] C/ Emilio Vargas 1Jaiku/Twitter/Skype/Yahoo!: ivalladt Edif. Fiteni II AIM/ICQ: 264472328 28043 Madrid (Spain) The opinions expressed here represent my own and not those of my employer. Las opiniones expresadas representan las mías propias y no las de mi empresa.
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
Le Tuesday 26 February 2008 14:41:41 Nico Golde, vous avez écrit : Fine. I have other arguments: it would make it yet another FOSS project with an animal mascot. I strongly agree, also because we already have a logo it would be nice if the new fancy logo would be related to the existing ones. I really like the genie in http://www.openpuppets.com/fondos/8c.png :) Well, you still can put a logo on the animal's belly.. Now that I think about it, I think that a care bear with a debian logo on it's belly would even be better than a marmot :-D We could say that we all identifies to it, couldn't we ? :-P http://en.wikipedia.org/wiki/Care_Bears http://www.rastageeks.org/~toots/debian/bisounours-debian.jpg Romain
Re: On the subject of watchfiles (was Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version)
On Tue, 26 Feb 2008, Martín Ferrari wrote: Of course, we have luck, because CPAN (99% of our packages come from there, and we have only 4 unsolvable watch problems) is pretty well-behaving and consistent, compared to other upstreams. But chances are that watchfiles can be useful for the majority of people. Well, in fact it is helpful if you teach upstream to organise releases that way that watchfiles would work. This is not only in the interest of Debian but for the whole FLOSS community so other interested users will be able to transparantly download software as well and upstream will start using a consistent version management. This will not work for upstream dead software - but here are watch files void anyway. Kind regards Andreas, who had also doubt about watch files until about onw year ago ... -- http://fam-tille.de
Re: Dual-boot setup, incorrect time in Debian's side
On Tue, Feb 26, 2008 at 02:53:31PM +0100, Ismael Valladolid Torres wrote: I am running a dual boot system with Windows XP and Debian just upgraded to unstable installed. As usual Windows sets the hardware clock to local time. To compensate for this I have UTC=no in /etc/default/rcS as specified. Trying to have hardware clock in local time is bound to lose very fast. It's inherently incompatible with having more than one operating system installed, or even virtual machines and such... Instead of attempting to work around the related bugs, why won't you instead use the undocumented way to fix Windows: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal = (DWORD)1 You'll also need to shutdown and disable Windows Time Service if it's running. It's there on certain versions of Windows. I wonder if it would be a good idea to let d-i fix dual-booted systems this way... -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
also sprach Romain Beauxis [EMAIL PROTECTED] [2008.02.26.1454 +0100]: Now that I think about it, I think that a care bear with a debian logo on it's belly would even be better than a marmot :-D Oh, then I vote for teletubbies. (NOT) -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems i wish i hadn't slept all day, it's really lowered my productivity -- robert mcqueen digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
[Sam Hocevar] Development news Last month Petter Reinholdtsen (pere) gave some news about his project of improving the init system [3]. This is almost as simple as adding LSB headers to your init scripts, and work is advancing towards this goal, though not as quickly as desirable. If your packages have init scripts, or if you wish to help, I urge you to have a look at the proposal so that we can have it in Lenny. For those wondering if their package is affected, here is the complete list of 200 packages missing the LSB headers, sorted by maintainer. All release goals can use 0-day NMUs, so anyone is welcome to help solve these issue. Several of them have BTS reports with patches to fix it already, but I have not managed to covered them all yet. Guenter Geiger (Debian/GNU) [EMAIL PROTECTED] realtime-lsm Stefan Hornburg (Racke) [EMAIL PROTECTED] courier-authlib interchange pure-ftpd sympa Cyril Lacoux (Yack) [EMAIL PROTECTED] digitools Marco Presi (Zufus) [EMAIL PROTECTED] linesrv Peter De Schrijver (p2) [EMAIL PROTECTED] linux-atm Osamu Aoki [EMAIL PROTECTED] tpconfig Ben Armstrong [EMAIL PROTECTED] xpilot-ng Don Armstrong [EMAIL PROTECTED] spamass-milter SZALAY Attila [EMAIL PROTECTED] zorp Alan Bain [EMAIL PROTECTED] rbootd Andreas Barth [EMAIL PROTECTED] mgetty Daniel Baumann [EMAIL PROTECTED] ipmasq nfs-user-server Hilko Bengen [EMAIL PROTECTED] ulog-acctd Grzegorz Bizon [EMAIL PROTECTED] specter Blars Blarson [EMAIL PROTECTED] cnews Ed Boraas [EMAIL PROTECTED] tinyproxy Cyril Bouthors [EMAIL PROTECTED] bld drbdlinks Chris Boyle [EMAIL PROTECTED] reaim Adrian Bridgett [EMAIL PROTECTED] dante Eric Van Buggenhaut [EMAIL PROTECTED] udhcp Bruno Barrera C. [EMAIL PROTECTED] portsentry Patrick Caulfield [EMAIL PROTECTED] mopd Dennis L. Clark [EMAIL PROTECTED] bnetd Jesus Climent [EMAIL PROTECTED] distmp3 Russell Coker [EMAIL PROTECTED] memlockd Jamin W. Collins [EMAIL PROTECTED] jabber Carlo Contavalli [EMAIL PROTECTED] wipl Paul Cupis [EMAIL PROTECTED] guarddog guidedog Artur R. Czechowski [EMAIL PROTECTED] rrdcollect Julien Danjou [EMAIL PROTECTED] greylistd ledstats tetrinetx tleds Debian GNUstep maintainers [EMAIL PROTECTED] gnustep-base Debian Hamradio Maintainers [EMAIL PROTECTED] aprsd Debian Icecast team [EMAIL PROTECTED] icecast2 Debian Multimedia Team [EMAIL PROTECTED] das-watchdog Debian Nagios Maintainer Group [EMAIL PROTECTED] nsca Debian VoIP Team [EMAIL PROTECTED] rtpproxy siproxd Eric Delaunay [EMAIL PROTECTED] scsitools Bernd Eckenfels [EMAIL PROTECTED] net-acct transproxy Robert S. Edmonds [EMAIL PROTECTED] pcaputils Nick Estes [EMAIL PROTECTED] upsd Martín Ferrari [EMAIL PROTECTED] vtun Duncan Findlay [EMAIL PROTECTED] spamassassin Turbo Fredriksson [EMAIL PROTECTED] roxen4 Jochen Friedrich [EMAIL PROTECTED] isakmpd Peter S Galbraith [EMAIL PROTECTED] xtide Radovan Garabik [EMAIL PROTECTED] serpento Radovan Garabík [EMAIL PROTECTED] karrigell xtell Hector Garcia [EMAIL PROTECTED] smail RISKO Gergely [EMAIL PROTECTED] shaperd David Gil [EMAIL PROTECTED] pads Rudy Godoy [EMAIL PROTECTED] netapplet John Goerzen [EMAIL PROTECTED] pygopherd Celso González [EMAIL PROTECTED] cpudyn Daniel Gubser [EMAIL PROTECTED] psad Guido Guenther [EMAIL PROTECTED] smartmontools Aurélien GÉRÔME [EMAIL PROTECTED] dancer-ircd dancer-services Marc Haber [EMAIL PROTECTED] ifupdown-scripts-zg2 Pascal Hakim [EMAIL PROTECTED] anacron Chris Halls [EMAIL PROTECTED] apt-proxy David B. Harris [EMAIL PROTECTED] ipband Andres Seco Hernandez [EMAIL PROTECTED] alamin Varun Hiremath [EMAIL PROTECTED] oss-preserve Henrique de Moraes Holschuh [EMAIL PROTECTED] fcron Simon Horman [EMAIL PROTECTED] heartbeat perdition Peter Howard [EMAIL PROTECTED] zoneminder Qingning Huo [EMAIL PROTECTED] log2mail Alberto Gonzalez Iniesta [EMAIL PROTECTED] fwlogwatch netkit-bootparamd xmbmon Mario Iseli [EMAIL PROTECTED] irmp3 Ian Jackson [EMAIL PROTECTED] sauce Ian Jackson [EMAIL PROTECTED] userv LENART Janos [EMAIL PROTECTED] jmon Joerg Jaspert [EMAIL PROTECTED] muddleftpd LaMont Jones [EMAIL PROTECTED] hpsockd Karl E. Jorgensen [EMAIL PROTECTED] battery-stats Takuo KITAME [EMAIL PROTECTED] smtpguard Matthias Klose [EMAIL PROTECTED] buildbot Steve Kowalik [EMAIL PROTECTED] xringd Antonin Kral [EMAIL PROTECTED] pimd Anand Kumria [EMAIL PROTECTED] tspc Joshua Kwan [EMAIL PROTECTED] nethack Mario Lang [EMAIL PROTECTED] filterproxy Thomas Lange [EMAIL PROTECTED] fai Chris Lawrence [EMAIL PROTECTED] gnome-lokkit John Lines [EMAIL PROTECTED] plptools smtpd Pablo Lorenzzoni [EMAIL PROTECTED] tcpspy Ola Lundqvist [EMAIL PROTECTED]
Re: the new style mass tirage of bugs
Le mardi 26 février 2008 à 13:10 +, Jon Dowland a écrit : If you are unable to manage with the quantity of bugs coming in, that's because *more people are needed*, http://icanhascheezburger.files.wordpress.com/2008/01/funny-pictures-captain-obvious-cat.jpg -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Debian Configuration Packaging System
Timothy G Abbott wrote: There are really two problems with debconf in our system. The first is that debconf asks questions which our configuration package system will override. Using 'DEBCONF_PRIORITY=critical apt-get install' limits them, but some packages we configure prompt for information even with critical DEBCONF_PRIORITY (is this a bug?). No. If you want to avoid all prompts you should use the noninteractive frontend. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dual-boot setup, incorrect time in Debian's side
Ismael Valladolid Torres wrote: As usual Windows sets the hardware clock to local time. To compensate for this I have UTC=no in /etc/default/rcS as specified. There is another file that may need to be changed: /etc/adjtime Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
On Tue, Feb 26, 2008 at 11:26:30PM +1100, Hamish Moffatt wrote: What are the constrained environments where you think static linking would be useful? I'm developing embedded systems and I prefer shared libraries - unless you have only one application using a particular library then you will save space. Desktop grid applications that will be running on an unknown version of an unknown distribution, but I want to be able to build them on Debian. These applications won't ever use NSS, PAM or anything else that relies on some system-level configuration because you can't assume anything about the local system. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
On Mon, Feb 25, 2008 at 11:07:10PM +, Roger Leigh wrote: I stopped providing static libraries in all my library packages quite a while back. No one used them, and they were just needless bloat. I can't say I would be upset if we dropped all the static libraries from the entire archive--is there actually a real world requirement for them in 2008? Yes, desktop grid applications. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
On Mon, 25 Feb 2008 19:11:16 -0500, David Nusinow [EMAIL PROTECTED] said: On Sun, Feb 24, 2008 at 09:31:10PM -0600, Manoj Srivastava wrote: On Mon, 25 Feb 2008 10:34:55 +1100, Ben Finney [EMAIL PROTECTED] said: Manoj Srivastava [EMAIL PROTECTED] writes: David Nusinow [EMAIL PROTECTED] said: No matter what you want to say about your feature branches, you *must* apply them in a linear fashion to your final source tree that you ship in the package. This is no way around it. But there is no such linearization, not in the way that quilt et al do it. The state of such integration is not maintained in the feature branches; it is in the history of the integration branch. Is this (the integration branch and its history of changes) not the linear sequence of changes that David Nusinow is asking for? No, it is not. I Apply a update to feature A. The comes an upstream update. Then updates on feature B, a patch that needed conflict resoution, then patches on branches C, D, and A again. Another upstream change. At this point, none of the original patches to A, B, and C apply any more -- and then come another upstream update, and all the patches get even more bent out of shape. At this point, before you're ready to release, you regenerate the patches. Then they apply just fine. Nothing gets bent out of shape and you don't include old code in your patch that's now incorporated upstream, you just make an appropriate diff that applies cleanly to your source package. I don't see what the problem is here and why you believe this can't be done. Sure, I can re-generate the patches: but then I have to do all the integration work that I did for the integration branch over the years, and I have to do this over and over and over again every single darn package upload. And why am I doing all this busy work? A compromise would be to provide a patch for each pure fearure branch, along with the giant diff -- this can be automated. But these individual patches will not apply in sequence unless the manual integration work is done again -- which is not something I am willing to do for every package upload. manoj -- #else /* !STDSTDIO */ /* The big, slow, and stupid way */ --Larry Wall #in str.c from the perl source code Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
On Mon, 25 Feb 2008 19:04:10 -0500, David Nusinow [EMAIL PROTECTED] said: On Mon, Feb 25, 2008 at 03:56:49AM -0600, Manoj Srivastava wrote: No, it does not. If branch A has pi = 2.34567; and branch B has pi = 3.14159; No matter how much quilting you do you cannot reconcile the fundamental conflict in the final. Either pi is 3.14159; or it is not; and if branch A requires pi not to be that value, and branch B requires pi to be that value, quilt can't make C be quantum like and have the value be both. Feature branches don't magically allow you to avoid merge conflicts either, so this is a red herring. Once you've resolved the conflict, then it becomes just another change. This change can become a diff in a stack of diffs. This whole message is a red herring, since hte feature branches do not attempt to handle merge conflicts -- that is not their purpose. They capture one single feature, independently from every other feature, and thumb their collective noses at merge conflicts. The history of the integration branch captures the integration effort; and the integration branch makes no effort to keep the integration work up to date with current upstream and feature branches. If you think you can extract an up to date integration patch from the entrails of the integration branch -- feel free o smack me down. But please provide some substance to the assertion that it is doable. manoj -- One friend in a lifetime is much; two are many; three are hardly possible. Henry Adams Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
Quoting Petter Reinholdtsen ([EMAIL PROTECTED]): [Sam Hocevar] Development news Last month Petter Reinholdtsen (pere) gave some news about his project of improving the init system [3]. This is almost as simple as adding LSB headers to your init scripts, and work is advancing towards this goal, though not as quickly as desirable. If your packages have init scripts, or if you wish to help, I urge you to have a look at the proposal so that we can have it in Lenny. For those wondering if their package is affected, here is the complete list of 200 packages missing the LSB headers, sorted by maintainer. All release goals can use 0-day NMUs, so anyone is welcome to help solve these issue. Several of them have BTS reports with patches to fix it already, but I have not managed to covered them all yet. I'm currently in the early process of the second l10n NMU campaign ever (the first happened before etch). As usual with the help of the i18n crowd. That campaign will last until the very final freeze of lenny. While doing so, I already spotted a few packages which are missing LSB headers. I *will* add these when NMUing such packages to add the pending l10n stuff. So, in case some people start a NMU campaign for LSB stuff and find packages with pending debconf l10n bug reports, please drop me a note. signature.asc Description: Digital signature
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
Quoting Lars Wirzenius ([EMAIL PROTECTED]): I'm not advocating stuffed animals for Debian mascots. I'm fine with a pillow, a tie, and a tutu. I proposed Lars Wirzenius wearing nothing but a tie and a tutu, and holding a pillow with a swirl on it, as the official Debian mascot. signature.asc Description: Digital signature
Re: the new style mass tirage of bugs
On Thu, 21 Feb 2008 13:58:06 +0100, Bernhard R. Link [EMAIL PROTECTED] wrote: While jidanni's bugs are often hard to read and some might be plain stupid, I got many valuables bugs about hard to spot bugs or broken documentation. I think in the large picture he did more to improve Debian than some maintainers only adding package after package to the distribution. I couldn't say that any better. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: the new style mass tirage of bugs
On Thu, 21 Feb 2008 18:20:37 +0100, Josselin Mouette [EMAIL PROTECTED] wrote: Le vendredi 22 février 2008 à 02:10 +0900, Paul Wise a écrit : On Fri, Feb 22, 2008 at 2:07 AM, Josselin Mouette [EMAIL PROTECTED] wrote: OTOH, maybe you're just too incompetent for that. Insulting contributors really isn't helpful Josselin. Indeed, but jidanni is not a contributor. He contributes a lot of Bug Reports which is important input. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Practical solutions to: the new style mass tirage of bugs
* Stefano Zacchiroli [EMAIL PROTECTED] [2008-02-26 12:00:25 +0100]: Yes, it would be less flexible, but what meaning has a priority field with multiple values? I think that such a field would be meaningful only to sort upon it, and go looking for sorting of multiple valued fields seems to be looking for trouble to me. Priority is specific to a person or group of persons, and a usertag seems to capture this perfectly; a bug might be high priority for you, but low priority for me. -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature
Re: the new style mass tirage of bugs
Le mardi 26 février 2008 à 18:56 +0100, Marc Haber a écrit : On Thu, 21 Feb 2008 18:20:37 +0100, Josselin Mouette [EMAIL PROTECTED] wrote: Indeed, but jidanni is not a contributor. He contributes a lot of Bug Reports which is important input. While bug reports are certainly important input, lame and stupid bug reports are not. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Idea of Debian mascot
Raphael Hertzog dijo [Mon, Feb 25, 2008 at 02:33:26PM +0100]: For an idea of a mascot, maybe you could try some sort of bear. When I created the logo of my company [1], I tried to select an animal that could remind me the strength of Debian and I selected the bear: - walks usually slowly but when it runs, you'd better not be in his way (the quiet force -- we say la force tranquille in French, not sure if I made a good translation) - the white bear could live near the Linux penguin in some cold area In natural environments, you could hardly find animals living as far apart as polar bears and penguins. A polar bear has to swim/walk close to 15,000Km (as neither lives really on the poles, right?) to find a decent penguin. Bah, mascots. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On the subject of watchfiles (was Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version)
Andreas Tille dijo [Tue, Feb 26, 2008 at 03:02:31PM +0100]: Well, in fact it is helpful if you teach upstream to organise releases that way that watchfiles would work. This is not only in the interest of Debian but for the whole FLOSS community so other interested users will be able to transparantly download software as well and upstream will start using a consistent version management. This will not work for upstream dead software - but here are watch files void anyway. Heh, start a bit earlier (think Ruby)... Educate maintainers to release proper .tar.gz, not braindead .gem packages containing the equivalent to an orig.tar.gz (but created due to a nice don't-ask-me-why-that's-not-properly-implemented bug in December 31, 1969)... And then complaining if you are distributing in stable anything older than their nightly checkouts. Yes, Perl and the CPAN rock my world, although my programming is nowadays mostly Ruby-based. The Ruby general mindset is WAY inferior. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467655: ITP: cbflib -- C library for accessing Crystallographic Binary Files
Package: wnpp Severity: wishlist Owner: Teemu Ikonen [EMAIL PROTECTED] * Package name: cbflib Version : 0.7.9 Upstream Author : Herbert J. Bernstein [EMAIL PROTECTED] * URL : http://www.bernstein-plus-sons.com/software/CBF/ * License : GPL Programming Lang: C Description : C library for accessing Crystallographic Binary Files CBFlib is a library of ANSI-C functions providing a simple mechanism for accessing Crystallographic Binary Files (CBF files) and Image-supporting CIF (imgCIF) files. The CBFlib API is loosely based on the CIFPARSE API for mmCIF files. CBFlib performs validation checks on reading of a CBF. If a dictionary is provided, values will be validated against dictionary ranges and enumerations. Tags missing under parent-child relationships or category key requirements will be reported. CBFlib provides functions to create, read, modify and write CBF binary data files and imgCIF ASCII data files. Preliminary packages soon at http://esko.osmas.info/~tmx/cbflib/ Teemu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
On Tue, Feb 26, 2008 at 02:54:18PM +0100, Romain Beauxis wrote: Le Tuesday 26 February 2008 14:41:41 Nico Golde, vous avez écrit : Fine. I have other arguments: it would make it yet another FOSS project with an animal mascot. I strongly agree, also because we already have a logo it would be nice if the new fancy logo would be related to the existing ones. I really like the genie in http://www.openpuppets.com/fondos/8c.png :) Well, you still can put a logo on the animal's belly.. Now that I think about it, I think that a care bear with a debian logo on it's belly would even be better than a marmot :-D We could say that we all identifies to it, couldn't we ? :-P http://en.wikipedia.org/wiki/Care_Bears http://www.rastageeks.org/~toots/debian/bisounours-debian.jpg It would be better to avoid copyright and trademark infringments. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: the new style mass tirage of bugs
On Tue, 2008-02-26 at 19:21 +0100, Josselin Mouette wrote: While bug reports are certainly important input, lame and stupid bug reports are not. What is lame and stupid to us may not be lame and stupid to the average user. Just because you find no value in a particular report (or set of reports) does not mean that necessarily all of the bug reports submitted by a user are necessarily bad. William signature.asc Description: This is a digitally signed message part
Re: Idea of Debian mascot
Gunnar Wolf wrote: Raphael Hertzog dijo [Mon, Feb 25, 2008 at 02:33:26PM +0100]: For an idea of a mascot, maybe you could try some sort of bear. When I created the logo of my company [1], I tried to select an animal that could remind me the strength of Debian and I selected the bear: - walks usually slowly but when it runs, you'd better not be in his way (the quiet force -- we say la force tranquille in French, not sure if I made a good translation) - the white bear could live near the Linux penguin in some cold area In natural environments, you could hardly find animals living as far apart as polar bears and penguins. A polar bear has to swim/walk close to 15,000Km (as neither lives really on the poles, right?) to find a decent penguin. Sometimes, penguins take a vacation. http://www.threadless.com/product/1057/Penguins_On_Holiday (My son has this shirt, and he loves it) Bah, mascots. Cute fuzzy shwags are nice, though. -- John H. Robinson, IV [EMAIL PROTECTED] http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On the subject of watchfiles (was Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version)
On Tue, 26 Feb 2008, Gunnar Wolf wrote: Heh, start a bit earlier (think Ruby)... Educate maintainers to release proper .tar.gz, not braindead .gem packages containing the equivalent to an orig.tar.gz (but created due to a nice don't-ask-me-why-that's-not-properly-implemented bug in December 31, 1969)... And then complaining if you are distributing in stable anything older than their nightly checkouts. Yes, Perl and the CPAN rock my world, although my programming is nowadays mostly Ruby-based. The Ruby general mindset is WAY inferior. What? I admit I would have been able to parse the contents of your mail with the same success if you would have written in Spanish. :) Prehaps it is me who had to get up 4:20 this morning (so I started *really* early ;-) ) - but I do not even understand whether this is pro or contra proper watch files. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Pierre Habouzit writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)): Raphael is wrong to ask you to rebase, he's _really_ wrong about that, but *you* also are wrong to ask him to pull (aka fetch + merge). The usual way is that _you_ merge the current state of dpkg in your work so that _you_ solve the conflicts and issues, and _then_ mainline can see how it looks and look at the cleansed diff. I definitely agree that I should be the one to do the merge. So at least twice already I have merged mainline into my tree and published the result. Ie, I agree with you. That's exactly what I want to happen. I'm very happy to do that merge again, if I have some assurance that it's not just wasted work. In fact, at this stage I don't even want any effort from Raphael and Guillem. All I want is permission. They have already granted me physical commit access but they have made it clear that they don't want me to merge my branch, or to commit freely, and that they will consider it abusive if I simply push a merged triggers branch. All I want is for Raphael or Guillem to say `oh all right then'. I will then merge mainline into my branch, do any conflict resolution necessary, and give it a quick test to make sure nothing seems to have been broken in the meantime. Then merging my branch back into mainline is, as you say, just a fast forward - so I will simply do that, and push the result. And really I would like Raphael and/or Guillem to simply confirm that I'm a full member of the team. IOW, you have to merge master, preferably in a new branch than your trigger-new one, like a master-pu-triggers or whatever, and if mainline is pleased or can read that patch (that I'm sure isn't _that_ big) they _then_ will be able to merge that branch that would just be a fast-forward. The resulting patch is still big (3-4kloc of diff) because triggers is a big feature. The size will not change much depending on what precise revision it's based on. Note that they may ask you to rework this merge if they had done some further commits, but if you mkdir .git/rr-cache then git is able to use recorded images of already solved conflicts so that merging the same conflicts again and again doesn't costs you any time. IME I can just merge from mainline into my branch, and it all works completely fine and I never need to do any rework. This is, after all, what a distributed vcs is for. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Extending fortunes-debian-hints package
Hi! * Kartik Mistry [EMAIL PROTECTED] [080226 05:09]: Great idea. Please check: http://wiki.debian.org/FortunesDebianHints and get started! I am new to wiki, so improve my formatting too :) You might want to subscribe to that wiki page, so you'll get notified via email, when someone makes a change to that page :) Yours sincerely, Alexander signature.asc Description: Digital signature
Re: Idea of Debian mascot
On Tue, 2008-02-26 at 12:21 -0600, Gunnar Wolf wrote: In natural environments, you could hardly find animals living as far apart as polar bears and penguins. A polar bear has to swim/walk close to 15,000Km (as neither lives really on the poles, right?) to find a decent penguin. to find a decent penguin? Could you clarify what you mean by decent here? (Also, it's a bloody mascot, who cares if they don't /really/ live in the same locations. They live in the same /climate/ and that's good enough for most people.) William signature.asc Description: This is a digitally signed message part
mc with new utf-8 patch in experimental available - please test
Hey! Since upstream of mc rejects the current utf8 patchset which is used by several distributions and this patchset is to be honest, indeed not very good, I decided to switch to a new patchset, which was posted on the mc-devel list last year. One of the upstream authors took a look on this patchset and states that he might include this into mc after testing, since it looks in his eyes quite straight forward. He also encouraged people to test and use it. Since this patchset is quite new, I uploaded it for first testing to experimental and I it would rock if someone would test it and report errors to me :) Thanks in advance Greetings Winnie -- .''`. Patrick Winnertz [EMAIL PROTECTED] : :' : GNU/Linux Debian Developer `. `'` http://www.der-winnie.de http://people.skolelinux.org/~winnie `- Debian - when you have better things to do than fixing systems signature.asc Description: This is a digitally signed message part.
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Raphael Hertzog writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)): It starts with two very big commits touching almost all files and is followed by many small commits which have ubuntu changelog entries as commit log (and thus the summary line is useless). It also contains invalid email address in some Author fields. Well, I'm sorry that not all of my early commit entries are ideal. Note that the wrong email address was due to a bug in Debian's git. But, is it really worth the effort to go back and edit revision logs now ? And if I do so, will I disrupt merging any less than if I rebase ? Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Configuration Packaging System
On Tue, 26 Feb 2008, Frank K??ster wrote: [...] 3) Scripts that are not marked as conffiles but which cannot be configured in any way other than by modifying the script. If those scripts live below /etc, they definitely should be marked as conffiles. If they live elsewhere, no package should edit them. I think it's totally reasonable for the MIT site configuration packages to (e.g.) divert chsh to replace it with a wrapper that supports handling both inherently local user accounts (like root or postfix) by calling chsh.debathena-orig and network accounts (through some other mechanism). While some might argue that instead MIT should create a modified version of the passwd package to make this change, I think our solution is substantially cleaner. It's important to keep in mind is that while the system for creating configuration packages should be part of Debian, the configuration packages themselves are not distributed as part of Debian, but should instead be considered as modifications to Debian. It makes sense for them to be able to change some standard programs in a way that only makes sense for that particular site, but doesn't break other uses of those programs, as well as changing configuration file defaults. [...] One idea [...] would be for dpkg to run postinst scripts in a special environment that rewrites filenames according to the diversion database I would rather contemplate a new interface for configuration packages, something like a hook which has to be executed by each postinst script and allows the configuration package to bring its settings into effect. If you want to be able Would deploying this new interface require modifying every Debian package's postinst scripts to add support for this new hook? I'm not enthusiastic about the deployment costs of that kind of sweeping change if there are more localized changes to Debian that would work. to remove configuration packages, the original file needs to be preserved somehow, but the current dpkg-divert is not sufficient for this: Consider someone installing the configuration package in stable+0, then upgrading to stable+1 and keeping it, and then upgrading to stable+2 and subsequently removing the configuration package. Any special code in the maintainer scripts which dealt with incompatible conf(iguration )file changes in the stable-to-stable+1 upgrade is likely to have been removed by now, so the old, incompatible, file from stable+0 will be used after the removal, and the package is in a broken state. That's certainly a potential problem with our current system. The filename rewriting idea does not have this problem. During the upgrades, the maintainer scripts for the package would update /etc/ldap/ldap.conf.debathena-orig (rather than the running version), and when the configuration package is uninstalled, /etc/ldap/ldap.conf.debathena-orig will be moved back to /etc/ldap/ldap.conf, leaving the package in the state it would have been in had the configuration package never been installed in the first place. The filename rewriting plan is really a natural extension to the current dpkg-divert behavior; rather than just unpacking files in locations as determined by the diversion database, all actions by the packaging system would have their filenames transformed according to the diversion database. I also can't think of anything that doing this would break -- its primary cost would be the added complexity in dpkg (and perhaps some performance penalty, depending on implementation). But it's also no silver bullet. There are packages that want to restart their daemon after changing their configuration file, and it's unclear to me how to prevent packages from restarting their daemon (or regerating their database, etc.) in the filename rewriting environment. -Tim Abbott
Re: Practical solutions to: the new style mass tirage of bugs
On Tue, 26 Feb 2008, Stefano Zacchiroli wrote: I think that such a field would be meaningful only to sort upon it, and go looking for sorting of multiple valued fields seems to be looking for trouble to me. Since tags don't sort, they segregate, you just choose based on the first one that matches, so it's no real trouble. [The debbugs example with my user is one way you can do things.] Sounds like hackish, doesn't it? The advantage is it works now, works with methods that are known to work, and doesn't require a whole set of new control methods to interact with the field. Anyhow, another point for preferring a non-user priority tag is that you don't need to set a user, which IMO makes a lot easier to deal with bug reports since you don't risk to forget what the right user for the tag/category you're setting is (which frequently happens to me). You'd have to have a user; it could be a visible one by using [EMAIL PROTECTED] or [EMAIL PROTECTED], but implementing something like this that is necessarily a personal (or small group of people) preference in a way that can't be made personal is a waste of time, AFAIC. Don Armstrong -- o punish me for my contempt of authority, Fate has made me an authority myself -- Albert Einstein http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea of Debian mascot
2008/2/25, Goswin von Brederlow [EMAIL PROTECTED]: What? You don't have a set of Toy Story Action Figures yet? As i see on news today, sudafrica has an openning to hunt elephants again because they have so much, but some time ago there where on risk of extintion. Is not there an elephant on Toy Story Action Figures? As the huge amount of packages, architectures, documentations, translations, mail lists, ... that we have in Debian distribution makes Debian to have an _elephantastic_ size ! There is no time in one life to read all Debian information ;-) -- Héctor Orón
Re: Idea of Debian mascot
Well, now after I worked it out, you can have a look at my drafts at https://disc.alice-dsl.net . to log in use username aura_urlaub and password public. its an ant and an ant-eater as first ideas. nic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Henrique de Moraes Holschuh writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)): Given that many of us work on the kernel, some of us are both upstream and downstream in git, and therefore know *both* sides of the troubles and advantages of git rebase quite well... I can see why you'd have a tough time convincing anyone to change his mind about it. We will have lived it ourselves and made up our minds about it a long time ago, already... dpkg is not the Linux kernel. Linux dpkg Number of different people regularly contributinghundreds or three or significant changes thousandsfour Size of source (.tar.gz) 59 Mby 6.3 Mby Current gatekeepersOriginal author Developers who and hand-picked happened along lieutenants at the right time Organisational relationshipNone / Members of original between main contributors commercial project, under competition unified governance Linux has some very severe management problems to solve: its large size, its position right at the centre, and so forth. To deal with these problems, very heavyweight processes have evolved to ensure that the load on the small number of central gatekeepers is absolutely minimised. An underlying assumption is that in order to save a minute of work for Linus, it is worthwhile to impose tens of minutes, or even hours, of work on submitters. The gatekeepers in Linux can only delegate with extreme care because the code is too big for effective ongoing review, and because many contributors' motives are often specifically aligned with a desire to get a patch accepted - often with substantial financial implications. If you try to apply the same processes to dpkg, or to even smaller and less important projects, you're introducing a very cumbersome burden for very little good effect. It is very unfortunate for git that most of its advocates want to adopt these almost unmanageable development practices along with the revision control software. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Pierre Habouzit writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)): Well, what you want him to do then is not rebasing onto master, because that won't change that a single bit. And indeed I agree this history is a complete mess, and an SCM abuse. What you want him to do is using: git rebase -i his original branch point If I do that, it will surely break the revision history of my derived branches just as badly ? Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea of Debian mascot
On Tue, 2008-02-26 at 21:19 +0100, Harald Braumann wrote: On Tue, 26 Feb 2008 14:45:05 +0100 Miriam Ruiz [EMAIL PROTECTED] wrote: 2008/2/26, David Given [EMAIL PROTECTED]: Lars Wirzenius wrote: I'd really rather see something nicer than an ant as a mascot. :) How about a cockroach? Beautifully engineered, indestructable, and they're *everywhere*... No thanks, I preferred the Weasel idea to this :P And why does it have to be an animal at all? I for one can't identify with any specimen of the *nix bestiary. Except maybe with the bsd daemon, but that's technically not a beast. But all those foxes, chameleons, penguins and what not -- I don't know. If an animal at all, I would definitely prefer a cockroach. But it's maybe hard to manufacture from plush. What about a tarantula? Fluffy by design. I don't really see why you couldn't make a stuffed Debian swirl. I'd buy one of those. Maybe we could call the Debian swirl our mascot and come up with some lame name like Swirly the Debian mascot. It could be like that talking paper clip they always make fun of in M$ Office. Hmm! Maybe a Debian assistant... *boing* I see you are trying to install a package, do you want help with that? William signature.asc Description: This is a digitally signed message part
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On 25/02/2008, Pierre Habouzit wrote: What you want him to do is using: git rebase -i his original branch point Probably with -p. -- Cyril Brulebois, who tried, w/o prior knowledge of the code. pgpi79bZt6Ty5.pgp Description: PGP signature
Re: Debian Configuration Packaging System
Timothy G Abbott writes (Debian Configuration Packaging System): applying dpkg-divert to configuration files. Yikes. Tim Abbott writes (Re: Debian Configuration Packaging System): I'll note that we wrap our dpkg-divert calls with a bunch of error-handling code that we found quite important for correctly recovering from people hitting ^C in the middle of installation (see http://debathena/config-packages/code/config-package-dev-4.2/divert.sh.in for the code). Earlier iterations that did not do this were plagued with problems whenever there were errors in installation. Yikes. I think this is a bad idea. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea of Debian mascot
On Tue, 26 Feb 2008 14:45:05 +0100 Miriam Ruiz [EMAIL PROTECTED] wrote: 2008/2/26, David Given [EMAIL PROTECTED]: Lars Wirzenius wrote: I'd really rather see something nicer than an ant as a mascot. :) How about a cockroach? Beautifully engineered, indestructable, and they're *everywhere*... No thanks, I preferred the Weasel idea to this :P And why does it have to be an animal at all? I for one can't identify with any specimen of the *nix bestiary. Except maybe with the bsd daemon, but that's technically not a beast. But all those foxes, chameleons, penguins and what not -- I don't know. If an animal at all, I would definitely prefer a cockroach. But it's maybe hard to manufacture from plush. What about a tarantula? Fluffy by design. harry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea of Debian mascot
Hector Oron wrote: 2008/2/25, Goswin von Brederlow [EMAIL PROTECTED]: What? You don't have a set of Toy Story Action Figures yet? Is not there an elephant on Toy Story Action Figures? As the huge amount of packages, architectures, documentations, translations, mail lists, ... that we have in Debian distribution makes Debian to have an _elephantastic_ size ! PostgreSQL already uses an elephant in their logo. While ths does not preclude us from using it, it could be taken as an endorsement of one particular DB engine, over others. -- John H. Robinson, IV [EMAIL PROTECTED] http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html Disclaimer: I claim PostgreSQL is the best SQL DB we have in the archive. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
On Tue, Feb 26, 2008 at 09:36:32AM +0100, Franklin PIAT wrote: What about a bug... Bugs are our pets : we take care of them. Oh god. No, please, everything but not a bug as mascot. You'll be unable to communicate to our users that we _care_ for bugs. It will bring the reputation to Debian, that it is the project that is proud of its bugs and thats really a negative reputation. just my 2 cents Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
On Tue, Feb 26, 2008 at 10:20:55AM +0100, martin f krafft wrote: Fine. I have other arguments: it would make it yet another FOSS project with an animal mascot. What about a Foss project with a non-animal mascot? And for an non-animal mascot I'd like to suggest The perfect spiral [¹]. [¹] http://antwrp.gsfc.nasa.gov/apod/ap071201.html signature.asc Description: Digital signature
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Tue, Feb 26, 2008 at 07:09:46PM +, Ian Jackson wrote: I will then merge mainline into my branch, do any conflict resolution necessary, and give it a quick test to make sure nothing seems to have been broken in the meantime. Then merging my branch back into mainline is, as you say, just a fast forward - so I will simply do that, and push the result. I've no idea if anyone involved would consider it acceptable but might merging the triggers branch into the mainline with --squash be a suitable comprimise? This would give a single commit discarding the branch history which isn't ideal but would avoid having the history from your branch in the main history. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
Hi, On Tue, Feb 26, 2008 at 09:56:40AM +0100, martin f krafft wrote: also sprach Franklin PIAT [EMAIL PROTECTED] [2008.02.26.0936 +0100]: What about a bug... Bugs are our pets : we take care of them. I guess I just repeat myself when I question why we need to join the free software zoo. Is it hip? Are we hip? What's the gain? Why bother? The question is: Why not? Okay, it doesn't have to be an animal (it could also be an insect, a fantasy creature, etc.) but consider that having something like that has a good haptic effect. From a marketing point of view its a really great idea, because it betters the recognition of Debian. Consider that people like it. I'm quiet sure, that if we'd ask the sellers of such floss animals they would tell us that these floss animals are popular demanded items. And hey, don't you have a penguin or something like that in the near of your computer or its peripherals? Well, I do. A fluffy pillow with a swirl on it sounds like a good idea, for when you're feeling down and need some FOSS lovin'. Oh.. okay.. a fluffy pillow ... for FOSS lovin'.. is okay, but - well don't let me think about this :-) A fluff animal, on the other hand, is for kids. Debian is not. No it is not. Or would you really say that the recognition of FreeBSD is the one of a kids toy? And btw. we _do_ target kids as well. For them a nice fluffy animal seriously highers their interest in Debian. BTW. just for the records: I do not advocate for a logo replacement. It is fine as it is. But certainly a mascot can be a good supplement to a good logo. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
also sprach Patrick Schoenfeld [EMAIL PROTECTED] [2008.02.26.2239 +0100]: From a marketing point of view its a really great idea, because it betters the recognition of Debian. From a marketing point of view, our swirl is already better than any other mascot, except maybe Tux. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems all language designers are arrogant. goes with the territory... -- larry wall digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: Idea of Debian mascot
On Tue, Feb 26, 2008 at 01:41:22PM -0600, William Pitcock wrote: (Also, it's a bloody mascot, who cares if they don't /really/ live in the same locations. They live in the same /climate/ and that's good enough for most people.) How about a leopard seal? They eat penguins :-| http://www.flickr.com/photos/hnmoffatt/381679738/in/set-72157594521689295/ Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
On Tue, 26 Feb 2008 09:56:40 +0100, martin f krafft wrote: What about a bug... Bugs are our pets : we take care of them. I guess I just repeat myself when I question why we need to join the free software zoo. Is it hip? Are we hip? What's the gain? Why bother? Ack. A fluffy pillow with a swirl on it sounds like a good idea, for when you're feeling down and need some FOSS lovin'. What I'd actually like to see, own and use is a sweat-shirt; wearing it in everday life would be a nice and easy way of promoting Debian. gre as long as it's black gor -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `-NP: Sigur Rós: Mílanó signature.asc Description: Digital signature
Re: Practical solutions to: the new style mass tirage of bugs
DN don't have the time (or often the ability) to go back and DN reproduce the hundreds of bugs Yes. Never mind the old bugs then. Just try to reproduce new bugs as they come in, before they become old bugs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#466728: ITP: python-trio -- RDF utilities
Hi On Thursday 21 February 2008 19:07, Noah Slater wrote: On Thu, Feb 21, 2008 at 08:44:00AM +0100, Christian Perrier wrote: Sorry, this is precisely rationale I fight against. Just saying if you don't know what this is, you don't need this defeats the purpose of packages descriptions. Fully agree. In the general case maybe but for this I disagree. For highly specialised development tools such as RDF there is really no need to be verbose about what the name actually means because those who would be interested already know. sarcasm mode on I know what RDF means. RDF is an abbreviation for radio direction finder. I guess there are digital RDFs now, and you're packaged python utils for dealing with then. Or maybe it's python utils for manipulating a Reuters Data Feed. Or for a Radial distribution function. Or one of half a dozen other possible meanings for RDF. [0] /sarcasm mode off Even though a package is highly specialised, you should make a package description as understandable as possible by everyday users. Consider the following (made up) example. feamodel-utils - utils for manipulating FEA models Utilities for manipulating FEA models. It supports ABACA, FEDME and FrEA format models. feamodel-utils - utils for manipulating Finite Element Analysis (FEA) models Utilities for manipulating Finite Element Analysis (FEA) models. It supports ABACA, FEDME and FrEA format models. The first is pure gobbledygook to anyone who does not recognise the key acronym. Because they can't understand what you're talking about, you run the risk of alienating them. By expanding the key acronym, the second is much more understandable. As such it's much less alienating. By limiting the key sentence is to words everybody can understand, it provides all users with sufficient information to decide whether the package is interesting to them/someone they know. I took a look at the current state of affairs w/r to RDF: [EMAIL PROTECTED]: ~ $ apt-cache search rdf | grep rdf liblrdf0 - a library to manipulate RDF files describing LADSPA plugins Short and long descriptions use RDF in context. liblrdf0-dev - liblrdf0 development files Short description refers to liblrdf0, long description provides context. librdf-perl - Perl language bindings for the Redland RDF library Qualifies RDF in short description, expands RDF in long description. librdf-ruby - Ruby 1.8 language bindings for the Redland RDF library Qualifies RDF in short description, expands RDF in long description. librdf0 - Redland Resource Description Framework (RDF) library RDF expanded and qualified in short description. librdf0-dev - Redland RDF library development libraries and headers Qualifies RDF in short and long descriptions. php5-librdf - PHP5 language bindings for the Redland RDF library Qualifies RDF in short description, expands RDF in long description. python-librdf - Python language bindings for the Redland RDF library Qualifies RDF in short description, expands RDF in long description. python-rdflib - RDF library containing an RDF triple store and RDF/XML Short and long descriptions provide context. Only one of these packages is expanding the acronym RDF. All of the above either provide context or qualify RDF. Most expand RDF in the long description. If you are going to use an acronym from a specialised field as a central part of the package description, you should either expand or explain the acronym. At the absolute least, you need to provide enough context so that the acronym won't be confused with other possible meanings. Anything less is just begging to be misunderstood. I really don't see the use case here. Package descriptions should as clear as possible to all users. Resource Description Framework is plain English that all readers can understand. They may not be familiar with the subject matter, but at least they can understand the words that you're using. That way you avoid alienating them with unnecessary jargon. Andrew V. [0]. http://en.wikipedia.org/wiki/Rdf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea of Debian mascot
William Pitcock dijo [Tue, Feb 26, 2008 at 01:41:22PM -0600]: In natural environments, you could hardly find animals living as far apart as polar bears and penguins. A polar bear has to swim/walk close to 15,000Km (as neither lives really on the poles, right?) to find a decent penguin. to find a decent penguin? Could you clarify what you mean by decent here? There are penguins living in most of the South hemisphere's coasts - Up to the Equator, in the Galapagos Islands. I would not call them decent, as they break most of our cultural myths/icons :) (Also, it's a bloody mascot, who cares if they don't /really/ live in the same locations. They live in the same /climate/ and that's good enough for most people.) I do not care for a Debian mascot. The whole thread should belong in -curiosa, FWIW... Or in /dev/null even. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Configuration Packaging System
On Tue, 26 Feb 2008, Ian Jackson wrote: Tim Abbott writes (Re: Debian Configuration Packaging System): applying dpkg-divert to configuration files. Yikes. At the moment, there are no choices for doing site configuration that are general enough to change arbitrary configuration options and don't destroy whatever configuration state the machine had before configuring it (as well as suffering from a version of every bad interaction with existing maintainer scripts that our system has). All of the important problems with our dpkg-divert based configuration package system that have been discussed in this forum are problems for any configuration mechanism other than debconf preseeding. Debconf preseeding is unacceptable for site configuration because it is insufficiently general (often things need to be configured that are not set up as debconf options). Any system that is not based on debconf pre-seeding (or maintaining a fork of all the relevant packages containing the relevant configuration files, which is unmaintainable) will have all the problems with maintainer scripts that our system has. Further, any configuration system that does not use dpkg-divert will have to fight with dpkg over control of conffiles (a problem that our system does not have). It turns out that our system also works for almost all the other configuration files that we've wanted to change (in particular, those whose packages don't overwrite manual changes with answers from the debconf database on package upgrades, something the Debian Policy Manual forbids anyway). So, anything attempting to achieve the functionality we want has to use dpkg-divert, and I think the best way to remove the problems with dealing with configuration files that are not conffiles should probably involve making maintainer scripts that do overwrite existing configuration files follow diversions when doing so (though one mechanism or another). Tim Abbott writes (Re: Debian Configuration Packaging System): I'll note that we wrap our dpkg-divert calls with a bunch of error-handling code that we found quite important for correctly recovering from people hitting ^C in the middle of installation (see http://debathena.mit.edu/config-packages/code/config-package-dev-4.2/divert.sh.in for the code). Earlier iterations that did not do this were plagued with problems whenever there were errors in installation. Yikes. Those earlier iterations date to 2004 and were never deployed beyond a testing environment. The particular shell code we're using now has been basically unchanged since we wrote it back in Summer 2006, and has not been a problem for us since. -Tim Abbott -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea of Debian mascot
Consider a red octopus with its arms arranged in a swirl. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
On Tue, 2008-02-26 at 22:02 +0100, Patrick Schoenfeld wrote: On Tue, Feb 26, 2008 at 09:36:32AM +0100, Franklin PIAT wrote: What about a bug... Bugs are our pets : we take care of them. Oh god. No, please, everything but not a bug as mascot. You'll be unable to communicate to our users that we _care_ for bugs. It will bring the reputation to Debian, that it is the project that is proud of its bugs and thats really a negative reputation. It doesn't really have to be our best friend... we could have a stress ball looking like a bug, that we could bring at BSPs (Let's squash a bug). Those were just random ideas anyway, As I really like our Swirl (and its pink... that's really our color). Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Configuration Packaging System
Timothy G Abbott writes (Re: Debian Configuration Packaging System): All of the important problems with our dpkg-divert based configuration package system that have been discussed in this forum are problems for any configuration mechanism other than debconf preseeding. Debconf preseeding is unacceptable for site configuration because it is insufficiently general (often things need to be configured that are not set up as debconf options). I think a better approach is just to have a package which writes stuff over the configuration files without diverting them. Such a package is putting itself in the position of the system administrator, which is presumably what you intend. That's not appropriate for a Debian package but for a site-specific configuration setting system it's OK I think. You do have to deal with conffile prompts and other kinds of things that happen when software (package maintainer scripts, and dpkg) spot you've modified the files. But if you do all of your installations in a noninteractive mode (with a noninteractive debconf frontend and with dpkg configured not to prompt about conffiles) you get predictable behaviour which you can override as you like. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Configuration Packaging System
On Wed, 27 Feb 2008, Ian Jackson wrote: Timothy G Abbott writes (Re: Debian Configuration Packaging System): All of the important problems with our dpkg-divert based configuration package system that have been discussed in this forum are problems for any configuration mechanism other than debconf preseeding. Debconf preseeding is unacceptable for site configuration because it is insufficiently general (often things need to be configured that are not set up as debconf options). I think a better approach is just to have a package which writes stuff over the configuration files without diverting them. Such a package is putting itself in the position of the system administrator, which is presumably what you intend. That's not appropriate for a Debian package but for a site-specific configuration setting system it's OK I think. If we were running a cluster of identical machines, such a system would probably work. But we actually don't intend to be in the position of the system administrator; we just want to provide defaults in a decentralized environment with many different sysadmins. This is a harder setting, and I think our users find it useful that they can run etch or sid or even Ubuntu as needed to get their work done and benefit from the site defaults. Our current deployment is on a few hundred machines, primarily personal machines owned by individuals who want to be able to access MIT services, but who do their own system administration. We offer various metapackages with different levels of login integration, and we support all Debian and Ubuntu releases from sarge until present from a single set of source packages, a valuable feature of the configuration package creator interface of our system. So, our goal is to provide our users with the same opportunities to override our configuration defaults as they would have had if Debian had been providing them instead. Using the Debian packaging system for this configuration is a good way to achieve this. You do have to deal with conffile prompts and other kinds of things that happen when software (package maintainer scripts, and dpkg) spot you've modified the files. But if you do all of your installations in a noninteractive mode (with a noninteractive debconf frontend and with dpkg configured not to prompt about conffiles) you get predictable behaviour which you can override as you like. We've found it pretty useful to be able to install our configuration on an existing system. -Tim Abbott -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468110: ITP: osptoolkit -- An open source client side development kit for Open Settlement Protocol
Package: wnpp Severity: wishlist Owner: TransNexus, Inc. [EMAIL PROTECTED] * Package name: osptoolkit Version : 3.4.2 Upstream Author : TransNexus, Inc. [EMAIL PROTECTED] * URL : https://sourceforge.net/projects/osp-toolkit * License : BSD Programming Lang: C/C++ Description : An open source client side development kit for Open Settlement Protocol The Open Settlement Protocol (OSP) standard defined by the European Telecommunications Standards Institute (ETSI TS 101 321) www.etsi.org. The OSP Toolkit is an open source implementation of the OSP peering protocol and is freely available from www.sourceforge.net. It enables applications for secure multi-lateral peering. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mc with new utf-8 patch in experimental available - please test
Patrick Winnertz wrote: Since this patchset is quite new, I uploaded it for first testing to experimental and I it would rock if someone would test it and report errors to me :) Displays only question marks in the ru_RU.KOI8-R locale. This regression is a showstopper. -- Alexander E. Patrakov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
gregor herrmann [EMAIL PROTECTED] writes: What I'd actually like to see, own and use is a sweat-shirt; wearing it in everday life would be a nice and easy way of promoting Debian. URL:http://clusty.com/search?query=host%3Acafepress.com+debian+sweatshirt -- \ Dyslexia means never having to say that you're ysror. -- | `\ Anonymous | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
On Tue, Feb 26, 2008 at 8:41 PM, Nico Golde [EMAIL PROTECTED] wrote: I strongly agree, also because we already have a logo it would be nice if the new fancy logo would be related to the existing ones. I really like the genie in http://www.openpuppets.com/fondos/8c.png :) Hey, I like the genie, too. What it communicates to me is magic. In fact, when seeing the swirl logo, I usually imagine some wizard that makes it. :) Cheers, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea of Debian mascot
On Tue, Feb 26, 2008 at 07:55:56PM +, Hector Oron wrote: 2008/2/25, Goswin von Brederlow [EMAIL PROTECTED]: What? You don't have a set of Toy Story Action Figures yet? As i see on news today, sudafrica has an openning to hunt elephants again because they have so much, but some time ago there where on risk of extintion. Is not there an elephant on Toy Story Action Figures? As the huge amount of packages, architectures, documentations, translations, mail lists, ... that we have in Debian distribution makes Debian to have an _elephantastic_ size ! There is no time in one life to read all Debian information ;-) -- Héctor Orón Hi, I was trying to think of something interesting and this one idea: picture an elephant with a mouse sitting on the elephants head both have a swirl on them(somewhere). Now add the following text: Debian: it runs on the largest beast to the smallest HTH, Kev -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | |join the new debian-community.org to help Debian! | |___ Unless I ask to be CCd, assume I am subscribed ___|
Re: Idea of Debian mascot
On 2/26/08, John Hasler [EMAIL PROTECTED] wrote: Consider a red octopus with its arms arranged in a swirl. Swirl? http://fixxxer.cc/images/mascot/Cucumber_Swirl.jpg http://fixxxer.cc/images/mascot/Swirl_by_greenvampire.jpg http://fixxxer.cc/images/mascot/Red_Swirl_by_gemh.jpg http://fixxxer.cc/images/mascot/red_and_black_swirl_by_piffin.jpg http://fixxxer.cc/images/mascot/through_the_swirl_by_aStormcrow.jpg http://fixxxer.cc/images/mascot/magick-swirl.gif But, does Debian need another logo? I don't think so. I still like a mascot: http://fixxxer.cc/images/mascot/Mascot_Harmony_without_Strings_by_ravenmosher.jpg Regards. -- Anibal Avelar (FixXxeR) http://fixxxer.cc GPG: 83B64656 - C143 4AD8 B017 53FA B742 D6AA CEEA F9F3 83B6 4656 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Google Summer of Code 2008
On 27/02/08 at 00:42 +, Steve McIntyre wrote: Hey folks, Google are running their Summer of Code programme again this year[1], and if we want to take part again we need to apply between March 3rd and March 12th. If we're accepted as a mentoring organisation, then students will be able to apply to work with us up until the 1st April. [2] Hi, I have had a problem with the way GSOC was handled in Debian in the past years. Many of the students that were selected were already well-known Debian contributors or developers. The first problem with that is that some of those students used their GSOC time to work on their usual Debian tasks instead of their GSOC project, leading to disapointing results, unsuccessful projects, less projects being accepted the next year, etc. The other problem is that some Debian developers who could have applied as well didn't, because they thought that GSOC was only for new contributors. I think that GSOC is a great opportunity to get fresh blood inside Debian, and that we should use it for that, not to get funding for usual Debian work. We should have a policy of not allowing existing Debian developers to apply as students. If DDs want to use GSOC to get some work done inside Debian, they could become mentors instead. However, I'm not sure that many DDs agree with this, so maybe we should just aim for *clarification*. So any of the three following solutions would work for me: (1) Forbid DDs and people in the NM process waiting for FD/DAM to apply as students. (2) Make it crystal clear (through a mail to d-d-a) that DDs that are otherwise eligible can apply as well. (3) Compromise: allow current contributors to apply, but, when classifying applications, do it like that: 1. Application from outsider 2. Application from current contributor 3. Application from outsider 4. Application from current contributor [...] What do you think? -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Tue, 26 Feb 2008, Ian Jackson wrote: But, is it really worth the effort to go back and edit revision logs now ? And if I do so, will I disrupt merging any less than if I rebase ? As soon as you edit commits, they'll get a new id, and thus you'll disrupt merging. The thing that you doesn't seem to understand is that if you don't do it, Guillem will do it for you and you'll have to fix up your other branches (flex-based parser, ...) anyway and you won't be able to use plain merge for that (or rather you can but it will be highly inefficient compared to a git-rebase -i where you skip the irrelevant commits that have been merged with other id). Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Erlang on UltraSparc III (again)
On 2/24/08, Jurij Smakov [EMAIL PROTECTED] wrote: I can confirm that there is some serious problem. I've tried to rebuild Erlang on SunBlade 1000 (which is Ultrasparc III) and I keep getting non-reproducible falures (two Bus Errors in different places, once aborted saying that the file is missing, and once just hanged). Unfortunately, I don't have a clue on how to even start debugging something like this. I think it could be easier to debug using older erlang version (11.b.5). It doesn't start a thread for every physical processor by default. So, its behavior should be more predictable. Bernd Zeimetz did look at this bug once (see http://www.mail-archive.com/[EMAIL PROTECTED]/msg02147.html) but due to lack of time he couldn't fix it. -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted liboil 0.3.13-1 (source i386)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 26 Feb 2008 07:21:17 +0100
Source: liboil
Binary: liboil0.3 liboil0.3-dev liboil0.3-dbg
Architecture: source i386
Version: 0.3.13-1
Distribution: unstable
Urgency: low
Maintainer: Maintainers of GStreamer packages [EMAIL PROTECTED]
Changed-By: Sebastian Dröge [EMAIL PROTECTED]
Description:
liboil0.3 - Library of Optimized Inner Loops
liboil0.3-dbg - Library of Optimized Inner Loops (debug packages)
liboil0.3-dev - Library of Optimized Inner Loops (development headers)
Closes: 433025 444170 455724 467251
Changes:
liboil (0.3.13-1) unstable; urgency=low
.
* New upstream release (Closes: #467251):
+ Adds OS detection for GNU/kFreeBSD (Closes: #433025).
+ Fixes SEGV if /proc is not mounted on ARM (Closes: #455724).
+ Fixes PowerPC FPU test (Closes: #444170).
+ debian/liboil0.3.shlibs:
- Update to = 0.3.13.
* debian/control:
+ Package adopted by pkg-gstreamer as David doesn't want to continue
maintaining it. Thanks for all the good work in the past.
+ Use ${binary:Version} instead of ${Source-Version}.
+ Remove unnecessary build dependency on chrpath.
+ Build depend on autotools-dev.
* debian/control,
debian/compat:
+ Update to debhelper compat level 6 and Standards-Version 3.7.3.
* debian/bin:
+ Removed, not needed.
* debian/patches/01_liboil-linking.patch:
+ Link liboil against librt.
* debian/patches/02_ecx-clobbering.patch:
+ Add ecx to the clobbered registers on i386, fixes a crash with
pulseaudio. Patch taken from upstream GIT.
* debian/patches/03_jit-compilation.patch:
+ Don't compile the JIT example, this needs GLib.
* debian/patches/04_oil-detect-arm-non-static.patch:
+ Make the oil_cpu_detect_arch() function non-static to fix the build.
Patch taken from gstreamer-devel by Robert Schwebel.
Files:
144bad16aee0cda83a39b7bdda1e493a 724 devel optional liboil_0.3.13-1.dsc
97c22e4412ebb44e01565e35e0ae49c9 813995 devel optional
liboil_0.3.13.orig.tar.gz
29cf90ec38bafd232015c04867f96c9a 5871 devel optional liboil_0.3.13-1.diff.gz
0d5298a9351024df97285eefc903437e 124080 libs optional
liboil0.3_0.3.13-1_i386.deb
acbde9c00c67137083416dabccb27315 266686 libdevel optional
liboil0.3-dev_0.3.13-1_i386.deb
852e418857985bf1cf08a8097d4b6b82 297516 libdevel optional
liboil0.3-dbg_0.3.13-1_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHw8LsBsBdh1vkHyERAqKmAJ0SkA5oNMUbIquEUaUmFJrvbWaFjACgpBVv
mm2y0l96s8Bk8g5qspnz09c=
=B4m4
-END PGP SIGNATURE-
Accepted:
liboil0.3-dbg_0.3.13-1_i386.deb
to pool/main/libo/liboil/liboil0.3-dbg_0.3.13-1_i386.deb
liboil0.3-dev_0.3.13-1_i386.deb
to pool/main/libo/liboil/liboil0.3-dev_0.3.13-1_i386.deb
liboil0.3_0.3.13-1_i386.deb
to pool/main/libo/liboil/liboil0.3_0.3.13-1_i386.deb
liboil_0.3.13-1.diff.gz
to pool/main/libo/liboil/liboil_0.3.13-1.diff.gz
liboil_0.3.13-1.dsc
to pool/main/libo/liboil/liboil_0.3.13-1.dsc
liboil_0.3.13.orig.tar.gz
to pool/main/libo/liboil/liboil_0.3.13.orig.tar.gz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted orage 4.5.12.2-3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 26 Feb 2008 08:34:41 +0100 Source: orage Binary: orage Architecture: source amd64 Version: 4.5.12.2-3 Distribution: unstable Urgency: low Maintainer: Debian Xfce Maintainers [EMAIL PROTECTED] Changed-By: Yves-Alexis Perez [EMAIL PROTECTED] Description: orage - Calendar for Xfce Desktop Environment Closes: 465867 Changes: orage (4.5.12.2-3) unstable; urgency=low . * debian/NEWS: document new location for .ics files. closes: #465867 Files: 27b43bf2a24bc9da8d77800bd4b7d2a2 1034 x11 optional orage_4.5.12.2-3.dsc b43fbde3a6c6ccf2f0d577617a8f9bf2 11793 x11 optional orage_4.5.12.2-3.diff.gz 6782ea0ffbb5caee68f7b74bd19885cf 1486336 x11 optional orage_4.5.12.2-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHw8OqTUTAIMXAW64RAm8fAKCM9kEyOdJ6ZQbe/823Sr94bFghIwCeNx6J lv6j4wW3inYOV2QUfecgLeg= =CBa8 -END PGP SIGNATURE- Accepted: orage_4.5.12.2-3.diff.gz to pool/main/o/orage/orage_4.5.12.2-3.diff.gz orage_4.5.12.2-3.dsc to pool/main/o/orage/orage_4.5.12.2-3.dsc orage_4.5.12.2-3_amd64.deb to pool/main/o/orage/orage_4.5.12.2-3_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted claws-mail-extra-plugins 3.3.1-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 19:38:19 +0100 Source: claws-mail-extra-plugins Binary: claws-mail-extra-plugins claws-mail-extra-plugins-dbg claws-mail-vcalendar-plugin claws-mail-perl-filter claws-mail-feeds-reader claws-mail-mailmbox-plugin claws-mail-smime-plugin claws-mail-html2-viewer claws-mail-acpi-notifier claws-mail-attach-remover claws-mail-cache-saver claws-mail-fetchinfo-plugin claws-mail-newmail-plugin claws-mail-multi-notifier claws-mail-synce-plugin claws-mail-attach-warner claws-mail-pdf-viewer claws-mail-spam-report claws-mail-tnef-parser Architecture: source all amd64 Version: 3.3.1-1 Distribution: unstable Urgency: low Maintainer: Ricardo Mones [EMAIL PROTECTED] Changed-By: Ricardo Mones [EMAIL PROTECTED] Description: claws-mail-acpi-notifier - Laptop's Mail LED control for Claws Mail claws-mail-attach-remover - Mail attachment remover for Claws Mail claws-mail-attach-warner - Missing attachment warnings for Claws Mail claws-mail-cache-saver - Internal cache saver for Claws Mail mailer claws-mail-extra-plugins - Extra plugins collection for Claws Mail mailer claws-mail-extra-plugins-dbg - Debug symbols for Claws Mail Extra Plugins packages claws-mail-feeds-reader - Feeds (RSS/Atom) reader plugin for Claws Mail claws-mail-fetchinfo-plugin - X-FETCH headers adder for Claws Mail mailer claws-mail-html2-viewer - HTML mail/attachment viewer for Claws Mail mailer claws-mail-mailmbox-plugin - mbox format mailboxes handler for Claws Mail mailer claws-mail-multi-notifier - A variety of new mail notifiers for Claws Mail claws-mail-newmail-plugin - New mail logger plugin for Claws Mail mailer claws-mail-pdf-viewer - PDF and PostScript viewer for Claws Mail claws-mail-perl-filter - Message filtering plugin using perl for Claws Mail claws-mail-smime-plugin - S/MIME signature/encryption handling for Claws Mail claws-mail-spam-report - Spam reporting plugin for Claws Mail claws-mail-synce-plugin - Addressbook synchronization with Windows CE devices claws-mail-tnef-parser - TNEF attachment handler for Claws Mail claws-mail-vcalendar-plugin - vCalendar message handling plugin for Claws Mail Closes: 461189 Changes: claws-mail-extra-plugins (3.3.1-1) unstable; urgency=low . * New upstream release * debian/control - Recommend notification-daemon instead depend (Closes: #461189) - Bumped required libclaws-mail-dev version Files: e86498438120fb8082a89c96f9e55b20 1465 mail optional claws-mail-extra-plugins_3.3.1-1.dsc 632c7ae7505d1a189ad23043ed3ce4b3 6902629 mail optional claws-mail-extra-plugins_3.3.1.orig.tar.gz 4c5a3cac3a2996ed5973fcd7f478f066 25978 mail optional claws-mail-extra-plugins_3.3.1-1.diff.gz 54e4778828c1ee7bbed4515b568523dc 8620 mail optional claws-mail-extra-plugins_3.3.1-1_all.deb 642d56cf60c7f520a63b2d8f0854004e 1581276 mail extra claws-mail-extra-plugins-dbg_3.3.1-1_amd64.deb 7269974bbed0b57e583ed0efd2e6fb27 262930 mail optional claws-mail-vcalendar-plugin_3.3.1-1_amd64.deb cfb969d70995ca2c438ad79a20faf069 50106 mail optional claws-mail-perl-filter_3.3.1-1_amd64.deb 4ac5595b3bfd43ba6b8906229d660e15 91216 mail optional claws-mail-feeds-reader_3.3.1-1_amd64.deb 9df4701754750b37a86f4853ee1a577a 60174 mail optional claws-mail-mailmbox-plugin_3.3.1-1_amd64.deb 4fd2e6853523c4bbf24165025ccbc784 18934 mail optional claws-mail-smime-plugin_3.3.1-1_amd64.deb 8f13a644834665add239b7250e69ad24 37072 mail optional claws-mail-html2-viewer_3.3.1-1_amd64.deb 100f795c74aabea71101e3da56fbdbd4 28132 mail optional claws-mail-acpi-notifier_3.3.1-1_amd64.deb 6b3d0ffc157dd32557831b4b2af60deb 11246 mail optional claws-mail-attach-remover_3.3.1-1_amd64.deb 51bbebaaff75c6d63b9307004e6244bb 9252 mail optional claws-mail-cache-saver_3.3.1-1_amd64.deb 21e8a16afb2aabe38f9a73ad0c2d6799 15032 mail optional claws-mail-fetchinfo-plugin_3.3.1-1_amd64.deb 0993e4b9ba5227b00f02127271503838 10698 mail optional claws-mail-newmail-plugin_3.3.1-1_amd64.deb 1b1797ea033e9dc96b67b0e582d7aad3 74144 mail optional claws-mail-multi-notifier_3.3.1-1_amd64.deb 7dfcc4fbf133a15daa80c58c5442aade 15984 mail optional claws-mail-synce-plugin_3.3.1-1_amd64.deb 1c9e6b72c49aa3625ddc606ce0a10553 23516 mail optional claws-mail-attach-warner_3.3.1-1_amd64.deb 1b0ef57f878887d5c101421ea4beafcd 44828 mail optional claws-mail-pdf-viewer_3.3.1-1_amd64.deb cb33ea3f0e43f5f22583fee20dd4a1f6 19028 mail optional claws-mail-spam-report_3.3.1-1_amd64.deb 93b6a034718f13947a7942fd61866e3b 20744 mail optional claws-mail-tnef-parser_3.3.1-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHw9FQLARVQsm1XawRAh7NAJ438qherYBnqVcnoZ2AOhXwrOcPFQCgk6KL aTRd2RqQUWv0Z6vRms+NQvs= =HSHh -END PGP SIGNATURE- Accepted: claws-mail-acpi-notifier_3.3.1-1_amd64.deb to pool/main/c/claws-mail-extra-plugins/claws-mail-acpi-notifier_3.3.1-1_amd64.deb claws-mail-attach-remover_3.3.1-1_amd64.deb to
Accepted gstreamermm 0.9.4-2 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 26 Feb 2008 11:27:21 +0800 Source: gstreamermm Binary: libgstreamermm-0.10-2 libgstreamermm-0.10-dev libgstreamermm-0.10-dbg libgstreamermm-0.10-doc Architecture: source all i386 Version: 0.9.4-2 Distribution: experimental Urgency: low Maintainer: Deng Xiyue [EMAIL PROTECTED] Changed-By: Deng Xiyue [EMAIL PROTECTED] Description: libgstreamermm-0.10-2 - C++ wrapper library for the multimedia library GStreamer (shared libgstreamermm-0.10-dbg - C++ wrapper library for the multimedia library GStreamer (debug s libgstreamermm-0.10-dev - C++ wrapper library for the multimedia library GStreamer (develop libgstreamermm-0.10-doc - C++ wrapper library for the multimedia library GStreamer (documen Changes: gstreamermm (0.9.4-2) experimental; urgency=low . * Use common-install-impl rule instead of common-install-prehook-arch, the latter might be triggered before `make install` was called. Should fix FTBFS on buildds. Files: df6529a251e52fa0bc78fffe4f923ed4 1104 libs optional gstreamermm_0.9.4-2.dsc 2cb7c34a8119689ac24e6504db9242b5 11881 libs optional gstreamermm_0.9.4-2.diff.gz c4f456cca180f16a55fb2c620a370ccb 490416 doc optional libgstreamermm-0.10-doc_0.9.4-2_all.deb 2339523bcff870ce6ae144a06065563d 138012 libs optional libgstreamermm-0.10-2_0.9.4-2_i386.deb e7fe9e414626302487f767de35420934 199344 libdevel optional libgstreamermm-0.10-dev_0.9.4-2_i386.deb 4d66d45edf65b25de7caa71ef88fe65a 721788 libdevel extra libgstreamermm-0.10-dbg_0.9.4-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHw8YvBsBdh1vkHyERAv0zAKCTPUCRy3BP37qYIuAoUwcbYY+1XQCgj7J+ 6KzMmdXeLPjnCKXLW9on5Mk= =3wBR -END PGP SIGNATURE- Accepted: gstreamermm_0.9.4-2.diff.gz to pool/main/g/gstreamermm/gstreamermm_0.9.4-2.diff.gz gstreamermm_0.9.4-2.dsc to pool/main/g/gstreamermm/gstreamermm_0.9.4-2.dsc libgstreamermm-0.10-2_0.9.4-2_i386.deb to pool/main/g/gstreamermm/libgstreamermm-0.10-2_0.9.4-2_i386.deb libgstreamermm-0.10-dbg_0.9.4-2_i386.deb to pool/main/g/gstreamermm/libgstreamermm-0.10-dbg_0.9.4-2_i386.deb libgstreamermm-0.10-dev_0.9.4-2_i386.deb to pool/main/g/gstreamermm/libgstreamermm-0.10-dev_0.9.4-2_i386.deb libgstreamermm-0.10-doc_0.9.4-2_all.deb to pool/main/g/gstreamermm/libgstreamermm-0.10-doc_0.9.4-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libmicrohttpd 0.2.1-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 26 Feb 2008 10:26:00 +0100 Source: libmicrohttpd Binary: libmicrohttpd3 libmicrohttpd-dbg libmicrohttpd-dev Architecture: source i386 Version: 0.2.1-2 Distribution: unstable Urgency: low Maintainer: Daniel Baumann [EMAIL PROTECTED] Changed-By: Daniel Baumann [EMAIL PROTECTED] Description: libmicrohttpd-dbg - library embedding HTTP server functionality (debug) libmicrohttpd-dev - library embedding HTTP server functionality (development) libmicrohttpd3 - library embedding HTTP server functionality Changes: libmicrohttpd (0.2.1-2) unstable; urgency=low . * Adding vcs fields in control. * Rewriting copyright in machine-interpretable format. * Removing watch file. * Bumping shlibs to 0.2.1. * Rewritten rules. Files: 47f7f5e26af2d5ccfd53a42d4fbb1ec1 880 libs optional libmicrohttpd_0.2.1-2.dsc 3dda31f9ce74af8b4970f21556204283 2186 libs optional libmicrohttpd_0.2.1-2.diff.gz 6dd2b2326b3c99ac77b229dfc3dc1dd5 21216 libs optional libmicrohttpd3_0.2.1-2_i386.deb b2b77647e3a4f01f079cd971cbf2eb32 30086 devel extra libmicrohttpd-dbg_0.2.1-2_i386.deb 048cc154e642e5e0f520cb93b0ee1af0 30636 libdevel optional libmicrohttpd-dev_0.2.1-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHw9uE+C5cwEsrK54RAlpaAJ0SjVvkq8zgZ8KqIs+INK0wdxlDaACbB5oG CZe2SL2h9jD4QKFG+rcIrM0= =QRd9 -END PGP SIGNATURE- Accepted: libmicrohttpd-dbg_0.2.1-2_i386.deb to pool/main/libm/libmicrohttpd/libmicrohttpd-dbg_0.2.1-2_i386.deb libmicrohttpd-dev_0.2.1-2_i386.deb to pool/main/libm/libmicrohttpd/libmicrohttpd-dev_0.2.1-2_i386.deb libmicrohttpd3_0.2.1-2_i386.deb to pool/main/libm/libmicrohttpd/libmicrohttpd3_0.2.1-2_i386.deb libmicrohttpd_0.2.1-2.diff.gz to pool/main/libm/libmicrohttpd/libmicrohttpd_0.2.1-2.diff.gz libmicrohttpd_0.2.1-2.dsc to pool/main/libm/libmicrohttpd/libmicrohttpd_0.2.1-2.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gtkmm2.4 1:2.12.5-2 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 26 Feb 2008 11:11:26 +0800 Source: gtkmm2.4 Binary: libgtkmm-2.4-dev libgtkmm-2.4-1c2a libgtkmm-2.4-dbg libgtkmm-2.4-doc Architecture: source all i386 Version: 1:2.12.5-2 Distribution: unstable Urgency: low Maintainer: Deng Xiyue [EMAIL PROTECTED] Changed-By: Deng Xiyue [EMAIL PROTECTED] Description: libgtkmm-2.4-1c2a - C++ wrappers for GTK+ 2.4 (shared libraries) libgtkmm-2.4-dbg - C++ wrappers for GTK+ 2.4 (debug symbols) libgtkmm-2.4-dev - C++ wrappers for GTK+ 2.4 (development files) libgtkmm-2.4-doc - C++ wrappers for GTK+ 2.4 (documentation) Changes: gtkmm2.4 (1:2.12.5-2) unstable; urgency=low . * Use common-install-impl rule instead of common-install-prehook-arch, the latter might be triggered before `make install` was called. Should fix FTBFS on buildds. * It turns out .svn dirs are not shipped in, but keep DEB_DH_ALWAYS_EXCLUDE for now as precaution and reminder. Files: b1ea137ede8a42c041e08c7d7c0cf46b 1090 libs optional gtkmm2.4_2.12.5-2.dsc 618d37df652dd90ba2517b9d7ba5ac68 5519 libs optional gtkmm2.4_2.12.5-2.diff.gz e2a662e9523bd431285888d05fd26fe0 13954042 doc optional libgtkmm-2.4-doc_2.12.5-2_all.deb 8098574ffd06bac2818653cf4fd7f8b9 2230102 libdevel optional libgtkmm-2.4-dev_2.12.5-2_i386.deb 09cd2c92e4e7e1d4e0ede946c30d6095 1221592 libs optional libgtkmm-2.4-1c2a_2.12.5-2_i386.deb 8ec15bf5b5bebeff11167d5c55956798 7241104 libdevel extra libgtkmm-2.4-dbg_2.12.5-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHw85hBsBdh1vkHyERAtXxAJwPsi29K2fdw9V5HMvLOOOyzkhAaACfRRc6 J0m+Ho7DGizsZ74kFFb5hqw= =KvUn -END PGP SIGNATURE- Accepted: gtkmm2.4_2.12.5-2.diff.gz to pool/main/g/gtkmm2.4/gtkmm2.4_2.12.5-2.diff.gz gtkmm2.4_2.12.5-2.dsc to pool/main/g/gtkmm2.4/gtkmm2.4_2.12.5-2.dsc libgtkmm-2.4-1c2a_2.12.5-2_i386.deb to pool/main/g/gtkmm2.4/libgtkmm-2.4-1c2a_2.12.5-2_i386.deb libgtkmm-2.4-dbg_2.12.5-2_i386.deb to pool/main/g/gtkmm2.4/libgtkmm-2.4-dbg_2.12.5-2_i386.deb libgtkmm-2.4-dev_2.12.5-2_i386.deb to pool/main/g/gtkmm2.4/libgtkmm-2.4-dev_2.12.5-2_i386.deb libgtkmm-2.4-doc_2.12.5-2_all.deb to pool/main/g/gtkmm2.4/libgtkmm-2.4-doc_2.12.5-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cl-who 0.11.0-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 21 Feb 2008 06:58:22 +0100 Source: cl-who Binary: cl-who Architecture: source all Version: 0.11.0-2 Distribution: unstable Urgency: low Maintainer: Debian Common Lisp Team [EMAIL PROTECTED] Changed-By: Peter Van Eynde [EMAIL PROTECTED] Description: cl-who - Common Lisp HTML generator Changes: cl-who (0.11.0-2) unstable; urgency=low . * Changed to group maintanance * Corrected Vcs-Git control field * Added Homepage field * swap binary-arch and binary-indep * updated standard version without real changes * Fixed cl-cl-who typo Files: f83dd8210a915cae0f5bf6d46ff9ecf9 771 devel optional cl-who_0.11.0-2.dsc c0377d69998152f8e39e2abfc7fa29ec 2832 devel optional cl-who_0.11.0-2.diff.gz daff46041fa28ff7b9a438ad9f929f0e 22852 devel optional cl-who_0.11.0-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHvSLd11ldN0tyliURAh7vAKCi8hioiJKSQFCGo4KpI0pqA2zQxQCgiWsP gHPMLKghaC4giafZLk0sY4E= =DAs4 -END PGP SIGNATURE- Accepted: cl-who_0.11.0-2.diff.gz to pool/main/c/cl-who/cl-who_0.11.0-2.diff.gz cl-who_0.11.0-2.dsc to pool/main/c/cl-who/cl-who_0.11.0-2.dsc cl-who_0.11.0-2_all.deb to pool/main/c/cl-who/cl-who_0.11.0-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gpsk31 0.3.2-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 21:29:36 +0100 Source: gpsk31 Binary: gpsk31 Architecture: source i386 Version: 0.3.2-1 Distribution: unstable Urgency: low Maintainer: Joop Stakenborg [EMAIL PROTECTED] Changed-By: Joop Stakenborg [EMAIL PROTECTED] Description: gpsk31 - A gtk based psk31 Closes: 466850 Changes: gpsk31 (0.3.2-1) unstable; urgency=low . * New upstream release. * Fixes buffer overflow reading config file. Closes: #466850. * New maintainer. * Add Uploaders field to the control file with Carlos Barros, who is the previous maintainer and me (upstream maintainer). * Menu transition. * Several lintian fixes. * Remove debian manual page, is now provided upstream. * Remove README from the docs, it is provided upstream in /usr/share/gpsk31 and also available through the Help menu. Files: 78656743d4bba52885f03f4045e1469d 669 hamradio optional gpsk31_0.3.2-1.dsc 358634716bf458fa5e6730af85081036 165318 hamradio optional gpsk31_0.3.2.orig.tar.gz cd6bd0418a776550a640d8bf3a53fde8 17992 hamradio optional gpsk31_0.3.2-1.diff.gz 0543bc44e90e6eee89b987f538588ac7 51878 hamradio optional gpsk31_0.3.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHw9Su/CqtjGLxpX8RAovFAKCCN5Iq1Xuxozoq2xctgS6logWk9ACgnoIn w/8wby3cLRDFuY7njInppSU= =KWx0 -END PGP SIGNATURE- Accepted: gpsk31_0.3.2-1.diff.gz to pool/main/g/gpsk31/gpsk31_0.3.2-1.diff.gz gpsk31_0.3.2-1.dsc to pool/main/g/gpsk31/gpsk31_0.3.2-1.dsc gpsk31_0.3.2-1_i386.deb to pool/main/g/gpsk31/gpsk31_0.3.2-1_i386.deb gpsk31_0.3.2.orig.tar.gz to pool/main/g/gpsk31/gpsk31_0.3.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
