Re: timezone data packaged separately and in volatile?
On Tue, Feb 07, 2006 at 09:57:54AM +0100, Andreas Barth wrote: > * Anand Kumria ([EMAIL PROTECTED]) [060207 09:52]: > > On Tue, Feb 07, 2006 at 09:13:07AM +0100, Andreas Barth wrote: > > > * Anand Kumria ([EMAIL PROTECTED]) [060207 04:34]: > > > > I also think volatile is precisely the wrong place to put this kind of > > > > data -- it isn't part of the default apt.sources for one thing; and it > > > > places an extra burden on the maintainer(s) (who know have to track > > > > three different upgrade paths, etc.). > > > > > > Only because you have a prejudice against volatile doesn't mean its the > > > wrong place. Volatile is rather the exactly right place for this kind of > > > update. > > > > It is precisely the wrong place because volatile isn't in > > apt.sources by default. If it were, it'd be a different story. > > You mean, we better don't do anything than to accept packages into a > repository that is actually in apt.sources on a lot of machines, even on > the debian.org-machines? I don't understand your English, perhaps you could rephrase or clarify? > > As it is, volatile is a great solution in search of a problem. It is > > unfortunate that you, and others, seem to latch onto things like as a > > reason to make volatile useful. > > You mean, like accepting a new locale package into volatile? Ah, that's > you who don't like it. Again, those statements don't make any sense to me. Either by themselves or in the context my what you've quoted. Could you rephrase or clarify. Thanks, Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, "This you may not read, this you must not see, this you are forbidden to know," the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, "If this goes on --" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: katie complains about .changes not signed by PGP/GnuPG
On Tue, Feb 07, 2006 at 04:28:19PM +0100, Davide G. M. Salvetti wrote: > I'm trying to upload auctex 11.82-1 since a few days, but I keep getting > the following answer from katie. > The .changes file look fine to me, it is signed by my GnuPG key, as > usual. > Does anyone know why katie does not find the signature? Am I doing > something stupid? The queued gives that error if you don't have three lines like "-BEGIN PGP" and "-END PGP". > If you are willing to help, you can find all needed files on > people:~salve/pub/apt/. I uploaded those files via ftp, and it worked fine. My only guess is the changes you were uploading is different to the one you thought you were uploading. Cheers, aj signature.asc Description: Digital signature
Bug#351821: RFA: freetype -- FreeType 2 font engine, shared library files
Package: wnpp Severity: normal I request an adopter for the freetype package. Due to a new job I haven't had any time to work on FreeType in the last few months. As such I would like someone to adopt it. A team would probably be best, there's lots of difficult issues with this package and it requires plenty of testing with different fonts and displays. There's a new upstream version likely in the not so distant future. The package description is: The FreeType project is a team of volunteers who develop free, portable and high-quality software solutions for digital typography. They specifically target embedded systems and focus on bringing small, efficient and ubiquitous products. . The FreeType 2 library is their new software font engine. It has been designed to provide the following important features: * A universal and simple API to manage font files * Support for several font formats through loadable modules * High-quality anti-aliasing * High portability & performance . Supported font formats include: * TrueType files (.ttf) and collections (.ttc) * Type 1 font files both in ASCII (.pfa) or binary (.pfb) format * Type 1 Multiple Master fonts. The FreeType 2 API also provides routines to manage design instances easily * Type 1 CID-keyed fonts * OpenType/CFF (.otf) fonts * CFF/Type 2 fonts * Adobe CEF fonts (.cef), used to embed fonts in SVG documents with the Adobe SVG viewer plugin. * Windows FNT/FON bitmap fonts . This package contains the files needed to run programs that use the FreeType 2 library. . Home Page: http://www.freetype.org/ Authors: David Turner <[EMAIL PROTECTED]> Robert Wilhelm <[EMAIL PROTECTED]> Werner Lemberg <[EMAIL PROTECTED]> -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
Hi Daniel, On Monday, 06 Feb 2006, you wrote: > On Tue, Feb 07, 2006 at 02:30:01PM +1100, Anand Kumria wrote: > > But that doesn't mean that we can issue an update to a stable package. > > > > Currently they are mainly done for security purposes -- but stable updates > > should not be confined to only that. They should be done to keep the > > system functional. > > > > I also think volatile is precisely the wrong place to put this kind of > > data -- it isn't part of the default apt.sources for one thing; and it > > places an extra burden on the maintainer(s) (who know have to track > > three different upgrade paths, etc.). > > > > It would be good to hear from the glibc maintainers if there are any > > issues addressing bugs such as: 345479, 351049 with an update for > > stable. > > It's not us, but the stable maintainer, that you'd have to talk to; > he has traditionally not been interested in these sorts of updates to > stable as far as I know. I talked to Joey another day, and he said, we should mail him about, and he will decide if this could go in via a point release. I hearby mail him (CC). Lets see what happens. Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Automatic testing of .deb's
Scripsit Adrian von Bidder <[EMAIL PROTECTED]> > Ian: I add my voice to what you already perceive: these tests would be > welcome, and I'd probably accept them to my few packages. A very short > (one screenfull or so) HOWTO/README about how the whole system works linked > from the bug would be helpful, because I don't have the time to read up on > it now, but will want to when you file the first bug on my pkgs, FWIW, I agree with both of these points. -- Henning Makholm "This imposes the restriction on any procedure statement that the kind and type of each actual parameter be compatible with the kind and type of the corresponding formal parameter." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG4 and combined works [was: Anton's amendment]
Anton Zinoviev <[EMAIL PROTECTED]> wrote: > Obviously any patch that is automatically generated in this way is a > work based on A. The license of A permits to use "patch files" for > the purpose of modifying the sources of A at build time. However the > license of A doesn't explicitly permit us to use "patch files" or any > other work based on A for the purpose of modifying the sources of > another program, in our case B. If the license forbids the use of modified code in other works, then it's plainly not a free license. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: katie complains about .changes not signed by PGP/GnuPG
"Davide G. M. Salvetti" <[EMAIL PROTECTED]> wrote: > If you are willing to help, you can find all needed files on > people:~salve/pub/apt/. s/pub/public_html/ I didn't find the culprit, unfortunately. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
working together - executive career site
Hello there, I noticed that your site points to an executive career site. You can generate an additional stream of income for you just by linking to another executive career site. ExecutiveTrumpet is a resume distribution service exclusively for ($75k+) executives and it provides around $37.60 to you per successful referral. We give you a unique link to place on your site and we do the rest. You receive 40% commission. The average amount per transaction is $37.60. If you refer just ten visitors who purchase every week the amount you will receive per year is $19,552. We convert a lot of executive candidates into buyers of our services as we have a results or refund policy, and this of course increases commission generated for you. For more information on generating a stream of income just by linking, do take a look at http://www.executivetrumpet.com/partner.htm I think that this is a strong opportunity for your company (and ours) to increase profits with little effort on your part. After visiting the site, do email or call me if you have any questions. Thank you and best regards, Robert Odhams Founder & Marketing Director ExecutiveTrumpet.com 115 East 57th Street 11th Floor New York, NY 10022 Phone: 212-531-6230 Fax: 212-531-6130 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
katie complains about .changes not signed by PGP/GnuPG
Hi all, I'm trying to upload auctex 11.82-1 since a few days, but I keep getting the following answer from katie. The .changes file look fine to me, it is signed by my GnuPG key, as usual. Does anyone know why katie does not find the signature? Am I doing something stupid? If you are willing to help, you can find all needed files on people:~salve/pub/apt/. -- Thanks, Davide --- Begin Message --- auctex_11.82-1_i386.changes isn't signed with PGP/GnuPG Removing auctex_11.82-1_i386.changes, but keeping its associated files for now. Greetings, Your Debian queue daemon --- End Message ---
Re: timezone data packaged separately and in volatile?
* Ian Jackson wrote: > Martijn van Oosterhout writes: > > The requirements for getting into a stable release update are not > > black magic, they're quite well known: > > > > http://people.debian.org/~joey/3.1r1/ > > 2. The package fixes a critical bug which can lead into data loss, > data corruption, or an overly broken system, or the package is broken > or not usable (anymore). That's why I'm wondering abount the mutt 1.5.9-2sarge1 reject... it also fixes possible data loss. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
Martijn van Oosterhout writes ("Re: timezone data packaged separately and in
volatile?"):
> The requirements for getting into a stable release update are not
> black magic, they're quite well known:
>
> http://people.debian.org/~joey/3.1r1/
2. The package fixes a critical bug which can lead into data loss,
data corruption, or an overly broken system, or the package is broken
or not usable (anymore).
That seems to be true in this case. I think a system which gets the
clock wrong in this way is `overly broken'.
There doesn't seem to be anything in those rules which allows for an
analysis of the risk, so that it can be compared to the benefit.
(Perhaps that's implicit, although it's not stated.) A timezone
update, carefully built against the right dependencies, could be
diffed (that is, the .deb could be diffed) against the old version and
carefully tested, which would provide us with confidence that the new
package is right to install.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
python-xml up for adoption
Hi, I'm no longer using python-xml[1] for my daily development, and as a consequence, I feel I'm not doing as good a job as I should on the python-xml package. I'm therefore considering passing maintenance to someone else, or co-maintaining the package. The packaging itself is pretty straightforward, but * upstream is not very active * some long lasting bugs[2] are fixed in upstream cvs, but the fix might break other packages depending on the bug, so I'm a bit reluctant to add a patch which could lead to debian shipping a pyxml-0.8.4 package which would behave differently from other distributions * xbel is part of the debian package, but is essentially unmaintained by upstream (not a problem for the DTD, but one for xbel-utils scripts, which I don't use and have been the only one to change in upstream CVS during the past years). Additionnally, xbel has been moved to it's own separate project [3], so maybe it makes sense to move it to its own source package. I'm not sure how this should be done, debian-wise. Is anybody interested in maintaining the package? [1] http://packages.qa.debian.org/p/python-xml.html [2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=python-xml [3] http://xbel.sourceforge.net/ -- Alexandre Fayolle signature.asc Description: Digital signature
Re: timezone data packaged separately and in volatile?
* Martijn van Oosterhout ([EMAIL PROTECTED]) [060207 14:09]: > ISTM the d-volatile is the right place for this. However, in the mean > time I think someone should send a message to debian-announce that > anyone running a debian machine with an Australian (or other affected) > timezone needs to get updated zone files from $location. Well, if we *have* files at $location that can be used for this, and that allow updates to etch, these files can directly be put into volatile. The round-trip time for such an update is less than 24 hours, if all relevant people (in this case: the glibc people) agree on how to do it. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
2006/2/7, Anand Kumria <[EMAIL PROTECTED]>: > > It's not us, but the stable maintainer, that you'd have to talk to; > > he has traditionally not been interested in these sorts of updates to > > stable as far as I know. > > Well, perhaps a first start is creating the package for stable-updates; > would it be easier for you if I created a diff or would you rather do it > yourself? The requirements for getting into a stable release update are not black magic, they're quite well known: http://people.debian.org/~joey/3.1r1/ It's quite clear it's not a security bug. Whether it leads to critical data loss or an overly unusable system is debatable. It's just that the clock will be off by an hour for a few weeks. Hardly the end of the world, people run with the clocks on their machines off by months and it doesn't seem to break anything critical. ISTM the d-volatile is the right place for this. However, in the mean time I think someone should send a message to debian-announce that anyone running a debian machine with an Australian (or other affected) timezone needs to get updated zone files from $location. Past policy has been that stable updates don't cover things that arn't critical, even if it makes us look out of date compared to other distributions. A change to that policy should be carefully considered before doing it... -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/
Re: Automatic testing of .deb's
Adrian von Bidder writes ("Re: Automatic testing of .deb's"):
> On Monday 06 February 2006 19:53, Gustavo Franco wrote:
> > On 2/6/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> [ filing automatic package tests to the Debian bts ]
>
> > The Ubuntu maintainer should always open bugs with the test related stuff
> > and see if the Debian maintainer judge it's valuable or not.
>
> Generally yes. But this specific issue discusses a potential (slow) mass
> bug-filing of many similar (in spirit, not technically) bugs and thus
> warrants a discussion on d-d.
That was my view, indeed.
> Ian: I add my voice to what you already perceive: these tests would be
> welcome, and I'd probably accept them to my few packages. A very short
> (one screenfull or so) HOWTO/README about how the whole system works linked
> >from the bug would be helpful, because I don't have the time to read up on
> it now, but will want to when you file the first bug on my pkgs, without
> having to sort through 100 mailing list hits with 90% content which doesn't
> apply anymore because the technical details were changed...
Quite so.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tcl in Debian - volunteers needed
David N. Welton writes ("Tcl in Debian - volunteers needed"):
> Apparently some of the packages I maintain were removed from Debian's
> testing distribution this evening: rivet, tcldom, tclxml and tclsoap,
> because of open bugs against them that I haven't found the time to
> close. "My bad", as they say.
I would like to volunteer to take:
tclparser, tclvfs, libtk-img
If you can't find anyone else then I could also take:
gdtclft, tclthread
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SVN on alitoth for guest accounts
On Tue, Feb 07, 2006 at 11:51:29AM +0100, Philipp Meier wrote: > Could any of the admins please have a look on this or point my to the > right address? Why do you think alioth admins read this list, or that your question had anything to do with Debian development? The frontpage at http://alioth.debian.org states: Any problems? If you encounter a problem with Alioth, please check out the Site Admin group. You may want to use the support request tracker to report problems. http://alioth.debian.org/projects/siteadmin/ Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
SVN on alitoth for guest accounts
Hi all, the debian java maintainers migrated their CVS repository on alioth to a SVN repository. I used to have access to CVS for my account "llucifer-guest" with ssh and public key auth on alioth. Since the SVN migration I did not manage to get access to the SVN repository. SVN itself works out fine at my host, and I'm able to log into alioth with the web interface. Could any of the admins please have a look on this or point my to the right address? -billy. -- Philipp Meier - [EMAIL PROTECTED] A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#204117: Help with installing sgml/xml catalogue stuff
Hi Neil! On Mon, 06 Feb 2006, Neil Roeth wrote: > This web page: http://debian-xml-sgml.alioth.debian.org/ has a link to the > "Latest XML Policy Draft" which has info on where files should go. Have you > seen that? No, thanks for the link. I have still a question concerning the placement in sgml vs xml: I have a texinfo.dtd, a catalogue entry texinfo.cat: OVERRIDE YES PUBLIC "-//GNU//DTD TexinfoML V4.8//EN" "texinfo.dtd" and a texinfo.xsl: http://www.w3.org/1999/XSL/Transform"; version="1.0"> ... I thought to put the dtd and the catalogue (=texinfo.cat) into /usr/share/sgml/texinfo/texinfo.dtd /usr/share/sgml/texinfo/catalog So now my two questions: - is the above the correct location - what should I do with texinfo.xsl Thanks a lot and all the best Norbert --- Dr. Norbert Preining Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- CHICAGO (n.) The foul-smelling wind which precedes an underground railway train. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
On Tue, Feb 07, 2006 at 07:52:15PM +1100, Anand Kumria wrote: > On Tue, Feb 07, 2006 at 09:13:07AM +0100, Andreas Barth wrote: > > * Anand Kumria ([EMAIL PROTECTED]) [060207 04:34]: > > > I also think volatile is precisely the wrong place to put this kind of > > > data -- it isn't part of the default apt.sources for one thing; and it > > > places an extra burden on the maintainer(s) (who know have to track > > > three different upgrade paths, etc.). > > > > Only because you have a prejudice against volatile doesn't mean its the > > wrong place. Volatile is rather the exactly right place for this kind of > > update. > > It is precisely the wrong place because volatile isn't in > apt.sources by default. If it were, it'd be a different story. > > As it is, volatile is a great solution in search of a problem. It is > unfortunate that you, and others, seem to latch onto things like as a > reason to make volatile useful. You feel yourself at war with volatile because the volatile team didn't accept a fully new upstream version of gtk-gnutella - which was never the idea behind volatile. Volatile is not just one more place for backports. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
* Anand Kumria ([EMAIL PROTECTED]) [060207 09:52]: > On Tue, Feb 07, 2006 at 09:13:07AM +0100, Andreas Barth wrote: > > * Anand Kumria ([EMAIL PROTECTED]) [060207 04:34]: > > > I also think volatile is precisely the wrong place to put this kind of > > > data -- it isn't part of the default apt.sources for one thing; and it > > > places an extra burden on the maintainer(s) (who know have to track > > > three different upgrade paths, etc.). > > > > Only because you have a prejudice against volatile doesn't mean its the > > wrong place. Volatile is rather the exactly right place for this kind of > > update. > > It is precisely the wrong place because volatile isn't in > apt.sources by default. If it were, it'd be a different story. You mean, we better don't do anything than to accept packages into a repository that is actually in apt.sources on a lot of machines, even on the debian.org-machines? > As it is, volatile is a great solution in search of a problem. It is > unfortunate that you, and others, seem to latch onto things like as a > reason to make volatile useful. You mean, like accepting a new locale package into volatile? Ah, that's you who don't like it. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
[ debian-volatile dropped ] Hi Daniel, On Mon, Feb 06, 2006 at 11:41:26PM -0500, Daniel Jacobowitz wrote: > On Tue, Feb 07, 2006 at 02:30:01PM +1100, Anand Kumria wrote: > > But that doesn't mean that we can issue an update to a stable package. > > > > Currently they are mainly done for security purposes -- but stable updates > > should not be confined to only that. They should be done to keep the > > system functional. > > > > I also think volatile is precisely the wrong place to put this kind of > > data -- it isn't part of the default apt.sources for one thing; and it > > places an extra burden on the maintainer(s) (who know have to track > > three different upgrade paths, etc.). > > > > It would be good to hear from the glibc maintainers if there are any > > issues addressing bugs such as: 345479, 351049 with an update for > > stable. > > It's not us, but the stable maintainer, that you'd have to talk to; > he has traditionally not been interested in these sorts of updates to > stable as far as I know. Well, perhaps a first start is creating the package for stable-updates; would it be easier for you if I created a diff or would you rather do it yourself? Once a package is available we can start talking to the stable release manager to see what his position is. Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, "This you may not read, this you must not see, this you are forbidden to know," the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, "If this goes on --" signature.asc Description: Digital signature
Re: timezone data packaged separately and in volatile?
On Tue, Feb 07, 2006 at 09:13:07AM +0100, Andreas Barth wrote: > * Anand Kumria ([EMAIL PROTECTED]) [060207 04:34]: > > I also think volatile is precisely the wrong place to put this kind of > > data -- it isn't part of the default apt.sources for one thing; and it > > places an extra burden on the maintainer(s) (who know have to track > > three different upgrade paths, etc.). > > Only because you have a prejudice against volatile doesn't mean its the > wrong place. Volatile is rather the exactly right place for this kind of > update. It is precisely the wrong place because volatile isn't in apt.sources by default. If it were, it'd be a different story. As it is, volatile is a great solution in search of a problem. It is unfortunate that you, and others, seem to latch onto things like as a reason to make volatile useful. The underlying technical issue that volatile is working around is that the stable release manager isn't interested in ensuring that a stable release is both functional and secure (btw: has anyone asked him to confirm this?; I'm just working on the 'general assumptions' here). These goals are not inherently opposed to each other. I'd rather work through the existing stable release process first, then resort to a work-around. Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, "This you may not read, this you must not see, this you are forbidden to know," the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, "If this goes on --" signature.asc Description: Digital signature
Re: timezone data packaged separately and in volatile?
* Anand Kumria ([EMAIL PROTECTED]) [060207 04:34]: > I also think volatile is precisely the wrong place to put this kind of > data -- it isn't part of the default apt.sources for one thing; and it > places an extra burden on the maintainer(s) (who know have to track > three different upgrade paths, etc.). Only because you have a prejudice against volatile doesn't mean its the wrong place. Volatile is rather the exactly right place for this kind of update. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
