Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation
Package: wnpp Severity: wishlist Owner: "Alejandro Rios P." <[EMAIL PROTECTED]> * Package name: libming-fonts-openoffice Version : 0.1 Upstream Author : OpenOffice.org * URL : http://www.openoffice.org/ * License : GPL Description : Fonts for use with the Ming Library for SWF Creation These are the OpenOffice Fonts converted for use with libming, .which is a library for SWF (Flash) File creation. .These fonts canNOT be used with X11 or for printing. -- System Information: Debian Release: testing/unstable APT prefers breezy-updates APT policy: (500, 'breezy-updates'), (500, 'breezy-security'), (500, 'breezy') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-9-686 Locale: LANG=es_CO.UTF-8, LC_CTYPE=es_CO.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [HELP] FTBFS on alpha for xulrunner
On Tue, Aug 08, 2006 at 07:57:40AM +0200, Mike Hommey wrote: > PyGBase.cpp: In member function 'nsresult > PyG_Base::InvokeNativeGetViaPolicy(const char*, PyObject**)': > PyGBase.cpp:613: error: no matching function for call to > 'PyG_Base::InvokeNativeViaPolicyInternal(char [256], PyObject**&, int, int)' > PyGBase.cpp:563: note: candidates are: nsresult > PyG_Base::InvokeNativeViaPolicyInternal(const char*, PyObject**, const char*, > va_list) > make[5]: *** [PyGBase.o] Error 1 > > The code at PyGBase.cpp:613 reads: > ret = InvokeNativeViaPolicyInternal(buf, ppResult, nsnull, nsnull); This is not valid. va_list is no pointer, it is an opaque type > Maybe it's the va_args implementation on alpha that somehow differs ? Exactly. Alpha implements it as a struct. Bastian -- Without followers, evil cannot spread. -- Spock, "And The Children Shall Lead", stardate 5029.5 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation
Hi, Am Dienstag, den 08.08.2006, 02:28 -0500 schrieb Alejandro Rios P.: > .These fonts canNOT be used with X11 or for printing. I suggest writing this as 'can NOT'. It's easier to parse and (with the idea of descriptions' translations in mind) comes closer to what happens in a translation -- at least for the languages I know. Regards Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Pan in Sid
Hi list,
I have notice yesterday that the version of Pan has been change to the
coming Pan version 2. For many reasons I find this a very annoying
decision, but these two reasons should cause it to be immediately
removed from the repository:
1) It is VERY unstable - constant freezes and crashes
2) When installing the old settings from Pan 1.x is not merge with Pan
2.x in which case your settings are either lost or you have to merge
all settings manually.
I hope the version of Pan is removed by the end of the day!
--
Hilsen/Regards
Michael Rasmussen
Get my public GnuPG keys:
michael rasmussen cc
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E
mir datanom net
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C
mir miras org
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
--
die_if_kernel("Penguin instruction from Penguin mode??!?!", regs);
linux-2.2.16/arch/sparc/kernel/traps.c
pgpyeoXeeuvLY.pgp
Description: PGP signature
Re: Bug#381568: ITP: med-fichier -- Library to exchange meshed data
--- Miles Bader <[EMAIL PROTECTED]> escribió: > Andreas Tille <[EMAIL PROTECTED]> writes: > > but some kind of strange feeling continues if I hear this name (and > > the translation of it). It's just misleading. > > Er, just because you have a "strange feeling" doesn't mean the name is > misleading. > > "Med" is pretty ambiguous. _I_ certainly don't have any immediate > reaction that it contains "medical software," and I don't think it's a > generally used abbreviation for medical in the wider population -- > indeed I'm not sure even the long phrase "medical software" has much > meaning in the abstract; what would a user think it is?? When I saw the ITP, I was totally convinced it was medical-related software. I don't think it's that unusual to think that. Just my 2 cents, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation
Am Dienstag, 8. August 2006 09:28 schrieb Alejandro Rios P.: > * Package name: libming-fonts-openoffice > Version : 0.1 > Upstream Author : OpenOffice.org > * URL : http://www.openoffice.org/ > * License : GPL > Description : Fonts for use with the Ming Library for SWF Creation > > These are the OpenOffice Fonts converted for use with libming, Which OpenOffice Fonts? OpenSymbol? The other fonts included in OOo is ttf-bitstream-vera, Not to mention the program is named OpenOffice.org. WITH the .org. For trademark reasons. So *if* you reintroduce this package (see below) please name it correctly. And more importantly: [Date: Mon, 12 Jan 2004 22:30:29 -0500] [ftpmaster: James Troup] Removed the following packages from unstable: libming | 0.2a.cvs20030716-2 | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc libming-dev | 0.2a.cvs20030716-2 | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc libming-fonts-openoffice | 0.1-2 | source, all libming-util | 0.2a.cvs20030716-2 | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc libswf-perl | 0.2a.cvs20030716-2 | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc php4-ming | 0.2a.cvs20030716-2 | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc python2.1-ming | 0.2a.cvs20030716-2 | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc python2.2-ming | 0.2a.cvs20030716-2 | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc Closed bugs: 166973 166990 --- Reason --- RoQA; orphaned, dead upstream, grave bugs, unused. -- Did that change? Did you fix the grave bugs? Regards, Rene -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73
Re: Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation
Am Dienstag 08 August 2006 09:28 schrieb Alejandro Rios P.: > Package: wnpp > Severity: wishlist > Owner: "Alejandro Rios P." <[EMAIL PROTECTED]> > > * Package name: libming-fonts-openoffice > Version : 0.1 > Upstream Author : OpenOffice.org > * URL : http://www.openoffice.org/ > * License : GPL > Description : Fonts for use with the Ming Library for SWF Creation > > These are the OpenOffice Fonts converted for use with libming, > .which is a library for SWF (Flash) File creation. > .These fonts canNOT be used with X11 or for printing. Are those fonts manually converted? If not, wouldn't it be better to convert them as needed instead of yet-another-incompatible-font-package? (In which package are the OpenOffice Fonts?). HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Successful and unsuccessful Debian development tools
Hi, On Mon, 07.08.2006 at 12:52:26 +0100, martin f krafft <[EMAIL PROTECTED]> wrote: > also sprach Toni Mueller <[EMAIL PROTECTED]> [2006.08.07.1126 +0100]: > > what are your problems with CDBS? > http://lists.debian.org/debian-devel/2006/06/msg00451.html > http://lists.debian.org/debian-devel/2006/06/msg00467.html hmmm, for me, CDBS feels very much like BSD's ports system. That notwithstanding, it could be enhanced (what couldn't?). Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Pan in Sid
Hello Michael, > I have notice yesterday that the version of Pan has been change to the > coming Pan version 2. For many reasons I find this a very annoying > decision, but these two reasons should cause it to be immediately > removed from the repository: > > 1) It is VERY unstable - constant freezes and crashes > 2) When installing the old settings from Pan 1.x is not merge with Pan > 2.x in which case your settings are either lost or you have to merge > all settings manually. > > I hope the version of Pan is removed by the end of the day! Thank you for your concern. I'm not sure which Debian package you're talking about specifically. However, such concerns should be taken up with the maintainer, through the way of filing a bug report. Please file specific reports only, not "crashes constantly" but specifically when you're experiencing a crash so it can be dealt with. The maintainer or the release team can decide on the basis of bug reports that a specific version is not suitable for our next release and will not be shipped. But it starts with filing those reports. http://bugs.debian.org contains instructions on filing them. Good luck! Thijs Kinkhorst signature.asc Description: This is a digitally signed message part
Re: Bug#381201: ITP: reniced -- renice running processes based on regular expressions
Josselin Mouette wrote:
> Le mercredi 02 août 2006 à 23:15 +0200, Bart Martens a écrit :
> > Instead of editing the scripts in /etc/init.d to give daemons the
> > nicelevel you want (and get prompted at every package update because
> > these files are conffiles) you can just run reniced once a day.
>
> Out of curiosity, what real-life uses does this tool have? Daemons don't
> need to be reniced, so there must be something else.
Actually, I wonder if this really warrants a package on its own; AFAICS
it just adds some sugar and error checking to something as basic as
,[ reniced.sh ]
| #!/bin/bash
| grep -v '^#' "${1:-$HOME/.reniced" |
| while read prio regex; do
| renice $prio $(pgrep "$regex")
| done
`
... which is something I'd expect to find in ~/bin, but not as the
single functionality of a Debian package.
Nikolaus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#381201: ITP: reniced -- renice running processes based on regular expressions
Nikolaus Schulz, 2006-08-08 11:50:08 +0200 : > ... which is something I'd expect to find in ~/bin, but not as the > single functionality of a Debian package. moreutils then? Roland. -- Roland Mas If you're ever confused as to which mode you're in, keep entering the key until vi beeps at you. -- nvi manual page. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Pan in Sid
At 1155032605 past the epoch, Michael Rasmussen wrote: > I have notice yesterday that the version of Pan has been > change to the coming Pan version 2. For many reasons I > find this a very annoying decision This was discussed on -devel prior to the decision being made. I suggest you read up on that thread (root msg id [EMAIL PROTECTED]) to understand the rationale of the decision and then take it up with the maintainer if you still disagree. -- Jon Dowland http://alcopop.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_python and python policy analysis
Le mar 8 août 2006 00:18, Pierre Habouzit a écrit : > § 2.3.3, 2.4.2, 2.5.3, 2.6.2: > *here* the python$version alternative is correct, > because /extensions/ can be used with a '/usr/bin/python' as soon > as the python current version is in their supported range. > > so take the previous algorithm, and add to (2): if current python > version isn't in that range, add an alternative to the pythonX.Y > corresponding to the range lower bound. Meaning that in my test > cases, instead of *SHOULD NOT HAPPEN* you will get: > > python (>= 2.4) | python2.4 > > and in fact, wrt Depends, the algorithm for pure modules or > extensions, private or public is the same. I forgot to explicitely mention that when extensions are in the package, then you have to restrict your 'python' range to the range of the python for which extensions have been built. That seems obvious, but it has to be stated in the policy very clearly. That means that if you ship a .so for e.g. 2.3, 2.4, then your python depends will be: python (>= 2.3), python (<< 2.5) even if the pyversions is 2.1- about debian/pyversions, unlike his brother XS-P-V it does not supports all/current. for python support you have to use sth like 2.1-. current explicitely says that the package is only built for the current python version, and not for any other supported in debian. But I don't like that value for the following reasons: * it says for what the package is built, whereas other values explain for which range of python versions the package is build-able, so semanticaly it's not homogenous ; * it prevents the packager to explain with which python versions the package is compatible, as saying 'current' suggests that the package is now compatible with the current python version, and will always in the future, wich may be wrong when (if that happen) some python 3.0 that is not 100% backward compatible should exists ; * it also give an information we already have as a package that is built for the current python version should depend upon python-dev and not python-all-dev ; * current has not a constant meaning, as it depends of the state of the package python-defaults, and not only of the state of the archive when the package was uploaded. This is IMHO the biggest flaw of that field value. so IMHO the "current" value should be documented as an internal pycentral value, and should not be recommended to be used for other ways of python packaging. OTOH, I thing "pysupport" should also support "all" as it's prettier than 2.1- and more explicit to the packager, and then it could go into the policy as a recomended value in that case. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpkEcXWLwifH.pgp Description: PGP signature
Re: Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation
On Tue, 8 Aug 2006, Rene Engelhard wrote: Am Dienstag, 8. August 2006 09:28 schrieb Alejandro Rios P.: * Package name: libming-fonts-openoffice Version : 0.1 Upstream Author : OpenOffice.org * URL : http://www.openoffice.org/ * License : GPL Description : Fonts for use with the Ming Library for SWF Creation These are the OpenOffice Fonts converted for use with libming, I already have package for these fonts prepared as part of the ming sounrce package, and am awaiting some feedback from some of the packages that will use them. Feedback from others would be welcome as well. deb http://www4.netsweng.com/~anderson/ming-unstable/ binary/ [Date: Mon, 12 Jan 2004 22:30:29 -0500] [ftpmaster: James Troup] Removed the following packages from unstable: --- Reason --- RoQA; orphaned, dead upstream, grave bugs, unused. -- Did that change? Did you fix the grave bugs? I have adopted the libming packages, and there has been a new version in unstable for a few weeks now. Stuart Stuart R. Anderson [EMAIL PROTECTED] Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation
On Tue, 8 Aug 2006, Hendrik Sattler wrote: Are those fonts manually converted? If not, wouldn't it be better to convert them as needed instead of yet-another-incompatible-font-package? The long term plan is for libming to be able to read in TTF fonts directly, but that's not there yet. Stuart Stuart R. Anderson [EMAIL PROTECTED] Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation
Hi, Am Dienstag, 8. August 2006 14:13 schrieb Stuart Anderson: > On Tue, 8 Aug 2006, Hendrik Sattler wrote: > > > Are those fonts manually converted? If not, wouldn't it be better to convert > > them as needed instead of yet-another-incompatible-font-package? > > The long term plan is for libming to be able to read in TTF fonts directly, > but that's not there yet. YOu didn't answer his question. Are they manually converted? Or how are they converted? Can they be converted during-build of some other package (where the fonts are from, when there's OOo fonts I mean ttf-opensymbol and ttf-bitstream-vera). Regards, Rene -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73
Re: Successful and unsuccessful Debian development tools
On Tue, Aug 08, 2006 at 11:02:15AM +0200, Toni Mueller wrote: > On Mon, 07.08.2006 at 12:52:26 +0100, martin f krafft <[EMAIL PROTECTED]> > wrote: > > also sprach Toni Mueller <[EMAIL PROTECTED]> [2006.08.07.1126 +0100]: > > > what are your problems with CDBS? > > http://lists.debian.org/debian-devel/2006/06/msg00451.html > > http://lists.debian.org/debian-devel/2006/06/msg00467.html > > hmmm, for me, CDBS feels very much like BSD's ports system. > > That notwithstanding, it could be enhanced (what couldn't?). The problem some people see with CDBS is that you can't really see how a package will build from looking at debian/rules, instead you have to look it up in /usr/share/cdbs. That's not much of a problem with your own packages usually, but it can be unnerving if you're doing RC bugsquashing, looking at 10 packages per day, trying to figure out why something doesn't build. However pushing out as much build logic as possible from debian/rules is a central concept of CDBS, so this unlikely to ever change. Cheers, Christian Aichinger PS: We've already had this discussion, so let's try to skip the flamewar this time, can we? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation
On Tue, 8 Aug 2006, Rene Engelhard wrote: Are those fonts manually converted? YOu didn't answer his question. Fair enough. The coffee hadn't quite kicked in yet. 8-) Are they manually converted? Or how are they converted? I wasn't sure what Alejandro had in mind, so I didn't want to answer for him. In the past however, that package was made from some fonts that were manually converted and uploaded to the ming FTP site. The tool that was used for that conversion a few years ago has suffered some bitrot. Can they be converted during-build of some other package (where the fonts are from, when there's OOo fonts I mean ttf-opensymbol and ttf-bitstream-vera). Yes, the packages I have prepared are built as part of the rest of the ming package. The ming source package Build-depends on the package that contains the TTF fonts that will be converted into a libming font package. Upstream ming (and the libming-util package) now includes an updated version of the tool that is used to convert the fonts. It is now trivial to create additional libming format font packages, so some of the feedback I'd like to receive, is which fonts would it be useful to have already converted and packaged. Stuart Stuart R. Anderson [EMAIL PROTECTED] Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation
Am Dienstag, 8. August 2006 14:47 schrieb Stuart Anderson: > Yes, the packages I have prepared are built as part of the rest of the > ming package. The ming source package Build-depends on the package that > contains the TTF fonts that will be converted into a libming font package. > Upstream ming (and the libming-util package) now includes an updated version > of the tool that is used to convert the fonts. OK. Now, I fetched your -openoffice pakcage and saw that (as I guessed) it just does OpenSymbol. Can you please name it -opensymbol (to show that it is the opensymbol font from ttf-opensymbol) then? Regards, Rene -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73
Re: Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation
close 381992 thanks Am Dienstag, 8. August 2006 14:11 schrieb Stuart Anderson: > On Tue, 8 Aug 2006, Rene Engelhard wrote: > > > Am Dienstag, 8. August 2006 09:28 schrieb Alejandro Rios P.: > >> * Package name: libming-fonts-openoffice > >> Version : 0.1 > >> Upstream Author : OpenOffice.org > >> * URL : http://www.openoffice.org/ > >> * License : GPL > >> Description : Fonts for use with the Ming Library for SWF Creation > >> > >> These are the OpenOffice Fonts converted for use with libming, > > > I already have package for these fonts prepared as part of the ming > sounrce package, and am awaiting some feedback from some of the packages > that will use them. Feedback from others would be welcome as well. > > deb http://www4.netsweng.com/~anderson/ming-unstable/ binary/ So Alejandros ITP is bogus. I feel free to close it then. Alejandro (in case you read that in the buglog since your §%&§ mailserver doesn't accept mail): The libming maintainer (especially when those font packages come out of the ming source pkg) is the best person to maintain this. Especially as there's a tool to build those fonts proper. > > [Date: Mon, 12 Jan 2004 22:30:29 -0500] [ftpmaster: James Troup] > > Removed the following packages from unstable: > > > > --- Reason --- > > RoQA; orphaned, dead upstream, grave bugs, unused. > > -- > > > > Did that change? Did you fix the grave bugs? > > I have adopted the libming packages, and there has been a new version in > unstable for a few weeks now. Ah, yes. That makes the ITP obsolete since*if* this is to be packages it should be either from libming (which Stuart maintains) or on-the-fly converted from the font packages it's based on. But this doesn't answer whether the grave bugs in the fonts was fixed. Alejandro ITPed 0.1 again which supposedly to that removal log has those grave bugs. Or that might be libming only, I don't know.. But in any case, this were pre-connverted things afaik... In the meanwhile, you answered on -devel that it's generated during the build from opens___.ttf (which is the only font there). Please name it -opensymbol. So Alejandros ITP is bogus. I feel free to close it then. Regards, Rene -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73
Bug#382026: RFH: apt-show-versions -- lists available package versions with distribution
Package: wnpp Severity: normal I request assistance with maintaining the apt-show-versions package. The package description is: apt-show-versions parses the dpkg status file and the APT lists for the installed and available package versions and distribution and shows upgrade options within the specific distribution of the selected package. . This is really useful if you have a mixed stable/testing environment and want to list all packages which are from testing and can be upgraded in testing. The package is a native Debian package and needs some more programming. There are some open issues in the bug reports and feature requests. One thing would be the integration of backports.org. I need some help here with the programming and the finding of the bugs, because I have to few time at the moment. We should really have a fixed version of apt-show-versions in etch. Christoph -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (99, 'testing'), (50, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-3-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation
On Tue, 8 Aug 2006, Rene Engelhard wrote: OK. Now, I fetched your -openoffice pakcage and saw that (as I guessed) it just does OpenSymbol. Can you please name it -opensymbol (to show that it is the opensymbol font from ttf-opensymbol) then? Yes, that would be a better naming scheme. I was a little bit concerned with the migration path for anyone that had the old package installed, but I suppose the right set of Conflicts/Replaces/Provides would cover that? Stuart Stuart R. Anderson [EMAIL PROTECTED] Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation
Am Dienstag, 8. August 2006 15:10 schrieb Stuart Anderson: > On Tue, 8 Aug 2006, Rene Engelhard wrote: > > > OK. Now, I fetched your -openoffice pakcage and saw that (as I guessed) it > > just does OpenSymbol. Can you please name it -opensymbol (to show that it > > is the opensymbol font from ttf-opensymbol) then? > > Yes, that would be a better naming scheme. I was a little bit concerned > with the migration path for anyone that had the old package installed, > but I suppose the right set of Conflicts/Replaces/Provides would cover > that? stable doesn't have the package anymore and oldstable is unsupported. And dist-upgrades skipping one release is not supported. But yes, I think so. If not, you can add a transitional package, although I won't like it because of the "bogus" name... Regards, Rene -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73
Re: Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation
On Tue, 8 Aug 2006, Rene Engelhard wrote: stable doesn't have the package anymore and oldstable is unsupported. And dist-upgrades skipping one release is not supported. But yes, I think so. If not, you can add a transitional package, although I won't like it because of the "bogus" name... So this should cover it? Package: ming-fonts-opensymbol Conflicts: ming-fonts-openoffice Replaces: ming-fonts-openoffice Provides: ming-fonts-openoffice Interestingly, the ttf-opensymbol package places the font in the openoffice directory. /usr/share/fonts/truetype/openoffice/opens___.ttf Does this need to be fixed? I have my package putting its results in the same directory name (only the last part, the parent parent directory is different) as is used for the ttf files, but I think I can fix that easily enough for libming-fonts-opensymbol. Stuart Stuart R. Anderson [EMAIL PROTECTED] Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation
Hi, Am Dienstag, 8. August 2006 15:32 schrieb Stuart Anderson: > So this should cover it? > > Package: ming-fonts-opensymbol > Conflicts: ming-fonts-openoffice > Replaces: ming-fonts-openoffice > Provides: ming-fonts-openoffice No, Replaces:/Povides:/Conflicts: libming-... ^^^ important, because woody's package is named like that. for packages not yet in the archive (your ming-* you can do that but you don't need to; but you *need* the lib there) > Interestingly, the ttf-opensymbol package places the font in the > openoffice directory. > > /usr/share/fonts/truetype/openoffice/opens___.ttf > > Does this need to be fixed? Yeah, we could make that opensymbol, good catch. Minor point, though since it's just package contents and you normally should not need to fiddle around with that font anyway ;-). And it's OpenOffice.org which provides that font anyway. Regards, Rene -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73
Re: Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation
Am Dienstag 08 August 2006 14:47 schrieb Stuart Anderson: > Yes, the packages I have prepared are built as part of the rest of the > ming package. The ming source package Build-depends on the package that > contains the TTF fonts that will be converted into a libming font package. > Upstream ming (and the libming-util package) now includes an updated > version of the tool that is used to convert the fonts. Would it be possible to convert them at installation time? There would be two essential options: 1. creation at installation time: - possibly only one package for all ming fonts (the tool) - less packages on the mirrors 2. building a ming font package for the wanted TTF font packages I'd go for option one with a small util that: 1. installs the ttf font package e.g. via apt 2. converts to ming fonts 3. optionally uninstalls the ttf font package HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation
On Tue, 8 Aug 2006, Hendrik Sattler wrote: Would it be possible to convert them at installation time? Yes, it would be possible. There would be two essential options: 1. creation at installation time: - possibly only one package for all ming fonts (the tool) The tool is currently provided as part of the libming-util package. - less packages on the mirrors 2. building a ming font package for the wanted TTF font packages Subject to the input I receive on this, I estimate that only 3-4 font packages would need to be provided to cover the commonly used fonts. I don't want an explosion of packages in an effort to convert all fonts that are available, but I do think it would be good to provide the common fonts that are used by applications that depend on libming. I'd go for option one with a small util that: 1. installs the ttf font package e.g. via apt 2. converts to ming fonts 3. optionally uninstalls the ttf font package I have so far choosen the other option because I felt that when installing on a production server, I wanted to _not_ do the extra work of converting the fonts as part of the installation, nor did I want to have to go perform a manual step on multiple servers. This could also lead to other applications (which depend on libming) having to build the fonts in their postinstall script, and there could be multiple applications that need the same font. It is still possible to perform option #1 since the tool is provided, but I would like for the common cases to be effortless for the end user. Stuart Stuart R. Anderson [EMAIL PROTECTED] Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation
On Tue, 8 Aug 2006, Rene Engelhard wrote: No, Replaces:/Povides:/Conflicts: libming-... ^^^ important, because woody's package is named like that. for packages not yet in the archive (your ming-* you can do that but you don't need to; but you *need* the lib there) Doh.. of course. That's what I _meant_, but not what I typed. Thanks for catching that. Stuart Stuart R. Anderson [EMAIL PROTECTED] Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation
Hi Stuart, El mar, 08-08-2006 a las 08:11 -0400, Stuart Anderson escribió: > > I already have package for these fonts prepared as part of the ming > sounrce package, and am awaiting some feedback from some of the > packages > that will use them. Feedback from others would be welcome as well. > > deb http://www4.netsweng.com/~anderson/ming-unstable/ binary/ Those fonts are needed to build the op-panel package [0]. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=323689 I could upload the new ming package when it's ready. Just drop me a note. kind regards, -- Santiago Ruano Rincón signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation
Hello. I've talk to Stuart since a lot time ago about all this, but forgot to look over his late work on the fonts part that was missing. I tough that was a little bit more delyaed than it is. That is my fault for not checking and I'm sorry. Now I will test the fonts against my op-panel package, which is my own responsability now. I also want to apologize for the problems I had with my email account. This was a situation that escaped my control and I hope you all people never get in that situation so people like Rene Engelhard don't treat you like this: "Alejandro (in case you read that in the buglog since your §%&§ mailserver doesn't accept mail)..." Regards, and thanks for your time. -- Alejandro Ríos Peña signature.asc Description: Esta parte del mensaje está firmada digitalmente
Setting up pbuilder or sbuild like experimental buildds
Hi there, I'd like to setup a pbuilder or sbuild (preferably pbuilder, but I'm not sure it's possible) in the way I understand experimental buildds are setup: to only pull experimental software when it's required by the build-deps, but keep only unstable software when possible. I would also like experimental software purged after builds of course. Would someone share an APT + pbuilder / sbuild config to achieve this? Thanks, -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Setting up pbuilder or sbuild like experimental buildds
On Tue, Aug 08, 2006 at 07:30:14PM +0200, Loïc Minier <[EMAIL PROTECTED]> wrote: > Hi there, > > I'd like to setup a pbuilder or sbuild (preferably pbuilder, but I'm > not sure it's possible) in the way I understand experimental buildds > are setup: to only pull experimental software when it's required by the > build-deps, but keep only unstable software when possible. I would > also like experimental software purged after builds of course. > > Would someone share an APT + pbuilder / sbuild config to achieve this? Wouldn't pbuilder with a basic apt pinning setup be enough ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [HELP] FTBFS on alpha for xulrunner
On Tue, Aug 08, 2006 at 10:11:15AM +0200, Bastian Blank <[EMAIL PROTECTED]> wrote: > On Tue, Aug 08, 2006 at 07:57:40AM +0200, Mike Hommey wrote: > > PyGBase.cpp: In member function 'nsresult > > PyG_Base::InvokeNativeGetViaPolicy(const char*, PyObject**)': > > PyGBase.cpp:613: error: no matching function for call to > > 'PyG_Base::InvokeNativeViaPolicyInternal(char [256], PyObject**&, int, int)' > > PyGBase.cpp:563: note: candidates are: nsresult > > PyG_Base::InvokeNativeViaPolicyInternal(const char*, PyObject**, const > > char*, va_list) > > make[5]: *** [PyGBase.o] Error 1 > > > > The code at PyGBase.cpp:613 reads: > > ret = InvokeNativeViaPolicyInternal(buf, ppResult, nsnull, nsnull); > > This is not valid. va_list is no pointer, it is an opaque type > > > Maybe it's the va_args implementation on alpha that somehow differs ? > > Exactly. Alpha implements it as a struct. Thanks, that confirms my doubts and gave me a hint for a fix. Though, after looking at the surrounding code, it seems the function which the error occured in is not used. I asked upstream if it is safe to just remove it. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Setting up pbuilder or sbuild like experimental buildds
also sprach Mike Hommey <[EMAIL PROTECTED]> [2006.08.08.1843 +0100]: > Wouldn't pbuilder with a basic apt pinning setup be enough ? Sure, it should work, but pbuilder-satisfydepends does not support it. Or well, it did not. Looking at it now (0.155), checkbuilddep_versiondeps seems to do some magic. So I guess try it? Pin experimental to between 100 and unstable's priority. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system Most Intelligent Customers Realise Our Software Only Fools Them. signature.asc Description: Digital signature (GPG/PGP)
Re: Pan in Sid
As it was pointed out by Jon Dowland, please read the discussion on this list that was started by the maintainer. Michael Rasmussen wrote: > > 1) It is VERY unstable - constant freezes and crashes Please report such issues using the "reportbug" program or `M-x debian-bug' if you use Emacs and have debian-el installed. One of the reasons that pan was uploaded to unstable is to find and fix any existing bugs in due time. It doesn't crash for me on three architectures. > 2) When installing the old settings from Pan 1.x is not merge with Pan > 2.x in which case your settings are either lost or you have to merge > all settings manually. It is a pain, yes. But for some packages there is no guarantee for an automatic upgrade path, so you'll have to live with it. Note that this is is an upstream issue so all users of all distros suffer from it. > I hope the version of Pan is removed by the end of the day! It won't, I hope. The old pan is not supported by upstream and although more stable than the new one, has plenty of annoying issues and bugs, which Søren Boll Overgaard has been fixing through the years with passion and love. It is inappropriate to insist to continue this nightmare for him throughout Etch's timeframe.
Bug#382091: ITP: libtest-www-mechanize-perl -- Testing-specific WWW::Mechanize subclass
Package: wnpp Severity: wishlist Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]> * Package name: libtest-www-mechanize-perl Version : 1.12 Upstream Author : Andy Lester, * URL : http://mirrors.kernel.org/cpan/modules/by-module/Test/Test-WWW-Mechanize-1.12.tar.gz * License : Perl: GPL/Artistic Programming Lang: Perl Description : Testing-specific WWW::Mechanize subclass Test::WWW::Mechanize is a subclass of WWW::Mechanize that incorporates features for web application testing. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-vserver-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Setting up pbuilder or sbuild like experimental buildds
On Tue, Aug 08, 2006, Mike Hommey wrote: > Wouldn't pbuilder with a basic apt pinning setup be enough ? It didn't work in the first place with pinning (it would either not try installing packages from experimental or install them on upgrades too). Then I thought I might have forgotten APT::Default-Release, and with APT::Default-Release set to "unstable", I could pin experimental higher than 500, 700 for example, and it wouldn't upgrade the packages automatically, however it still doesn't work. These are the scores of the package I'm interested in: bee# apt-cache policy libglib2.0-dev libglib2.0-dev: Installed: 2.10.3-3 Candidate: 2.10.3-3 Version table: 2.12.0-1 0 600 http://ftp.de.debian.org experimental/main Packages *** 2.10.3-3 0 990 http://ftp.de.debian.org sid/main Packages 100 /var/lib/dpkg/status I checked the code of pbuilder-satisfydepends, and I see it tries all versions of "apt-cache show" output to see whether one of them would be enough, but I see no place where it would request a particular version. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Silly Packaging Problem
Hello all, I hope I've got the right list. If not, I appologize; just point the way and I'll take my question to the proper list. I'm attempting to write a debian package for our site that installs configuration files specific to our needs. I'm not a *complete* n00b -- I've written dozens of packages similar to this one and they work without a hitch -- but for some reason this one isn't working. Here's what I've been able to figure out: My package pre-depends on the package that it configures: (In this case, courier-authdaemon.) In my preinst script: 1) I check for the presence of a file: /etc/courier/authdaemonrc -- exit w/ error if it doesn't exist. 2) I then divert this file. 3) Then I check to see that (a) /etc/courier/authdaemonrc does not exist, and (b) that /etc/courier/authdaemonrc.distrib does exist. 4) The script continues by diverting other files that are also to be replaced. After the preinst script exits the files from my package are installed. I presume dpkg handles this magically. Then, in my postinst script: 1) I check for the presence of /etc/courier/authdaemonrc.distrib 2) I check for the presence of /etc/courier/authdaemonrc (from my package) *** This is where the package installation fails -- /etc/courier/authdaemonrc does not exist. Now, before you say, "Hey stupid, make sure your etc/courier/authdaemonrc file is actually *in* the package..." I already have. When I extract the contents of the .deb file to a directory using 'dpkg-deb -x', here is what I have: 39246344 drwxr-xr-x 5 root root 4096 Aug 8 15:52 . 39246414 drwxr-xr-x 3 root root 4096 Aug 8 15:44 ./etc 39246434 drwxr-xr-x 2 root root 4096 Aug 8 15:45 ./etc/courier 39246454 -rw-r--r-- 1 root root 364 Aug 3 14:38 ./etc/courier/imapd.cnf 39246468 -rw-r--r-- 1 root root 6139 Aug 3 14:38 ./etc/courier/imapd-ssl 39246474 -rw-r--r-- 1 root root 2692 Aug 3 14:38 ./etc/courier/authdaemonrc 3924648 16 -rw-r--r-- 1 root root12638 Aug 3 14:38 ./etc/courier/imapd 39246494 drwxr-xr-x 3 root root 4096 Aug 8 15:45 ./usr 39246504 drwxr-xr-x 3 root root 4096 Aug 8 15:45 ./usr/share 39246514 drwxr-xr-x 3 root root 4096 Aug 8 15:45 ./usr/share/doc 39246524 drwxr-xr-x 2 root root 4096 Aug 8 15:45 ./usr/share/doc/tiem-courier-cfg 39246534 -rw-r--r-- 1 root root 1055 Aug 3 14:38 ./usr/share/doc/tiem-courier-cfg/copyright 39246544 -rw-r--r-- 1 root root 366 Aug 8 15:43 ./usr/share/doc/tiem-courier-cfg/changelog.gz 39246554 drwxr-xr-x 2 root root 4096 Aug 8 15:45 ./DEBIAN 39246564 -rwxr-xr-x 1 root root 1160 Aug 8 15:45 ./DEBIAN/postinst 39246574 -rwxr-xr-x 1 root root 1373 Aug 8 15:45 ./DEBIAN/preinst 39246584 -rwxr-xr-x 1 root root 738 Aug 8 15:45 ./DEBIAN/prerm 39246594 -rwxr-xr-x 1 root root 1019 Aug 8 15:45 ./DEBIAN/postrm 39246604 -rw-r--r-- 1 root root 91 Aug 8 15:45 ./DEBIAN/conffiles 39246614 -rw-r--r-- 1 root root 376 Aug 8 15:45 ./DEBIAN/md5sums 39246624 -rw-r--r-- 1 root root 510 Aug 8 15:45 ./DEBIAN/control As you can see, etc/courier/authdaemonrc clearly exists in the package file. The other files in etc/courier/ are installed as expected, but for some reason the authdaemonrc file is not installed. Oh, and it get's better. After installation, when I do 'dpkg -L', etc/courier/authdaemonrc *is* listed as one of the files installed by my package. So... Uh... Can anyone enlighten me as to why this is happening? Anxiously awaiting a clue, Michael Peek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Silly Packaging Problem
also sprach Michael S. Peek <[EMAIL PROTECTED]> [2006.08.08.2124 +0100]: > 2) I then divert this file. Diversions of conffiles are not supported. Check that /etc/courier/authdaemonrc is not a conffile. If it is, you could easily lose data in my experience. > 1) I check for the presence of /etc/courier/authdaemonrc.distrib > 2) I check for the presence of /etc/courier/authdaemonrc (from my package) > *** This is where the package installation fails -- > /etc/courier/authdaemonrc does not exist. Exactly. I suggest installing your files to /usr/local/share/etc/courier and then using ucf or just plain cat to modify the file in /etc/courier. This is how I solved the challenge in a cluster situation. You can force ucf to replace files by setting $UCF_FORCE_CONFFNEW . -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system Most Intelligent Customers Realise Our Software Only Fools Them. signature.asc Description: Digital signature (GPG/PGP)
Re: [Mactel-linux-devel] MacBook iSight works?
Hello, On 23/07/06, Junichi Uekawa <[EMAIL PROTECTED]> wrote: > I've created a Debian package. I'm having trouble in that it doesn't > seem to work at all with any application I tried. Could people try > out and see if it's going to work? Actually, I managed to get it working on MacBook with Ekiga. I'm looking for success/failure reports now. I installed the Debian package linux-uvc-source and recompiled the driver, installed it, installed libpt-plugins-v4l2 for ekiga and gnomemeeting. I report that my iSight is working on my MacBook pro 17". I now have a external USB webcam for sale :-) Thanks, -- Dr. Ludovic Rousseau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Silly Packaging Problem
Thanks for the help, Martin. martin f krafft wrote: also sprach Michael S. Peek <[EMAIL PROTECTED]> [2006.08.08.2124 +0100]: 2) I then divert this file. Diversions of conffiles are not supported. Check that /etc/courier/authdaemonrc is not a conffile. If it is, you could easily lose data in my experience. Got it! I suggest installing your files to /usr/local/share/etc/courier and then using ucf or just plain cat to modify the file in /etc/courier. This is how I solved the challenge in a cluster situation. You can force ucf to replace files by setting $UCF_FORCE_CONFFNEW . Okay, now this raises a question: Let's say I do this. I install courier-authdaemon, which installs /etc/courier/authdaemonrc. Then I install my own package, tiem-courier-cfg, which installs a replacement authdaemonrc in, say, /usr/local/share/etc/courier/, and then uses ucf to copy it to /etc/courier/. The next time there's an upgrade for courier-authdaemon, won't it overwrite my version of /etc/courier/authdaemonrc with it's own? I thought that was the whole reason for diversions in the first place, but if diversions don't work for conffiles, then what is one to do? Or does ucf work some magic to prevent this? Is this kind of thing addressed in the Debian Policy Manual (and I just missed it)? Thanks for your help, Michael Peek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Silly Packaging Problem
also sprach Michael S. Peek <[EMAIL PROTECTED]> [2006.08.08.2239 +0100]: > The next time there's an upgrade for courier-authdaemon, won't it > overwrite my version of /etc/courier/authdaemonrc with it's own? No way. Packages must *never* overwrite your files in /etc. > Is this kind of thing addressed in the Debian Policy Manual (and > I just missed it)? Well, yes. Section 10.7. PS: I suggest you look into cfengine2 or parrot, these are designed to do configuration file changes in an organised fashion. They have steep learning curves but they're powerful. Doing this with packages (c.f. dpsyco) is painful, IME. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system "the perfect gun is an idealist without any ideal." -- mc 900 ft jesus signature.asc Description: Digital signature (GPG/PGP)
Re: Silly Packaging Problem
On Tue, Aug 08, 2006 at 05:39:48PM -0400, Michael S. Peek wrote:
[...]
> The next time there's an upgrade for courier-authdaemon, won't it
> overwrite my version of /etc/courier/authdaemonrc with it's own? I
> thought that was the whole reason for diversions in the first place, but
> if diversions don't work for conffiles, then what is one to do? Or does
> ucf work some magic to prevent this?
>
> Is this kind of thing addressed in the Debian Policy Manual (and I just
> missed it)?
Yes, it is. If this is the courier-authdaemon in Debian, and it
blindly overwrites conffiles on upgrade, expect it to be plastered
with RC bugs faster than you can blink.
http://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation
Hi, Alejandro R?os P. wrote: > "Alejandro (in case you read that in the buglog since your ??%&?? > mailserver doesn't accept mail)..." Well, it's not personal. It just the mailserver not accepting mail and that makes problems for reaching you (as in case for this ITP). As mail is to debian communication channel nr.1 this is not good. It could also have been the fact that you don't have control over it (provider, or whatever) Again: It was not meant in offense to you and if you understood that so I apologoize... Regards, Rene signature.asc Description: Digital signature
Re: dh_python and python policy analysis
Hi, Another day, another draft. Here is the latest update for my take on the new Python policy document. The current version, and future updates, are to be found at http://www.golden-gryphon.com/software/manoj-policy/ I am including a text version below. manoj Packaging with the new Python policy A package developers view Manoj Srivastava Copyright (c) 2006 Manoj Srivastava Revision History Revision 1.0.4 25 Jul 2006 Obstacles to conformance with the new python policy. While the new Python policy, specifically the [1]"Packaged Modules" chapter, contains the elements that must be present in the debian/control filename, it is not very explicit about how the values are to be substituted. The Debian Wiki falls back on calling dh_python, which is not helpful in understanding the actual logic to be followed. This article is an attempt to correct this gap in documentation. -- Table of Contents 1. [2]Introduction 1.1. [3]Categorization of Python software 2. [4]Goals of the new Python policy 3. [5]Recipe for developers 3.1. [6]General Notes 3.1.1. [7]Python versions supported by the source 3.1.2. [8]Depends: 3.1.3. [9]Provides 3.1.4. [10]Build-Depends: 3.2. [11]Deprecating "current" in versions supported 3.3. [12]Script 3.3.1. [13]Supported versions 3.4. [14]Private Pure Python Modules 3.4.1. [15]Byte compilation 3.4.2. [16]Supported versions 3.5. [17]Private Extension 3.5.1. [18]Supported versions 3.6. [19]Public pure Python Module 3.6.1. [20]Byte compiling 3.6.2. [21]Supported versions 3.6.3. [22]Provides: 3.7. [23]Public Extension 3.7.1. [24]Supported versions 3.7.2. [25]Provides 4. [26]Changing the default Python version 4.1. [27]Python rtupdate scripts 4.1.1. [28]rtupdate script invocation 1. Introduction While trying to update SELinux packages, I ran across problems in trying to determine if my packages were complying with the new python policy: any practical tips for packaging generally devolved to the statement "Oh, just run dh_python". This is my attempt to offer more concrete tips for packaging. While this document started by reverse engineering dh_python, it has, thanks to help from various people more knowledgeable about Python than I, moved beyond that, and is closer to being a specification unfettered by the idiosyncrasies of current tools and implementations. -- 1.1. Categorization of Python software Program/script This consists of software directly called by an end user of external program, and is independently interpreted by the Python interpreter. Usually starts with the magic bytes #!, with the interpreter being /usr/bin/python* or /usr/bin/env python*. Modules This is code included in python "programs/scripts", and not invoked directly (serving as library modules in compiled languages). Modules can be categorized under two orthogonal criteria: firstly, based on the whether or not they are implemented purely in python, like so: Pure Python Module These are python source code, to be interpreted by the Python interpreter just like program/script code is, and may work across many versions of Python. Extension Module Extensions are C code compiled and linked against a specific version of the libpython library, and so can only be used by one version of Python. Another way of categorizing modules is based on whether or not they are available for use by third party scripts/modules. Public Public modules are available for use in other Python scripts or modules using the import directive. They are installed in one of the directories: /usr/lib/pythonX.Y This directory is reserved for official python modules. No other package apart from upstream official Python modules should install modules in this directory. /usr/lib/pythonX.Y/site-packages
Re: Buildds still not picking up new architectures, why?
On Mon, Aug 07, 2006 at 12:17:52PM -0400, Kevin Mark wrote: > > Someone else (lamont) did the changes I requested on p-a-s; now the > > only remaining problem is that the buildds are not taking the new > > version of p-a-s into account, because they can't talk to the CVS > > pserver. > it is my understanding that each arch has its own wanna-build that uses > its own copy of a p-a-s file. No. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382117: ITP: videolink -- DVD authoring program using HTML for menus
Package: wnpp Severity: wishlist Owner: Ben Hutchings <[EMAIL PROTECTED]> * Package name: videolink Version : 0.8 Upstream Author : Ben Hutchings <[EMAIL PROTECTED]> * URL : http://womble.decadent.org.uk/software/webdvd/ * License : GPL with additions Description : DVD authoring program based on HTML WebDVD is intended to provide a simple way of producing DVDs with attractive and usable menus. It converts HTML pages into DVD menus by rendering them in Mozilla and reproducing their link structure. This allows you to design DVDs using familiar HTML editing tools or your favourite text editor. (As the upstream author I am about to rename the software because "WebDVD" is also the name of an extended DVD format.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382128: RFH: mailman
Package: wnpp Severity: normal Andreas Barth wrote in <[EMAIL PROTECTED]>, to debian-devel-announce@lists.debian.org: > We have a very tough time ahead of us to actually release in time in > December 2006, and we all have to set the release as priority one in > order to make it happen. In particular, the mailman package needs some serious love, which its current maintainers are not giving it. If nobody steps up, etch will be late or without mailman. (That is not mathematically guaranteed, but I - the only currently active Mailman-in-Debian maintainer - doubt I will make it by the freeze deadline of 18 Oct 2006.) Do not be fooled by the long list at http://alioth.debian.org/project/memberlist.php?group_id=30291: - The lead/main maintainer hasn't done anything in Debian for this package since May 2005, although he is definitely not MIA; maybe he is too busy on the Ubuntu side (where he does make occasional updates), maybe too busy with other things in his life. I dunno. - All sidekicks but one have announced they will not (lack of time, ...) do anything for Mailman-in-Debian at the many-months scale of time and haven't reversed this announcement. - Past facts show that the only remaining active sideckick (that would be me) is patently unable (time-wise and/or motivation-wise) to maintain the package on his own. In particular, he hasn't even read the *title* of every bug report yet. Hasn't touched the thing since April 2006. If on the date of 1st October 2006, nothing has changed, I'm going to ask for removal of mailman from etch. The package is not release quality. If you want mailman to be in etch, step up! (Persons that have sent helpful patches in the past, filed several bugs reports, etc are particularly invited, as they seem to be caring for the package at least somewhat.) Get yourself an account on Alioth, I'll add you to the pkg-mailman project and sponsor your uploads if you are not a DD. Contact me with any question / proposition. Thank you in advance and best regards, -- Lionel Elie Mamane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
