Re: Work-needing packages report for Jul 11, 2003
Graham Wilson wrote: > On Fri, Jul 11, 2003 at 08:49:46AM +0200, Marcelo E. Magallon wrote: > >>On Fri, Jul 11, 2003 at 12:33:22AM -0400, Work Needing Prospective >>Packages wrote: >> >judy (#172772), orphaned 210 days ago >> > Description: C library for creating and accessing dynamic arrays >> > Reverse Depends: libjudy-dev >> >> I thought that bogus bogofilter depended on this for building... > > > bogofilter used to use this, but doesnt any longer. anybody opposed to > removing it? There's someone on d-mentors wanting to adopt this. As in the BTS: Debian Bug report logs - #172772 ITA: judy -- C library for creating and accessing dynamic Cheers T. pgpjsNbEXKAcj.pgp Description: PGP signature
Re: Work-needing packages report for Jul 11, 2003
On Sat, Jul 12, 2003 at 08:25:57AM +0200, Thomas Viehmann wrote: > There's someone on d-mentors wanting to adopt this. As in the BTS: > > Debian Bug report logs - #172772 > ITA: judy -- C library for creating and accessing dynamic Oh dear, Ted T'so just uploaded it and assumed maintainership... -Josh -- "Notice that, written there, rather legibly, in the Baroque style common to New York subway wall writers, was, uhm... was the old familiar suggestion. And rather beautifully illustrated, as well..." -- Art Garfunkel on the inspiration for "A Poem On The Underground Wall" pgpdPoNvor6LC.pgp Description: PGP signature
Re: Kernel question: initrd/cramfs
Nenad Antonic <[EMAIL PROTECTED]> wrote:
>Apparently, there is a bug (at least from my perspective) which
> prevents initrd/cramfs in stock kernels, which has been arround for
> years. On the other hand, this bug gets fixed in every version of debian
Why are you trying to use initrd anyway? It's much easier to build
the drivers into the kernel.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Movie
A message was sent from debian-devel@lists.debian.org to [EMAIL PROTECTED] on 7/12/2003 3:03:38 AM. This message contained an attachment (your_details.zip)which was infected with a virus named: W32/[EMAIL PROTECTED] Violated Policy:TRW Inbound Virus Stripping Virus W32/[EMAIL PROTECTED] found in attachment your_details.zip. Remedial action (clean virus) requested. Message quarantined. This message may contain an attachment which is infected with a virus. Message ID: 730188535-2-2 ** MailWatch has scanned your e-mail message and determined it can not be delivered as originally sent. MailWatch can help you avoid these problems in the future by scanning your e-mail for viruses, Spam and objectionable content. Visit http://www.MailWatch.com to read about the benefits of MailWatch. **
Re: Work-needing packages report for Jul 11, 2003
Arnaud Vandyck wrote: [junit-freenet (#165504), orphaned 264 days ago] When I look at the cvs, two classes have been commited 8 month ago, the other 23 month ago!.. I will adopt this package but I won't upload a new version. I have asked for its removal instead (#200949). Let's see which other useless Java packages we can get rid of this way... ;-) Stefan
Re: Work-needing packages report for Jul 11, 2003
Hi, Jamin W. Collins wrote:
> As of today, I've been awaiting
> DAM approval now for 155 days, with no end to the wait in sight. I've
> already adopted one orphaned package (Jabber) and made significant
> improvements to it. However, the 150+ day wait for DAM approval has
> deterred me from looking at adopting any more packages.
I'm not quite at the 150+ day point, but for what it's worth, this is
exactly the reason I haven't yet adopted more packages either.
> However, the DAM approval process needs serious review. Keeping anyone
> in awaiting DAM approval for more than 60 days without any kind of
> notice or update is quite frankly rude and unneeded.
AOL.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
To succeed planning alone is insufficient. One must improvise as well.
-- Salvor Hardin
FWD: Bug#200905: dh_installdocs: don't install empty doc files
This strikes me as a good idea, unless someone has a legit reason to include an empty documentations file in a package. So speak up if you do. Maybe a zero length TODO could be considered to have some implied meaning, but I've seen zero length everything including AUTHORS and README and NEWS. - Forwarded message from Thomas Viehmann <[EMAIL PROTECTED]> - From: Thomas Viehmann <[EMAIL PROTECTED]> Date: Fri, 11 Jul 2003 22:29:59 +0200 To: Debian Bug Tracking System <[EMAIL PROTECTED]> Subject: Bug#200905: dh_installdocs: don't install empty doc files Reply-To: Thomas Viehmann <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Organization: beamNet X-Spam-Status: No, hits=-17.8 required=5.0 tests=AWL,BAYES_01,DEBIAN_BTS_BUG,PGP_SIGNATURE_2,RCVD_IN_NJABL, USER_AGENT_MOZILLA_UA,X_LOOP autolearn=ham version=2.55 Package: debhelper Version: 4.1.52 Severity: wishlist Hi Joey. Thanks for all the things debhelper does right for me. I get lintian warnings for empty files in /usr/share/doc (e.g. TODO which will sometimes be filled by upstream, sometimes be empty). It would be cool to have debhelper (optionally?) discard those when they lack content. Cheers T. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux hardy 2.4.19-tv #1 Tue Mar 18 10:23:25 CET 2003 i686 Locale: LANG=en_US, LC_CTYPE=en_US Versions of packages debhelper depends on: ii binutils 2.14.90.0.4-0.1 The GNU assembler, linker and bina ii coreutils5.0-4 The GNU core utilities ii coreutils [fileutils]5.0-4 The GNU core utilities ii debconf-utils1.2.42 debconf utilities ii dpkg-dev 1.10.10 Package building tools for Debian ii file 4.02-4 Determines file type using "magic" ii fileutils4.1-10 GNU file management utilities ii html2text1.3.0.1-1 An advanced HTML to text converter ii perl 5.8.0-18Larry Wall's Practical Extraction ii po-debconf 0.6.9 Manage translated Debconf template - End forwarded message - -- see shy jo pgp9YdWjjxkqL.pgp Description: PGP signature
Re: Work-needing packages report for Jul 11, 2003
Joshua Kwan wrote: > > >svgalib (#173471), orphaned 205 days ago > > > Description: Console SVGA display libraries > > Of all those people, someone surely has an interest in this. Or > > perhaps it's time to just drop this crash-inducing security-scary > > package? > > This one kind of shocked me. I sure hope it conflicts with > harden-something. And directfb has mostly superseded it for computers > where you would expect to be able to do things fairly smoothly. There's nothing insecure about it if the program using it is not suid. I would be happy to see it removed, or to see it be made policy that programs that use svgalib not be shipped suid. > > >xtrojka (#156524), orphaned 331 days ago (non-free) > > > Description: Fast paced columns-like game > > > > YATP. And it's non-free! > > It sucks, IMHO. xemeraldia beats the stuffing out of many tetris > packages, and don't forget crack-attack ;D I agree that xtrojka sucks, and I was the original maintainer. -- see shy jo pgphQjmrGRtuj.pgp Description: PGP signature
Won't package [was: Re: ITP: libjdbc-stdext-java -- JDBC 2.0 Optional Package from SUN]
After some more investigations: 1° this library is in classpath package and in the j2(sdk|re)1.4 package; 2° it's non-free (I knew but...); 3° it's needed by tomcat4 (by the way of libcommons-dbcp-java) but t4 will depend on j2(sdk|re)1.4. -- Arnaud Vandyck, STE fi, ULg Formateur Cellule Programmation.
Won't package [was: Re: ITP: libjta-java -- JTA is the JavaTM Transaction API from Sun]
After some more investigations: 1° this library is in classpath package and in the j2(sdk|re)1.4 package; 2° it's non-free (I knew but...); 3° it's needed by tomcat4 (by the way of libcommons-dbcp-java) but t4 will depend on j2(sdk|re)1.4. -- Arnaud Vandyck, STE fi, ULg Formateur Cellule Programmation.
Re: Kernel question: initrd/cramfs
On Sat, Jul 12, 2003 at 06:04:41PM +1000, Herbert Xu wrote: > Nenad Antonic <[EMAIL PROTECTED]> wrote: > > Apparently, there is a bug (at least from my perspective) which > > prevents initrd/cramfs in stock kernels, which has been arround for > > years. On the other hand, this bug gets fixed in every version of > > debian > > Why are you trying to use initrd anyway? It's much easier to build the > drivers into the kernel. Not if you want the kernel to function on a wide variety of hardware. Plus there are some situations that a monolithic kernel just can adapt to, such as system partitions on a firewire device (sbp2 can't be built into the kernel TMK). -- Jamin W. Collins This is the typical unix way of doing things: you string together lots of very specific tools to accomplish larger tasks. -- Vineet Kumar
BSP in Debcamp.
Hello, guys. Here in Debcamp we decided that we're going to kill as many bugs as possible (and even releasing sarge if we work hard ;-) during the entire Debcamp, so we'll apply approx. BSP rules and a DELAYED/4-day policy. If anybody is going to start bitching...well, we decided 4-days instead of 7-days because that way is easier to track down problematic NMUs and fix them during the former DC and later DC. Nothing else. We are waiting for you :-) Regards, Ender. -- Why is a cow? Mu. (Omm)
strange BTS behaviour with bug #200180
Hello, by accident I discovered bug #200180 at the fdutils bug report page http://bugs.debian.org/fdutils I was surprised to see this, because I never got a notification for this bug via email (despite the fact that I'm the package maintainer). The BTS claims to have sent the norification mail to [EMAIL PROTECTED] at "Sat, 05 Jul 2003 18:32:26 -0400". My logfiles show that I never received it here. Is there any way to find out, whether the mail actually reached to [EMAIL PROTECTED] address, and whether it was forwarded from there? Another strange thing about the bug report is, that the above mentioned fdutils BTS page displays no ager for this bug. But maybe it is still to new for this. Jochen -- Omm (0)-(0) http://www.mathematik.uni-kl.de/~wwwstoch/voss/index.html pgpYju5W49URW.pgp Description: PGP signature
Re: FWD: Bug#200905: dh_installdocs: don't install empty doc files
On Fri, Jul 11, 2003 at 08:07:40PM -0400, Joey Hess wrote: > This strikes me as a good idea, unless someone has a legit reason to > include an empty documentations file in a package. So speak up if you > do. Maybe a zero length TODO could be considered to have some implied > meaning, in my mind, it probably has the same meaning as no TODO file at all, so adding this feature would be good. -- gram pgpJ1Pr4TlsvE.pgp Description: PGP signature
Re: strange BTS behaviour with bug #200180
On Sat, Jul 12, 2003 at 03:50:16PM +0200, Jochen Voss wrote: > I was surprised to see this, because I never got a notification for > this bug via email (despite the fact that I'm the package maintainer). I've had this happen to me a few times in the past. I'd always ascribed it to my personal e-mail (which I didn't have logs for all of) when it happened. -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
Re: strange BTS behaviour with bug #200180
On Sat, Jul 12, 2003 at 03:50:16PM +0200, Jochen Voss wrote: > by accident I discovered bug #200180 at the fdutils bug report page > > http://bugs.debian.org/fdutils > > I was surprised to see this, because I never got a notification for > this bug via email (despite the fact that I'm the package maintainer). > > The BTS claims to have sent the norification mail to [EMAIL PROTECTED] > at "Sat, 05 Jul 2003 18:32:26 -0400". My logfiles show that I never > received it here. Is there any way to find out, whether the mail > actually reached to [EMAIL PROTECTED] address, and whether it was > forwarded from there? I can verify that it arrived to debian-bugs-dist on the list server, which is Bcc:ed in the mail sent to the maintainer, IOW you. I can't read the mail logs on the d.o MX, for that you'll have to ask debian-admin. > Another strange thing about the bug report is, that the above > mentioned fdutils BTS page displays no ager for this bug. But maybe > it is still to new for this. Yes. -- 2. That which causes joy or happiness.
Re: strange BTS behaviour with bug #200180
Mark Brown writes: > I've had this happen to me a few times in the past. Same here (though not recently). -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin
Bug#200985: ITP: jed-extra -- Collection of useful JED modes and utilities
Package: wnpp Version: unavailable; reported 2003-07-12 Severity: wishlist * Package name: jed-extra Version : 0.1 Upstream Author : Many * URL : http://jedmodes.sourceforge.net * License : GPL Description : Collection of useful JED modes and utilities This package will contain several add-on packages for the JED editor which are present at jedmodes.sf.net and elsewhere on the net. For now I just included home_lib, sl_utils, and ispell from jedmodes.sf.net. Actually, the origin of this package was a request to improve the ispell jed support provided by the dictionaries-common package (see Bug#199502). The preliminary (highly experimental) packages, including a modified version of dictionaries-common, can be apt-got with the following lines in sources.list: deb http://people.debian.org/~rafael/jed-extra ./ deb-src http://people.debian.org/~rafael/jed-extra ./ WARNING: This apt-get repository is highly experimental (haven't I said that already?) and the final release of jed-extra will have to be coordinated with a changed version of dictionaries-common (jed-extra conflicts with dictionaries-common <= 0.10.3). Put the lines above in your source.list only if you really want to participate in the development of jed-extra until its official release. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux laboiss0 2.4.19-686 #1 Mon Nov 18 23:59:03 EST 2002 i686 Locale: LANG=en_US, LC_CTYPE=en_US
Re: BSP in Debcamp.
On Sat, Jul 12, 2003 at 03:28:18PM +0200, David Martinez Moreno wrote: > Hello, guys. Here in Debcamp we decided that we're going to kill as > many bugs > as possible (and even releasing sarge if we work hard ;-) during the entire > Debcamp, so we'll apply approx. BSP rules and a DELAYED/4-day policy. > If anybody is going to start bitching...well, we decided 4-days instead > of > 7-days because that way is easier to track down problematic NMUs and fix them > during the former DC and later DC. > Nothing else. We are waiting for you :-) Is there a designated IRC channel and website for coordination? -- Steve Langasek postmodern programmer pgpwKjPPs6ZQC.pgp Description: PGP signature
help wanted with 'ntp' packages
I am unable to spend as much time updating the 'ntp' packages as they deserve, and so I would like to find someone suitable to either join me in working on them, or take them over outright. There are a number of open bugs that need to be addressed, and I'm completely unhappy with the current default configuration and debconf utilization. I think the resources are all now in place to have a question-free install of a working default configuration and I'd like to see the packages move in that direction. There's a kernel patchset that can help turn Linux into a high- quality stratum one timeserver that I'm using personally on the system that my radio clock is attached to, but have never packaged, that might deserve more attention. And so on... To successfully maintain these packages, you need to understand the NTP protocol a bit, and it would be helpful to have experience managing a non- trivial NTP environment. You need to be willing to deal with an upstream that doesn't release very often, and doesn't always care if the software is broken on Linux. And upstream has moved to using BK for their source repository, so to be effective in doing more than just keeping up with stable releases (which is what I've fallen back to recently), you need to be willing to use a non-free revision control system. If you aren't scared away yet, then send me some email, and/or find me at Debconf3 and we can talk. Bdale
Re: Work-needing packages report for Jul 11, 2003
On Fri, Jul 11, 2003 at 11:58:55PM -0700, Joshua Kwan wrote: > On Sat, Jul 12, 2003 at 08:25:57AM +0200, Thomas Viehmann wrote: > > There's someone on d-mentors wanting to adopt this. As in the BTS: > > > > Debian Bug report logs - #172772 > > ITA: judy -- C library for creating and accessing dynamic > > Oh dear, Ted T'so just uploaded it and assumed maintainership... I'm not on d-montors, and no one had noted this fact in BTS. Sorry. I assume what was meant was that a prospective DD was interested in adopting the package? Does that person have a sponsor? If so, could the sponsor contact me? We can probably work something out. - Ted
Re: Work-needing packages report for Jul 11, 2003
Matthias Urlichs wrote: Oh guys. I'm waiting some 500 days now. I think that's a record (the current is around 470). And I'm still working and contributing. Some nice other DDs stepped forward and wrote mails to the DAM but that didn't cause anything. Robert. As of today, I've been awaiting DAM approval now for 155 days, with no end to the wait in sight. I've already adopted one orphaned package (Jabber) and made significant improvements to it. However, the 150+ day wait for DAM approval has deterred me from looking at adopting any more packages. I'm not quite at the 150+ day point, but for what it's worth, this is exactly the reason I haven't yet adopted more packages either. However, the DAM approval process needs serious review. Keeping anyone in awaiting DAM approval for more than 60 days without any kind of notice or update is quite frankly rude and unneeded. AOL.
Re: Work-needing packages report for Jul 11, 2003
On Sat, Jul 12, 2003 at 05:06:45PM +0200, Robert J?rdens wrote: > Oh guys. I'm waiting some 500 days now. I think that's a record (the > current is around 470). And I'm still working and contributing. Some > nice other DDs stepped forward and wrote mails to the DAM but that > didn't cause anything. No, you've been waiting 188 days (as of today) for DAM according to: http://nm.debian.org/nmstatus.php?email=rjo%40gmx.de According to the above page you application was approved by your AM on 2002-01-04. I'm only referring to the time since the application was approved by AM and DAM became the holdup. You have still been waiting longer, but could still have another 290 days to go (before a new record). So, who does DAM report to? Who can do something about this extremely long wait? -- Jamin W. Collins Remember, root always has a loaded gun. Don't run around with it unless you absolutely need it. -- Vineet Kumar
Re: Work-needing packages report for Jul 11, 2003
> No, you've been waiting 188 days (as of today) for DAM according to: Hm, there are two possibilities: a) I'm blind b) You're wrong because... > 2002-01-04. I'm only referring to the time since the application was its... *January*2002* and today is *July*2003* - its about year and half. Regards! Mati
Re: Work-needing packages report for Jul 11, 2003
On Sat, Jul 12, 2003 at 07:23:55PM +0200, Mateusz Papiernik wrote: > > No, you've been waiting 188 days (as of today) for DAM according to: > > Hm, there are two possibilities: > > a) I'm blind > b) You're wrong Ahh I'm indeed wrong, misread the year both times. You have amazing patience if you haven't bitched about this before. Your situation makes this even more depressing. Here I thought 470 was the current top end, now I find that I may as well not get worked up about it until I've been waiting for nearly 2 years. Something has to change. -- Jamin W. Collins Remember, root always has a loaded gun. Don't run around with it unless you absolutely need it. -- Vineet Kumar
Re: Deconf and shared questions
On Fri, Jul 11, 2003 at 01:20:12AM -0500, Manoj Srivastava wrote: > Given that the check is done before asking any question in the > postinst, if you do install all three of the packages, the first one > whose postinst runs shall ask the question, and create the file; > subsequently, the other packages won't ask the question, since the > file /etc/news/organization shall exist. So the user is only asked > once. > Now, if all these packages use debconf, and they all > preconfigure, then when the preconfiguration is run, the file does > not exist -- and thus all the packages in question shall query the > user -- bombarding the installer with multiple versions of the same > question, over and over again -- unless all the packages use the > same, shared, variable. > If there is to be a shared variable, what should the common > shared toplevel hierarchy be? I don't see all these packages (dist, > mailagent, Gnus, VM, and other packages) using a common (virtual) > package name; they are not even close to being similar types of > packages, and thus do not share a common purpose in general, only for > this variable. > The question then becomes: what is this shared variable > called? How does a package maintainer discover this variable? How are > updates to common templates made? Does some package "own" this shared > variable template? Which one? > Where is this central registry of shared variablenames, so > that the next package wanting to create /etc/news/organization can > use the same variable, and not ask the user yet another duplicate > question. I don't think there is a central registry. I do see a debconf value on my system named shared/organization; this seems to be a general-purpose "organization" value, but perhaps it could be used for the contents of /etc/news/organization as well? The "shared/" toplevel heirarchy seems to be popular for this sort of thing, at any rate; even related packages seem likely to use this when the question doesn't clearly belong to just one of them. As for owning the template: /all/ of the packages own the template (as shown by the Owners: field in /var/cache/debconf/config.dat), and must ship it; or there must be a common package that all others depend on which owns the question, if including it in multiple packages is seen as a duplication of effort. In the absence of strict package dependencies, though, each package that needs the answer must be prepared to ask for it separately. -- Steve Langasek postmodern programmer pgpB3mfIZg5Mf.pgp Description: PGP signature
ITP: knutclient -- A KDE client for monitoring UPSs using NUT - the Network UPS Tools
Package: wnpp Version: unavailable; reported 2003-07-12 Severity: wishlist * Package name : knutclient Version: 0.6.1 Upstream Author : Daniel Prynych <[EMAIL PROTECTED]> * URL : http://www.alo.cz/knutclient-pop-en.html * License : GPL Description : A KDE client for monitoring UPSs using NUT - the Network UPS Tools KNutClient is a KDE client for monitoring UPSs using NUT - the Network UPS Tools. It features support for multiple UPS devices, per-device choice (for warning indicators and stats to monitor), and support for auto switching to the good ranges for voltage and frequency. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux daneel.dune.org 2.4.18-k6 #1 Sun Apr 14 12:43:22 EST 2002 i586 Locale: LANG=fr_FR.ISO-8859-1, LC_CTYPE=fr_FR.ISO-8859-1
Re: Bug#200332: O: netpbm -- Graphics conversion tools
On Mon, Jul 07, 2003 at 06:40:04PM +0200, Andreas Barth wrote: > As you said, we should make at least a silent transition. IMHO we > should split netpbm to a netpbm-legacy (to where all the programms are > transfered) and then substitut the programms on a step-by-step basis > with wrappers to usable[1] programms in netpbm-* (or already existing) > packages). [1] "usable" means: have usable licences and a manpage. Also usable means that the program is not imagemagick. I am really sick of tools that read any image they should process (even for something simple like shrinking) in 48 bit true color into memory. The netpbm tools are far more efficient in this respect. Michael Karcher -- > [Microsoft wirbt:] "Ein offenes Betriebssystem kann schon mal mutieren." Mutieren tun vor allem MS-proprietäre Dateiformate. -- Frank Fürst in <[EMAIL PROTECTED]>
Re: Work-needing packages report for Jul 11, 2003
Theodore Ts'o <[EMAIL PROTECTED]> wrote: > On Fri, Jul 11, 2003 at 11:58:55PM -0700, Joshua Kwan wrote: >> On Sat, Jul 12, 2003 at 08:25:57AM +0200, Thomas Viehmann wrote: >> > There's someone on d-mentors wanting to adopt this. As in the BTS: >> > Debian Bug report logs - #172772 >> > ITA: judy -- C library for creating and accessing dynamic >> Oh dear, Ted T'so just uploaded it and assumed maintainership... > I'm not on d-montors, and no one had noted this fact in BTS. Sorry. Afaict [EMAIL PROTECTED] was almost a whole day faster than you retitling the bug. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=172772&msg=6 > I assume what was meant was that a prospective DD was interested in > adopting the package? Yes, look for threads started by [EMAIL PROTECTED] in debian-mentors archive. > Does that person have a sponsor? If so, could > the sponsor contact me? We can probably work something out. Afaict he was not yet ready to upload. cu andreas
Re: BSP in Debcamp.
Hi, Steve Langasek wrote: > On Sat, Jul 12, 2003 at 03:28:18PM +0200, David Martinez Moreno wrote: > > Hello, guys. Here in Debcamp we decided that we're going to kill as > > many bugs > > as possible (and even releasing sarge if we work hard ;-) during the entire > > Debcamp, so we'll apply approx. BSP rules and a DELAYED/4-day policy. [snip] > Is there a designated IRC channel and website for coordination? And shouldn't such messages be posted to d-d-a? Grüße/Regards, René -- .''`. 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 pgpHJnLplGgDb.pgp Description: PGP signature
Re: Bug#200332: O: netpbm -- Graphics conversion tools
On Fri, Jul 11, 2003 at 11:56:55PM +0200, Michael Karcher wrote: > Also usable means that the program is not imagemagick. I am really sick > of tools that read any image they should process (even for something > simple like shrinking) in 48 bit true color into memory. The netpbm tools > are far more efficient in this respect. Is that why imagemagick is so obscenely slow for simple things like viewing an image? -- - mdz
Re: Work-needing packages report for Jul 11, 2003
On Sat, Jul 12, 2003 at 23:25 +0200, Andreas Metzler wrote: > Theodore Ts'o <[EMAIL PROTECTED]> wrote: > > On Fri, Jul 11, 2003 at 11:58:55PM -0700, Joshua Kwan wrote: > >> On Sat, Jul 12, 2003 at 08:25:57AM +0200, Thomas Viehmann wrote: > >> > There's someone on d-mentors wanting to adopt this. As in the BTS: > > >> > Debian Bug report logs - #172772 > >> > ITA: judy -- C library for creating and accessing dynamic > > >> Oh dear, Ted T'so just uploaded it and assumed maintainership... > > > I'm not on d-montors, and no one had noted this fact in BTS. Sorry. > > Afaict [EMAIL PROTECTED] was almost a whole day faster than you > retitling the bug. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=172772&msg=6 > > > I assume what was meant was that a prospective DD was interested in > > adopting the package? > > Yes, look for threads started by [EMAIL PROTECTED] in debian-mentors > archive. > > > Does that person have a sponsor? If so, could > > the sponsor contact me? We can probably work something out. > > Afaict he was not yet ready to upload. But Ted T'so could be his sponsor now that he has hijacked judy. > cu andreas I've cc-ed Eduardo Cermeño as I think he's not on this list yet. Aníbal pgptkCsif3HQp.pgp Description: PGP signature
Re: [Debian-au] Debian 10th birthday gear
Anand, I know I'd be keen to see a Debian version of this: http://www.everythinglinux.com.au/item/satchel01 as well as some decent t-shirts. Perhaps others'd be interested too? On Tue, 2003-07-08 at 17:36, Anand Kumria wrote: > Hi all, > > [ forward as required ] > > I'm planning on doing some 10th birthday gear. I'm intending to get some > t-shirts made up but if people would like something else instead/as well > then let me know. Naturally you'll probably find it simpler to get your > own made up if you don't live in Sydney, Australia. > > I'm only planning on doing a limited run, so perhaps people who are > doing something similiar locally can email [EMAIL PROTECTED] and let > others know. Naturally if I don't hear from you, nothing will be made. > > I've also been toying around with a slogan (or two) with the help of > Anthony. The general one can always be done later (or used on posters). > I've, obviously, taken some artistic liberties with the numbers but the > intent is the alliteration. > > Birthday > > Debian > 10 years >100 countries > 1000 maintainers > 1 packages > > General > Debian > 1 project >10 architectures > 100 countries > 1000 maintainers > 1 packages >10 bug fixed > 100 million users > 1000 installations > 1 lines of code > > I'd welcome any feedback / improvements. > > Regards, > Anand -- Cheers, Craige. GPG Key fingerprint = C206 904F 5231 2F2E 8DAA F094 5879 71B5 0960 CF37 http://arseclown.tv/ signature.asc Description: This is a digitally signed message part
problem setting up interlibrary dependencies
I'm running into difficulties getting vibrant6 [1] to comply with the new policy requiring full inter-library dependencies. The source of the complication is that two of the libraries come in OpenGL and non-OpenGL variants, but certain intervening libraries are OpenGL-agnostic and therefore come in only one variant. Since OpenGL is a pretty hefty dependency, I'd like to avoid it if possible, and not have the intermediate libraries indirectly require it; on the other hand, the GL-enabled variant of the higher-level library (ncbicn3d) specifically needs the GL-enabled variant of the lower-level library (vibrant) in order to work properly. I would also like for packages that request linkage against plain vibrant not to end up depending on the GL variant, even if built on systems with the GL variant installed. (On the other hand, packages that specifically try to link against the GL variant should get it) I haven't quite been able to come up with a reasonable arrangement that satisfies all of these constraints. The closest I've come up with so far falls apart the moment ldconfig runs: BASELINE: libvibrant-nogl.so.6.1.: real file, soname libvibrant.so.6 libvibrant-nogl.so.6 -> libvibrant-nogl.so.6.1. [libvibrant-nogl.so -> libvibrant-nogl.so.6.1.] [libvibrant.so -> libvibrant-nogl.so] WITHOUT libvibrant6-gl: libvibrant.so.6 -> libvibrant-nogl.so.6 WITH libvibrant6-gl: libvibrantOGL.so.6.1.: real file, soname libvibrantOGL.so.6 libvibrantOGL.so.6 -> libvibrantOGL.so.6.1. [libvibrantOGL.so -> libvibrantOGL.so.6.1.] libvibrant.so.6 -> libvibrantOGL.so.6 (clobbered by ldconfig :-/) I could perhaps kludge around this by having libvibrant6-gl also contain a dummy library with a soname of libvibrant.so.6 that pulls in libvibrantOGL.so.6 and sorts after libvibrant-nogl.so.6.1., but that would be gross, and lead to odd-looking ldd output. Any suggestions? Should I just punt and force everyone to use the OpenGL version? (That would certainly be simplest, but I'd really prefer to avoid the dependency bloat if I can.) [1] I am simultaneously renaming the package to libvibrant6, so please refrain from commenting on its archaic name. ;-) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Qt3 still broken (compat-headers), what to do?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi ho, it's time for another rant from me regarding the libqt3-compat-headers split. This time my ex-housemate has been hit by the problem: she's just started working with Qt, and lo and behold she received a missing header compile error. She didn't look through README.Debian for the fix since it didn't occur to her that debian would deliberately break the Qt development environment like this. The motivation for this post is that I *really* want this issue fixed for sarge, lest we go through the whole debacle once more for users upgrading between stable releases. The contents of this email are as follows: 1. Problem description 2. Timeline 3. What can be done If you don't want to read this entire email, feel free to skip directly to section 3 where I discuss a possible Qt NMU amongst other things and ask for opinions. Otherwise, off we go. 1. Problem description Qt3 as produced by upstream includes a number of headers, including both modern headers and legacy headers to ease the Qt2 -> Qt3 transition. In debian these headers are split into libqt3-headers and libqt3-compat-headers. There is *nothing* in the package management system to suggest to users that they might want libqt3-compat-headers. In particular, the main development packages (libqt3-mt-dev and libqt3-dev) depend on libqt3-headers but don't even mention libqt3-compat-headers (no depends, recommends or suggests). Several 3rd-party Qt apps still use these legacy headers. If a user tries to build one of these apps they get a compile error (missing header) and are given no further information. To find out how to fix this problem they have to (i) post to a mailing list or read an online FAQ, or (ii) think that perhaps this is a debian problem, not a Qt problem, and then think to read the README.Debian to see how and why debian introduced this breakage. The original motivation for this split was to encourage upstream developers to transition their apps from Qt2 to Qt3 headers, and to encourage users to hassle upstream developers because their debian build no longer works. The consequences of this split are that: (i) some upstream apps have migrated from Qt2 to Qt3 headers; (ii) many users have been confused by compile errors, as evidenced by posts to debian-kde over the past months; (iii) many people have simply installed libqt3-compat-headers to fix the problem, rendering the package split meaningless (since legacy headers in other Qt apps are no longer identified). There is a much less painful way to encourage upstream developers to migrate their headers; this is to run fixkdeincludes over the sources and email upstream the results. Of course this doesn't put the upstream developers under pressure from their users to fix what are debian-specific compile errors, which is presumably why the package split was used instead. The less harmful solution of putting #warnings in the legacy headers was proposed; this was rejected by the Qt maintainers because it differs from upstream's Qt release. Why silently moving all of the legacy headers into a separate not-installed-by-default package is more faithful to upstream's Qt release I do not understand. Most of the noise regarding this problem has died down, almost certainly because people who have already transitioned from woody to sid have experienced the problem, posted to mailing lists or read list archives and installed libqt3-compat-headers to get rid of the errors. Presumably the noise will start up again when we release sarge and get another round of errors and confusion from people upgrading from woody. I would like this issue resolved before this happens. 2. Timeline 3 Feb 2003: Headers are split; libqt3-compat-headers is born. 27 Feb 2003: The header split is discussed on -devel and -kde: http://lists.debian.org/debian-devel/2003/debian-devel-200302/msg01724.html With the exception of a couple of vocal people (such as the Qt maintainers), IIRC most developers disagreed with the split. 17 Mar 2003: Ralf indicates in #184084 that the problem will be fixed, i.e., that libqt3-compat-headers will be introduced as a dependency for libqt3-dev and libqt3-mt-dev. This fix can be observed in KDE CVS (where the Qt packaging files are kept). 10 May 2003: A new Qt3 is uploaded to debian without the promised dependencies. 16 May 2003: These dependencies are removed from KDE CVS by the Qt maintainer: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/qt-copy/debian/control.diff?r1=1.56&r2=1.57&f=h The changes were never uploaded to debian. 3. What can be done I have been prodding on this issue for several months now with repeated posts to mailing lists and the Qt maintainers. A bug has been open (#184084) for this issue since 9 March. Despite what seems to be an strong majority of opinion against the split, nothing has been done, even though the fix is so utterly trivial (add libqt3-compat-h
Re: problem setting up interlibrary dependencies
On Sat, Jul 12, 2003 at 11:05:54PM -0400, Aaron M. Ucko wrote: > I'm running into difficulties getting vibrant6 [1] to comply with the > new policy requiring full inter-library dependencies. The source of > the complication is that two of the libraries come in OpenGL and > non-OpenGL variants, but certain intervening libraries are > OpenGL-agnostic and therefore come in only one variant. > Since OpenGL is a pretty hefty dependency, I'd like to avoid it if > possible, and not have the intermediate libraries indirectly require > it; on the other hand, the GL-enabled variant of the higher-level > library (ncbicn3d) specifically needs the GL-enabled variant of the > lower-level library (vibrant) in order to work properly. I would also > like for packages that request linkage against plain vibrant not to > end up depending on the GL variant, even if built on systems with the > GL variant installed. (On the other hand, packages that specifically > try to link against the GL variant should get it) > I haven't quite been able to come up with a reasonable arrangement > that satisfies all of these constraints. The closest I've come up > with so far falls apart the moment ldconfig runs: > BASELINE: > libvibrant-nogl.so.6.1.: real file, soname libvibrant.so.6 > libvibrant-nogl.so.6 -> libvibrant-nogl.so.6.1. > [libvibrant-nogl.so -> libvibrant-nogl.so.6.1.] > [libvibrant.so -> libvibrant-nogl.so] > WITHOUT libvibrant6-gl: > libvibrant.so.6 -> libvibrant-nogl.so.6 > WITH libvibrant6-gl: > libvibrantOGL.so.6.1.: real file, soname libvibrantOGL.so.6 > libvibrantOGL.so.6 -> libvibrantOGL.so.6.1. > [libvibrantOGL.so -> libvibrantOGL.so.6.1.] > libvibrant.so.6 -> libvibrantOGL.so.6 (clobbered by ldconfig :-/) > I could perhaps kludge around this by having libvibrant6-gl also > contain a dummy library with a soname of libvibrant.so.6 that pulls in > libvibrantOGL.so.6 and sorts after libvibrant-nogl.so.6.1., but > that would be gross, and lead to odd-looking ldd output. > Any suggestions? Should I just punt and force everyone to use the > OpenGL version? (That would certainly be simplest, but I'd really > prefer to avoid the dependency bloat if I can.) So to restate, you have two libraries which export similar ABIs, but not identical; the GL-enabled version of the library exports additional entry points which are only of use to a subset of callers. You want to supply distinct .so links for each library, so that at build-time a program can clearly specify which variant it wishes to link against; and you don't want to drop the non-GL variant, because OpenGL is a hefty dependency for those who don't need it. I see two possible strategies here. 1) Divide the library into two parts: one which provides the non-GL functions, and one which provides *only* the GL functions. This provides a clear delineation of the functionality of each package; the downside is that you (or upstream) would have to do a fair amount of work to implement such a split, and you may have private functions that have to be shared (rather, duplicated) between the two libs. 2) Continue to ship complete versions of each library, tagging each with a unique soname and keeping their associated filenames entirely separate. If someone wants the non-GL version, they link with -lvibrant; if they want the OpenGL-enabled version, they link with -lvibrant-gl. Disadvantage: if you have a higher-level library that would use the non-GL version of the library, and an application that would use both this higher-level library and libvibrant-gl, you would have both libvibrant and libvibrant-gl loaded into memory, which probably won't work too well unless you implement symbol versioning as well. -- Steve Langasek postmodern programmer pgpYfLM3roLOs.pgp Description: PGP signature
Re: Qt3 still broken (compat-headers), what to do?
On Sun, Jul 13, 2003 at 01:51:07PM +1000, Ben Burton wrote: > It seems then that our options are as follows. > (i) Wait for the Qt maintainers to upload a fix. > (ii) Do an NMU for Qt, despite the fact that this bug is not release-critical. > (iii) Resort to the technical committee. > (iv) Keep the package split and release sarge with a broken Qt development > environment. > Several months of experience suggest that (i) does not promise success. > Option (iii) seems rather heavy-handed to me. And I am loathe to see us > reach (iv), cementing debian as the only distribution with a deliberately > broken Qt. > I'd thus like to propose (ii) as the best solution. I realise this is not an > RC bug; technically it's not debian's problem but the upstream Qt app's > problem. Nevertheless, as it stands users are expected to divine the fact > that debian has deliberately broken Qt, that they should look in > README.Debian for a fix and that they are morally expected to tell upstream > that their code is wrong (after all, that's why they were forced through this > hassle in the first place). Though I certainly agree that the current packages are gratuitously broken, an NMU without the consent of the maintainer seems almost certain to turn into a pissing contest. Since (i) hasn't gotten anywhere in four months, I would suggest that (iii) is the way to go here: this is precisely the sort of case I think the technical ctte. is for. > I therefore see this is as a "release-critical usability problem", which the > BTS and policy have no formal concept of. I think that would be counted as 'grave'. -- Steve Langasek postmodern programmer pgpAKaCWgS8O5.pgp Description: PGP signature
