Re: Security updates for sarge?
> And without starting a flamewar, ... Yep, I thought it looked too good to be true. b.
Re: Bug#277582: ITP: kwin-baghira -- A MacOSX-like theme for Apple junkies ;)
Hi ho, > yes, please consider kde-baghira-style, since it's not only kwin > decorations that you'll be providing in the package, right? see > rationale in my other message. I'd suggest kde-style-baghira, since with such a scheme all styles will show up together in the package listing. Just my 2c, b.
Re: RFS: kmenc15 - An advanced Qt/KDE MEncoder frontend.
> Yup, thats exactly what I thought. In which case, my program does have a > chance to be in contrib. which brings me to my original question, what should > I do to find a sponsor?... I believe I've maxed out my available resources... It might be that you need to wait until you've gone through NM and can upload on your own. Speaking only for myself, my time is limited and sponsorship chews up a fair bit of time (checking over the packaging, talking with the maintainer about what needs fixing, etc), and I'd rather spend that time on packages that can go into main. I don't know how many others feel the same, but if you're looking to go through NM you may find more offers of help if you choose something in main to train yourself on. Of course I may be wrong, just my thoughts on the matter. b.
Re: RFS: kmenc15 - An advanced Qt/KDE MEncoder frontend.
> However, if you > upload a package to contrib that build-depends on a package not in > contrib or non-free, you'll get a FTBFS RC bug filed against you > before you blink. Hmm, I didn't, back in the days when regina-normal built against java2 (which wasn't in the archive at the time). Though thankfully those days are gone. b.
Re: Bug#280435: ITP: libkexif -- KDE library to read/edit EXIF informations
> > Libkexif is a KDE library for manipulating EXIF information embedded in > > images. It currently supports viewing of all EXIF information via > > libexif. It also supports the modification of a few attributes in a save > > way that preserves all other EXIF information in the file. It can > > currently modify the following tags: > > Given that it sounds like it's non-graphical, what does it do that > libexif doesn't, and why does KDE need its own EXIF library? Because it is graphical (says me after taking a lightning look in the upstream CVS). And moreover it makes use of the regular libexif, as Achim's description points out. Ben.
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
> Choosing to be offended by what other people do is a choice. Oh, come on. That's a cop-out if I ever heard one. (Discussing the generalities here, not the particular hot-babe example in question.) b.
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
> > > >>>As already written in -women, this is the point which saddens me the > > > >>>most in this thread. I'm really disappointed by seeing most > > > >>>contributors just not realize why this package, as proposed, is > > > >>>likely to hurt the feelings of several women (probably not all, I > > > >>>don't know) as well as, indirectly or not, some men. > > (And quite stunningly failing to realise that objecting to this > package in this manner is equally offensive in the other direction, > and probably more so. Please humour me and spell it out for me in small words. I am presumably missing something stunningly obvious. b.
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
> I find the notion of introducing censorship in order to not 'hurt > their feelings' to be morally repugnant. Yes yes, I understand why you don't like it. What I wanted was an explanation of why objecting to this package was probably _more_ offensive than proposing it. (Bearing in mind that in this context, "censorship" simply means not shipping with debian, as opposed to attempting to deny access altogether.) > It has been proven endless times that once you start doing this, you > can't stop. For any package, there is going to be some minority group > that is offended by it. Sounds to me like your problem is not so much with the objection, but with its expected implementation. b.
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
> "Oh no, there's the possibility that somebody else might look at some > low quality porn" versus "Other people are actively forcing their > beliefs onto us". Isn't it obvious? > > ... > > That's what "censorship" means in every context, under any practical > definition. It's impossible to deny access altogether to anything. Hmm? I didn't think people were trying to restrict access -- at least I presume nobody is under the delusion that keeping hot-babe out of debian would make it any more difficult to access such material. There are other reasons for choosing not to ship a package with a distribution. > > > It has been proven endless times that once you start doing this, you > > > can't stop. For any package, there is going to be some minority group > > > that is offended by it. > > > > Sounds to me like your problem is not so much with the objection, but with > > its expected implementation. > > There's only one way this ever goes. Any student of history should be > familiar with how this plays out. shrug. At least in .au we have some legislation to protect minority groups but we're not living in a totalitarian PC clampdown. b.
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
> > shrug. At least in .au we have some legislation to protect minority > > groups but we're not living in a totalitarian PC clampdown. > > Sounds irrelevant. There's a big difference between 'protect minority > groups' (from what?) and 'compel everybody to behave in a manner > approved of by minority groups'. The latter is often designed to achieve the former. So let me say then that we have some legislation in .au that in certain contexts compels people to behave in a manner approved of by minority groups, and yet we're not living in a totalitarian PC clampdown. Sure, it's a far cry from restricting what you can say in a classroom or workplace to controlling your every action. But then again, it's a far cry from keeping a package out of debian to controlling your every action. b.
Re: historic mails from me - please ignore
Heh. I read that as "histrionic". Twice. b.
Re: Bug#299379: ITP: moodle-book -- moodle module for multi-page resources
Hi, > This Moodle module makes it easy to create multi-page > resources with a book-like format. When you create the actual packages it might be nice to explain what moodle is, for those of us who have no idea. e.g.: This Moodle module makes it easy to create multi-page resources with a book-like format. . Moodle (Modular Object-Oriented Dynamic Learning Environment) is a course management system Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: yet another mass bug filing on GFDL issues ?
> Do a
>
> find /usr/share/doc -name copyright -exec grep -l "YOUR NAME" {} \;
>
> to find those packages on your system. (This might cause a few false
> positives, figlet for example is not affected :)
Hmm, I suspect this will find a very large number of false positives
since "YOUR NAME" shows up in the addendum ("how to use this license for
your documents").
I looked up a couple of KDE packages (kdeedu, kdebase), which both match
your grep (due to the addendum) but which both have the full "no invariant
sections, no front-cover texts, no back-cover texts" blurb appearing before
the license itself.
Ben.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ubuntu and its "appropriation" of Debian maintainers
On the one hand, I think it's polite and the "socially responsible" thing to give credit where credit is due, i.e., to acknowledge the debian maintainers whose work is used. On the other hand, I've had packages for which ubuntu has moved to a newer upstream version without properly updating the debian/ files, resulting in packages that are severely broken (some to the point of unusability), with my name listed as maintainer. So I guess all I'm saying is that, if you're choosing whether or not to attribute packages to the respective debian maintainers, there's no obvious default that won't upset somebody (either through lack of recognition, or through being blamed for problems that aren't their fault). Anyway, just thoughts. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Orphaning packages
Hi, > libarchive-zip-perl (bug #314850) I can look after this one if you like, since I use it. Though it seems Matthias Klose has been doing uploads for the last year, so if he'd rather look after it then this is fine by me. (Please CC me on replies related to libarchive-zip-perl adoption.) b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
KDE apps up for adoption
Hi all, Since my spare time is not what it used to be, I have put a few KDE apps up for adoption this morning: kdbg (#315336) -- graphical debugger interface kprof (#315337) -- visual tool to help analyse profiling results kbear (#315340) -- graphical ftp client for KDE If anyone is willing to take these up it would be appreciated. More detailed notes on each package are included below. Ben. kdbg: This KDE package is relatively straightforward to maintain, and upstream is active. kprof: This KDE package is small and relatively straightforward to maintain. Although upstream is not nearly as active as it used to be, the package itself remains useful. An ability to dive into Qt/KDE code and fix it is preferable, since (due to upstream's inactivity) you will need to do bugfixing yourself. kbear: This KDE package is not easy to maintain, mainly because upstream has been silent for some time and there have been some rather nasty and hard-to-find bugs that needed fixing. Nevertheless, people still use this package so it would be nice to have someone look after it. You will need a good understanding of Qt/KDE programming, since you'll probably end up doing all the bugfixing yourself and the code is somewhat complex. The version currently in debian is 2.1.1. Upstream released 3.0alpha a couple of years ago, but I chose not to upload an alpha release. I'd also recommend against uploading 3.0alpha to the new maintainer without some very thorough testing and inspection, since all signs suggest that a beta/final release is never likely to appear. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: KDE apps up for adoption
> I guess we (qt-kde team) could do it. and anybody interested in doing > it too could join us (only having an alioth account is required) and > maintain those inside our svn. Works for me, ta. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
> > Wow. First off, Kari does not appear to be upstream, so who are > > you addressing? > > Him. I think he's in the better position to talk to upstream about > it. Or in fact not make the package. Oh, come on. It's the author's perogative as to how the work is licensed, and since it adheres to the DFSG I don't see why debian should be rejecting this package on license issues. While you're at it, you might as well request the removal of regina-normal, for which I am both packager and upstream, which also supplies a GPLed library. Oh, and don't forget readline too. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Move to python 2.4 / Changing the packaging style for python packages
Hi, > With the upcoming releases of the last packages which > didn't support 2.4 yet (Plone on the Zope application server) we may > be able to drop support for 2.3 in sid and etch as well. For reference, decompyle still needs python2.3. There are two issues: 1. It won't build under python2.4. I have fixes for this that I haven't uploaded (and that need some more testing and tidying up). 2. It won't decompile python2.4 bytecode. This will be somewhat harder to fix (and I haven't done it yet). Issue #2 is not really relevant to dropping python2.3, since keeping python2.3 around is not going to help the fact that people will be wanting to decompile bytecode for the new default python2.4. Issue #1 is a problem however, so if there are plans to drop 2.3 for etch, I'd be very happy for a rough timeframe so I know when this all needs to be dealt with. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Move to python 2.4 / Changing the packaging style for python packages
Hi, > > 1. It won't build under python2.4. I have fixes for this that I haven't > >uploaded (and that need some more testing and tidying up). > > You may still ask for help. This will be easy enough to have ready by the time 2.3 is removed, which I'm assuming is not happening tomorrow. Where I'd love the help is with the python2.4 decompilation (see below). > > 2. It won't decompile python2.4 bytecode. This will be somewhat harder > >to fix (and I haven't done it yet). > > If it is not able to decompile recent python version, then it is a kind > of useless one. Well, it's certainly useful at the moment since python2.3 is the default, and I claim it's still useful even after python2.3 is dropped -- just because debian changes the default python doesn't mean all your old bytecode disappears. One of the more important uses of this software is for repairing things in an emergency (e.g., rm *.py, oops), which is why I want to keep it around. > Python 2.4 is out since a while, what are upstream plans for their software ? Upstream went commercial back in the 2.2 days. The debian packages forked and essentially became the de-facto upstream source when 2.3 decompilation was introduced, and it's still that way now. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Celebrating Debian's 10th birthday?
> Are there any parties planned already? ;) Well, it coincides with the first day of the international olympiad in informatics, so with all the computer geeks around I'm hoping there will be someone else there to celebrate with. :) Ben.
Re: j2re1.3 plugin for mozilla isn't working.
> Has anyone else noticed this? I know that the unofficial j2se1.4 packages consistently crash under certain conditions when using JNI with C++ code; this is related to the fact that the j2se1.4 packages are still built using g++-2.95 whereas the default C++ compiler for debian is g++-3.x. Don't know if this is related to the mozilla problem or not. You could try downloading your own Java runtime from blackdown.org and using that instead of the unofficial debian packages; this fixed the JNI crashes for me. Ben.
Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster
> How would you react if somebody called work you did and that took a > few hours "silly"? In the sweetest way possible, if all you lost was a few hours then I don't see why you're (apparently) so very upset. Many times I have seen contributions worth days or weeks of work dismissed from software projects. For that matter, in academia you can spend months or years working on a result only to find that someone else has been working on the same result simultaneously and has published it before your work was complete. If it's only a few hours I'd honestly just file it away under experience and get on with my life. Not taking sides, just putting it into perspective. Ben. :)
Re: failing to compile a KDE package
> checking for Qt... configure: error: Qt (>= Qt 3.0.2) (library > qt-mt) not found. Try ./configure --with-qt-dir=/usr/share/qt3 and see if that helps. If it does then upstream is using a very old admin/ directory which should probably be updated. If the compilation then breaks because of missing headers like qptrlist.h and so on, install libqt3-compat-headers and optionally flame the Qt maintainer(s) for not including them in their standard Qt development installation. And tell upstream that they're using legacy headers as the Qt maintainers are expecting you to, which is why they've chosen to break Qt in this way. Ben. :)
Re: failing to compile a KDE package
> problem status: still unsolved. Hmm.. is it possible to post the section of config.log where the error occurs? b.
Re: [solved] failing to compile a KDE package
> >Uh, this is not a problem with autoconf. It is a problem with upstream > > calling AC_CHECK_COMPILERS (which checks for all compilers) and ignoring > > the results thereof. > > ok. i'll have it sent upstream. FYI, all upstream probably needs to do is update their admin/ directory with a fresh copy from a recent KDE release. Ben.
Qt3 still broken (compat-headers), what to do?
though the fix is so utterly trivial (add libqt3-compat-headers to the Depends lines in debian/control). 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). I therefore see this is as a "release-critical usability problem", which the BTS and policy have no formal concept of. I'll be happy to do the NMU myself and wear the consequences if necessary. Though I would first like to elicit opinions from other developers on whether they feel this is the correct action to take at this point. So. Do people support this move or not? Ben. - -- Ben Burton [EMAIL PROTECTED] Public Key: finger [EMAIL PROTECTED] A handful of lovers and loved ones, fighting shoulder to shoulder, could rout a whole army. For a lover to be seen by his beloved forsaking the ranks or throwing away his weapons would be unbearable. He would rather a thousand times die than be so humiliated. - Plato, The Symposium (4th century BC) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/ENcuMQNuxza4YcERAiywAJ9P+92XuWbaDmQEGe49QpcQjZT71QCgjseB nA8kVe2xwTYKKUitekKl0QQ= =EQvF -END PGP SIGNATURE-
Re: Qt3 still broken (compat-headers), what to do?
> I suppose there's always the option of NMUing, and hoping it sticks -- > then taking it up with the tech ctte. if it doesn't... This is more or less what I was thinking of. The impression I get is that the Qt maintainers have shifted their stances on this issue from defense to apathy. Though it's possible that this is just because apathy is an easier way to keep the package split until somebody does an NMU or calls in the technical committee. Ben.
Re: Qt3 still broken (compat-headers), what to do?
> I wouldn't do it. Suppose you were the Qt maintainer, and you made a > technical choice that some people disagree with You mean a technical choice with a significant negative impact on users that breaks compatibility with upstream and every other linux distribution and that most (not some) people disagree with. > and they do an NMU on you after four or five months of constant prodding and visible user confusion. > IMHO, what should happen, is try to convince the Qt maintainer This option appears to lead nowhere, as explained in my earlier post. > or agree with him to let the technical committee decide this one.. Taking it to the technical committee needn't require the Qt maintainers' consent. Furthermore, since the Qt maintainers seem so apathetic about this issue I'm certainly not going to wait for it. I honestly believe that in this case having a sarge Qt that's not broken should take precedence over maintainers' territoriality over their packages. And this is not a snap decision; the problem has been discussed for many months now without resolution, and the user errors continue to roll in. Ben.
Re: Qt3 still broken (compat-headers), what to do?
> > Bah, the Technical Committee takes months, sometimes over a year, to do > > something even as seemingly uncontroversial as voting in opposition to > > whichever solution Branden Robinson proposes. > > So? This is more than enough time. This problem is to be fixed in sarge ... Hmm? Are you saying that sarge is definitively well over a year away? b.
Re: Qt3 still broken (compat-headers), what to do?
> My suggestion: Add a "Recommends: libqt3-compat-headers" to libqt3-dev. This is indeed what I would add were I to do an NMU, and I would include it in the list of solutions that I see as satisfactory were I to put it to the TC. b.
Re: Work-needing packages report for Sep 2, 2005
> Yes, those are the titles of those bugs *now*, after I noticed the > problem in the list. Check the original bug titles as submitted. :) FWIW, this was due to an issue with reportbug which was recently fixed (#323801). b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Problem with libtool relinking
Hi all, I have a problem with libtool; it's an issue that seems to have been affecting people for years but I'm having real trouble hunting down a solution (which I'm sure exists). My problem is that regina-normal currently needs to build-conflict with earlier versions of regina-normal-dev. Otherwise, if an earlier version of the development libraries is installed, libtool will relink some libraries against these old versions at the make install stage. The precise situation is this. The regina-normal source package builds and installs libraries A and B, where B links against A. At the build stage, everything is fine. At the make install stage, library A installs without problems into the DESTDIR, but then libtool tries to relink library B against the older A in /usr/lib (and fails because the older library is missing some new symbols). If I don't have regina-normal-dev installed, then B relinks without problems and also installs correctly into the DESTDIR. This happens with the most recent libtool in sid, and I am configuring with --enable-fast-install (thus the executables don't get relinked, but library B is still being relinked regardless). Does anyone know if there is a better solution than a build-conflicts? Looking through the gimp changelog (as an example), it seems that this problem has been seen and dealt with before in other packages. Anyway, if anyone has ideas then I'm all ears. Ta - Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem with libtool relinking
Hi Alexis, > So maybe putting the -L/-l linker args in LIBADD instead would fix the > problem. I tried this out over the weekend, and it worked a treat. Thanks for that, Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gimp1.2: gimp package suggest non-free software
> > Sometimes I wonder how I'd feel if some spoke of men in such a > > way. This occurs much less often than its opposite. > > I would laugh a lot if some woman made a comment similar to mine, but > regarding the size of other part of the masculine body :-) In fact, the > ability to counter my sexist jokes with other jokes would be something that > I'd really appreciate in a woman :-) The difference is probably that men have somewhat less of a history of being evaluated this way when people aren't joking. b. :)
How to depend on Japanese fonts?
Hi. I have a question in relation to #216440 (kiten requires Japanese fonts): Is there a simple or recommended way of making a package depend on Japanese fonts? The only solutions I can see are to either: 1) pick a couple of decent fonts and include them in the depends list; 2) pick a couple of decent fonts and include them in the recommends or suggests list; 3) make a list of all Japanese fonts (separated by | ). Option (1) seems bad because it forces a choice of font that the user might not want (bear in mind that Japanese font packages can be quite large). Option (3) seems bad because it's ugly and difficult to keep up-to-date. And of course option (2) seems bad because the hard dependency is lost. Any suggestions? Ben.
Re: How to depend on Japanese fonts?
> > Is there a simple or recommended way of making a package depend on > > [Japanese] fonts? > > It is categorically impossible and should not be done. Point taken. My question then is: is there a simple/recommended way of making a package suggest/recommend Japanese fonts? Given that it's not a hard dependency I'm now tempted just to pick a couple of good ones and include them in the suggests/recommends list. b.
Re: Bug#158631: ITP: mp32ogg -- Converts mp3 file to Ogg Vorbis
> Maybe, but I think lots of people will have to convert mp3 to vorbis if mp3 > decoder dispear from Debian. > mp32ogg is the way to help us. But I still don't understand how we can have mp32ogg if mp3 decoders disappear from debian, since presumably one must decode the mp3 in order to convert it to ogg? Ben.
Terraform up for adoption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So I have less and less to do with GNOME anything and I suspect the terraform package would really be better off with someone else. Anyone wants to adopt it, be my guest. There's a new upstream version, and hopefully the povray patches can be removed since povray 3.1 has finally been uploaded. If anyone does adopt it please drop me an email to let me know. The wnpp bug is #156372. The package description is: Allows you to create a fractal terrain (also called a height field) and transform it using a number of algorithms. It is meant to be a tool for those who want to generate digital terrain models for use in raytracing or other simulations. - -- Ben Burton [EMAIL PROTECTED] | [EMAIL PROTECTED] http://baasil.humbug.org.au/bab/ Public Key: finger [EMAIL PROTECTED] If Michelangelo had been straight, the Sistine Chapel would have been wallpapered. - Robin Tyler, Washington, 9 Jan 1988 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9chBLMQNuxza4YcERAhT/AJ9LUaBePjYJIU3FXChAMuw9+5mPiwCfSgYP SmJhE4d2k0R2vYabXGEVA3o= =R03r -END PGP SIGNATURE-
Pending removal of konverse/kdestudio
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all. At some near point in the future I'm going to ask for the removal of konverse and kdestudio from sid/sarge. Konverse doesn't work so well and by all appearances seems dead upstream. Upstream assures us they're in the middle of a complete rewrite but this has been the case for some time now and it's not clear how long it will take. Once this rewrite appears I'm perfectly happy to have it back, but until then it seems better IMHO to remove it completely. KDEStudio on the other hand *is* dead upstream; upstream has a notice to this effect on their website. I plan to keep it around as long as KDE2 is in sid, but once sid moves to KDE3 I'm again going to request its removal rather than do the port. So if anyone wants to rescue these packages from their imminent fate, please mail me; otherwise I'll keep maintaining them until the KDE3 transition and then file bugs on ftp.d.o for their removal. Ben. - -- Ben Burton [EMAIL PROTECTED] | [EMAIL PROTECTED] http://baasil.humbug.org.au/bab/ Public Key: finger [EMAIL PROTECTED] If this is the way Queen Victoria treats her prisoners, she doesn't deserve to have any. (Complaining at having to wait in the rain for transport to take him to prison) - Oscar Wilde -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9crCyMQNuxza4YcERAigyAJ4lFPkwTL3vHYnFlCVgWcLelC+pIQCfRDN0 o6/aPNZOICQ2zkmpVwgyAbo= =deL7 -END PGP SIGNATURE-
Re: Kivio with KDE 3.1.1 ?
> seems like broken package..? Broken in what sense? Kivio 1.2.x certainly had its problems as one of the more unloved children of the koffice suite. But kivio is getting some loving in CVS now, and since koffice has just begun tagging 1.3 betas you can expect some improvements in 1.3 when it comes into sid. Ben.
Conflict: libgb
Hi. I am currently packaging Gnome Basic (ITP: #94328) which wishes to install /usr/lib/libgb.* and /usr/lib/libgbrun.*. After searching through the debian package directory it appears that package sgb also installs /usr/lib/libgb.*. Gnome Basic is unrelated to package sgb and the libraries have completely different functionalities. What is the protocol when a situation like this arises? The policy says nothing about libraries, but for binaries it says to post to debian-devel; hence this mail. Thanks, Ben. -- Ben Burton ([EMAIL PROTECTED]) http://baasil.humbug.org.au/bab/ Director of Training Australian Informatics Olympiad Committee Man is the only animal that blushes - or needs to. - Mark Twain
Re: Conflict: libgb
> As the sgb maintainer, it would probably have been wise to email me as > well ([EMAIL PROTECTED] would do). I just happened to see the > email Hi.. sorry, I completely didn't think of it (as with so many other things this last week, which has been a complete disaster but anyway..). > Anyway, is the Gnome Basic library "standard" (in some vague sense of > the word)? Do people expect it to be installed with that name? It's still very preliminary at the moment. My understanding is that it's not "standard" but wishes eventually to be an alternate [VB-compatible] standard. Scripting already exists for Gnome but I understand the plan is to allow VB scripting for apps similar to that which exists for the Other office suite. I'll mail the gb list and enquire further. Of course there are no packages in Debian which use Gnome Basic either, since this is its first packaging. Ben. -- Ben Burton ([EMAIL PROTECTED]) http://baasil.humbug.org.au/bab/ Director of Training Australian Informatics Olympiad Committee What we have got is a dead carcass, swinging in the breeze, but nobody will cut it down to replace him. - Paul Keating, on John Howard
Fwd: Re: [GB]Conflict with name libgb.so
Hi.. just received this from the primary Gnome Basic author. I'll make the suggested changes and merge the Gnome Basic stuff into /usr/lib/libgbrun.so; Stanford GraphBase need not be touched. Ben. -- Forwarded Message -- Subject: Re: [GB]Conflict with name libgb.so Date: Mon, 30 Apr 2001 23:36:12 -0400 (EDT) From: Michael Meeks <[EMAIL PROTECTED]> To: Ben Burton <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Hi Ben, On Mon, 30 Apr 2001, Ben Burton wrote: > Hi. I am currently preparing Gnome Basic packages for Debian. As it > happens, there is another package (Stanford GraphBase, package sgb) > which also provides /usr/lib/libgb.so. Thus one of us will have to > have Debian packages with libraries named differently from the > upstream sources. Ok, well - I would be fairly happy to move to integrating libgb.so into libgbrun and just installing libgbrun [ which sounds somewhat more unlikely to conflict with anything ]. > What is the severity of renaming the Debian libraries to libgbparse.so > or something similar? Do people currently expect it to be installed > as libgb.so and will more people expect this in the future? How > "standard" is libgb.so and how standard is it likely to become? Not very standard. > Sorry, I realise these questions are vague but we're trying to resolve > the conflict with Debian packages and any input is helpful. Sounds fine, a patch to the automake stuff to create a non-installed libgb.a and merge that with libgbrun.so would be appreciated. Regards, Michael. -- [EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot --- -- Ben Burton ([EMAIL PROTECTED]) http://baasil.humbug.org.au/bab/ Director of Training Australian Informatics Olympiad Committee If you have the same ideas as everybody else but have them one week earlier than everyone else then you will be hailed as a visionary. But if you have them five years earlier you will be named a lunatic. - Barry Jones
Fwd: Re: ITA: centericq - A text-mode icq client based on ncurses
> >The following packages are up for adoption: > > centericq (#95054), offered 10 days ago > > Description: A text-based ICQ client > > What is happening here? Standard procedure for adopting a package is to retitle the RFA bug (#95054) from RFA: to ITA: once you plan to adopt, and then to close the bug once your new packages have been uploaded. See http://www.debian.org/devel/wnpp/ for further details. >From looking at the bug report, it seems neither task has been done yet, which is why the system thinks the package is still up for adoption. Ben. -- Ben Burton ([EMAIL PROTECTED]) http://baasil.humbug.org.au/bab/ Director of Training Australian Informatics Olympiad Committee He hasn't an enemy in the world, and none of his friends like him. - Oscar Wilde
Re: how to implement a renamed package
> Thanks, - I know this and have done it previously in the case of > zicq and krolden. However, what I really wanted to know is, how > this (or any other) procedure can take care that the users of the > old package will get the renamed package automatically updated with > 'apt-get upgrade'? Otherwise, the new (renamed) upstream version > could be easily overlooked and the users would just wonder why the > old package is removed from the archives. Hi.. I've never done this myself, but I'm sure I've seen it happen in the past: If you're replacing foo with newfoo, you upload a new dummy package foo that contains absolutely nothing, but depends on newfoo. This way apt-get upgrade will get the latest (empty) foo and thus drag in newfoo with it. Of course you should take this with disclaimers because I'm just going on what I think I remember seeing from past upgrades on my own machine. Ben. -- Ben Burton ([EMAIL PROTECTED]) http://baasil.humbug.org.au/bab/ Director of Training Australian Informatics Olympiad Committee Feminism... is about a social, anti-family political movement that encourages women to leave their husbands, kill their children, practice witchcraft, destroy capitalism and become lesbian. - Pat Robertson, candidate for the Republican presidential nomination, 1988
Re: what's wrong with last KDE update?
(Btw, questions like this are best posted to debian-kde). > kde: Depends: kdelibs3 (>= 4:2.2.1-1) but 4:2.2.0-final-3 is to be > installed This tells you what's wrong; the newest kdelibs packages have not yet made it to the FTP servers. Have another try tomorrow. :) Ben.
Re: A language by any other name
> British English is beautiful where it appears in poems, plays, and > novels by Shakespeare and Wilde and other brilliant English authors. > It certainly does NOT belong in the ls man page. Why such emphasis? The idea is to spell words like "colour" instead of "color", not to write the ls man page in iambic pentameter. I am reminded of an email I saw some years ago with error messages in Haiku. Ben. :)
Re: [kde] and, for my next trick ...
> The libpng[23] screwup in unstable is now more or less resolved with
> kde{base,graphics,network} in incoming. Now, the only packages that need
> rebuilding are kdeaddons, kinkatta, kmerlin, koffice, and maybe kdetoys
> (not sure on that one - Ben?). kdelibs was installed last night.
I don't believe kdetoys needs a rebuild.
As for koffice and kdeaddons, my network access at this conference is
somewhat less than I had hoped for and I won't be able to upload new builds
for another week or so. If people are happy with that, that's cool. If
someone desperately needs it sooner and feels the need to NMU, that's cool
also but please talk with me first so we can discuss what changes you're
planning if any.
Ben.
Bug#141126: ITP: konq-speaker -- text-to-speech plugins for Konqueror and Kate
Package: wnpp Version: N/A; reported 2002-04-04 Severity: wishlist * Package name: konq-speaker Version : 0.4 Upstream Author : George Russell <[EMAIL PROTECTED]> * URL : http://dogma.freebsd-uk.eu.org/~grrussel/speaker.html * License : GPL and LGPL Description : text-to-speech plugins for Konqueror and Kate This package contains text-to-speech plugins for Konqueror (the KDE file manager and web browser) and Kate (a KDE text editor). Text-to-speech is provided by the festival speech system. These plugins can be accessed through Konqueror's Tools menu and the plugin manager in Kate settings. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux espresso 2.4.18-686 #2 Wed Mar 20 20:21:31 EST 2002 i686 Locale: LANG=C, LC_CTYPE=C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
libusb and testing?
Hi.. out of curiosity, does anyone know what's keeping the new libusb out of testing? I can't find anything useful in update_excuses.html and I can't make sense of the lines in update_output.txt. I ask because it seems to be holding a fair few things up (my particular concern is that it's holding up a newer kghostview which will stop every koffice app from crashing when you try to print preview). Just wondering what remains to be done to let libusb 1:0.1.5-3 in. Thanks - Ben. -- Ben Burton [EMAIL PROTECTED] | [EMAIL PROTECTED] http://baasil.humbug.org.au/bab/ Public Key: finger [EMAIL PROTECTED] Ordinary riches can be stolen, real riches cannot. In your soul are infinitely precious things that cannot be taken from you. - Oscar Wilde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libusb and testing?
> The (obvious) problems were : > - sane-backends/sane-frontends RC bugs > - gphoto2 not building on arm > - kdegraphics not building on arm Well, not obvious since they were already fixed AFAICT (unless I'm more incompetent than I thought). > The hidden problems were : > - pencam depending on libusb0 on m68k and sparc (bad build-deps) > - libgpio depending on libusb0 on sparc (bad build-deps) Cool, this is what I was asking for. I'll sit and wait for the NMUs. Thanks - Ben. -- Ben Burton [EMAIL PROTECTED] | [EMAIL PROTECTED] http://baasil.humbug.org.au/bab/ Public Key: finger [EMAIL PROTECTED] Experience is one thing you can't get for nothing. - Oscar Wilde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
