Re: Debian women may leave due to 'sexist' post
On Sun, Dec 28, 2008 at 02:31:16PM -0600, Steve Langasek wrote: On Sun, Dec 28, 2008 at 09:04:24PM +0100, Norbert Preining wrote: Bummer, please stop that bullshit. I don't know your origin, but Lisi Reisz doesn't sound like an Arabic, nor Indian, nor African name, so probably your marriage was not arranged. If it was indeed, sorry for the bullshit above. If it wasn't, what the hell are you talking??? Get a life! by law down-moted to second class citizenship when we married It was *YOUR* decision, and in the countries I am imagining you living there is parity between spouses. If it wasn't in your case, it was a wrong choice of yours. Rights for women, yes, but femminist bullshit like the above, please don't unload your personal (ex-)marriage problems on men-in-general, go to a therapist. But who are you to decide what the rest of us may or may not do? Here I agree with Lisi, you can discuss whatever you want. Please spare the rest of us from being subjected to your discussion and take it off list. It has nothing to do with Debian development, and I'm embarrassed to read such comments from a fellow Debian developer. I never thought when I left that I'd be compelled to either a) post to -devel, or b) agree with vorlon, but here we are. AOL. Cheers, Daniel signature.asc Description: Digital signature
Re: dpkg semi-hijack - an announcement (also, triggers)
[Not subscribed, Cc if you want me to see it.] On Sun, Mar 09, 2008 at 01:19:58PM -0800, Mike Bird wrote: Ian hijacked his own program back from the people who had been blocking updates for six months So Ian Murdock would be perfectly entitled to kick out the DAM, DPL, TC, DSA, and all others to really fix Debian? including the triggers enhancement which is needed for boot time improvements No, it isn't (better documented by other replies). By blocking functionality for six months the old dpkg team has actively harmed Debian. I was going to ask on which grounds exactly you were judging the dpkg team's competence (and that of iwj's: have you reviewed the branch yourself? can you confidently say that it's all fine?), but instead I'll ask this: How have you helped Debian in the last six months, if the dpkg team has actively harmed it for the last six? He has chosen to do neither, which for me personally means I can no longer trust Raphael. Tragedy. Daniel signature.asc Description: Digital signature
Re: GCC 4.1 now the default GCC version for etch
On Mon, Jun 19, 2006 at 03:49:01PM +0200, Bastian Blank wrote: On Mon, Jun 19, 2006 at 02:59:37PM +0200, Henning Makholm wrote: The fix should be somehow unclumsified, though. Currently I inject some horrible runtime testing in the configure script to find out whether the clib supports the %zu format of C99, but that breaks crosscompilability (which I'm not sure worked before, but still...) What is the problem with just assuming that %zu works? C99 is not 7 years old and this is one of the easier things. Not all of us have the luxury of assuming C99 systems. One major project recently bumped its minimum toolchain requirements from KR to C89, and is quite a ways from being able to assume C99 features yet. signature.asc Description: Digital signature
Re: Sun Java available from non-free
On Wed, Jun 07, 2006 at 09:41:27AM +0100, MJ Ray wrote: Anthony Towns aj@azure.humbug.org.au [...] If people have weighed the costs and benefits of contacting -legal and decided not to, that's entirely their choice. Yes, that package maintainer may choose to ignore all of policy. It's entirely my choice how to respond to that. Everyone happy with that? Yes, but policy is generally sensible, edited by DDs, and each change is carefully vetted. debian-legal, OTOH, claims that not only is the stock MIT/X11 licence 'non-free', but 'it is impractical to work with such software'. It is mandated that all Debian packages follow policy. It is no more mandated that developers run everything past -legal, than that they run every change they make past #debian-devel. signature.asc Description: Digital signature
Re: Please revoke your signatures from Martin Kraff's keys
On Fri, May 26, 2006 at 04:18:15PM -0700, Paul Johnson wrote: On Friday 26 May 2006 00:50, Josselin Mouette wrote: Le jeudi 25 mai 2006 à 02:36 -0500, Manoj Srivastava a écrit : It has come to my attention that Martin Kraff used an unofficial, and easily forge-able, identity device at a large key signing party recently. FWIW, I'm pretty sure Martin presented me an official German ID card. But should I revoke signatures from developers who showed me a US driver license, a piece of plastic I could fake with my inkjet printer? I'd be inclined to say yes if they look like the new Oregon or California ones due to the lack of security features. OTOH, I live in a region with some of the highest meth consumption in the world, and I have had my identity stolen once. Damn you, social security administration... But what does it matter? Can you spot a fake Victorian drivers' licence? Fake German ID card? Do you know the distinguishing marks that differentiate a real Australian passport from fakes? Daniel, sensing misdirected enthusiasm signature.asc Description: Digital signature
Re: RFH: problems building against libradius1-dev with libtool-aware packages?
On Sat, May 27, 2006 at 06:42:40AM -0400, sean finney wrote: the latest upstream version of nagios-plugins has incorporated libtool into the build process, and no longer successfully builds in a pbuilder chroot with the following error: The real fix there, is to not install the .la file, ever. It's a world of hurt, and gains us nothing on Debian systems. signature.asc Description: Digital signature
Re: Sun Java available from non-free
On Mon, May 22, 2006 at 01:08:17AM +0200, Josselin Mouette wrote: By reading your email, I feel you are acknowledging the fact the ftp-masters cabal (I can't name it otherwise after seeing their behavior IRL) is treating other developers as second-class contributors who should just do as they say. Actually, Josselin, in this regard you are second-class, by simple virtue of not being an FTP master. Just like I don't get to dictate how GNOME gets packaged in Debian, and you don't get to dictate how X gets developed in Debian, without the aid of a GR: the ultimate tool of democracy. Hope that helps, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Easy way to incorporate Ubuntu improvements back into Debian?
On Fri, May 05, 2006 at 12:09:01AM -0700, Dustin Harriman wrote: Ubuntu benefits alot from Debian. They have custom development tools for streamlining the process of taking Debian packages and making them into Ubuntu packages. I'm curious: does the reverse of this exist for the convenience of Debian Developers somehow? For example (just a thought): how about a Debian Developer receiving an email every time Ubuntu has added something (possibly juicy) to a Debian package (that the DD maintains) upon Ubuntu adding it? In this way, the juicy bits that Ubuntu adds could possibly get back to into Debian quicker. What processes, infrastructure and tools are in place to streamline Debian integrating improvements Ubuntu makes? See the Utnubu project (on Alioth). Having automatic mail notifications and the like was discussed, but many DDs did not want anything to do with it, so the idea was quickly dropped. The reason I ask is that there are several huge usability improvements that Ubuntu has over Debian that I would love to see in Debian. What are the chances of Debian catching up to the quantum leap in usability that Ubuntu has added in Etch? Has Ubuntu been consistent in sending all these goodies back upstream to Debian (or farther)? It seems to me that Ubuntu is getting alot more out of their friendship with Debian, than Debian gets out of Ubuntu. Anyone have comments on this? Please correct me if I'm wrong, and examples would be great. Does Debian get lots of benefits from Ubuntu (in the software) that I'm unaware of? ... GNOME, Xorg, et al. signature.asc Description: Digital signature
Re: Re: XOrg transition, status of libxaw8
On Thu, May 04, 2006 at 10:15:36AM +1000, Drew Parsons wrote: On Wed, 2006-05-03 at 15:23 +0200, Wouter Verhelst wrote: On Wed, May 03, 2006 at 10:26:21PM +1000, Drew Parsons wrote: Wouter asked: Just out of curiosity, could you point me to arguments in favour of Xprint? http://www.dailynews.co.th/ QED Err. You're saying Xprint is the only print implementation that can print non-latin stuff properly and reliably? Yes, that's right. Unless you've taken particular pains to install your non-latin fonts the right way and get them used by mozilla the right way, the default mozilla printer just renders them with empty boxes, making the text a tad difficult to read. Xprint manages to print them legibly without making further particular efforts to set up the fonts. I won't claim the result is always picture perfect (I'm expecting quality to improve with X11R7.1), but at least you can read it. There is apparently some new FreeType support in mozilla printing which might change things (see http://www.jw-stumpel.nl/stestu.html#T9.3.2), but Xprint works where the default mozilla postscript driver does not. I didn't set Mozilla up with anything special at all, and you might remember me showing you dailynews and Russian/Japanese/etc sites rendering correctly, all the way back at LCA 2005, I think it was. ;) Cheers, Daniel signature.asc Description: Digital signature
Re: Possible conflict with XFree 4.5
On Sun, Apr 30, 2006 at 09:03:19AM -0500, Gunnar Wolf wrote: There is no xorg 7.0 backport yet, and I fear it will not be easy to add one (as the Debian xorg 7.0 introduced _major_ packaging changes, if somebody puts up a backport it will probably be completely made from scratch to behave as close as xfree 4.3 as possible). That would be basically the worst-case scenario, and completely tank all upgrades, given the huge number of versioned conflicts et al needed to ensure even a vaguely smooth upgrade. signature.asc Description: Digital signature
Re: Apache 2 maintenance status?
On Thu, Apr 27, 2006 at 05:58:58PM +0200, Olaf van der Spek wrote: On 10/29/05, Olaf van der Spek [EMAIL PROTECTED] wrote: Hi. Does anyone know the Apache2 maintenance status? Lots of bug reports appear to be 'ignored'. Examples are: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267477 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288615 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289868 Does anyone have any updates on this? It appears not much has changed in the past six days. I heard that Apache 2.2 is about to be uploaded, but I've no idea which bugs that fixes. Given that 2.2 packages are about to be uploaded (no mean feat: tons changed between 2.0 and 2.2), I'm going to go out on a limb and say that it's being maintained in this point in time. I only looked at the first bug you quoted, but you have conversed with the current active maintainers on that bug, and it's not a groundbreaking omgwtf-everything-is-broken bug. It's wishlist. signature.asc Description: Digital signature
Re: Bug#365010: Xserver G5 usb keyboard not loaded ...
On Thu, Apr 27, 2006 at 08:28:11PM +0200, Sven Luther wrote: Notice also that both you and Colin Watson, where donated pegasos machines, (and guess who arranged that), so the unavailability of a decent build machine is no excuse. I can't speak for the other guys, but I have a Pegasos machine (sitting under my desk at the moment, actually), sent to me by yourself. You offered it to me when I told you that I had no powerpc machines, and thus couldn't test X with PowerPC. I made it very, very clear to you that I could not guarantee that the machine would ever get turned on, let alone used productively. Repeatedly. You said that was fine. However, you then got upset when Pegasos support lapsed, and ripped into me for not doing enough to fix it, given that you sent me an ODW. So, I can't help but think, maybe this is another case where people explicitly told you that they couldn't ensure the machine was used productively, but you still got upset when it wasn't? signature.asc Description: Digital signature
Re: Possible conflict with XFree 4.5
On Wed, Apr 26, 2006 at 02:51:08AM +0200, Adam Borowski wrote: On Mon, 24 Apr 2006, Gunnar Wolf wrote: - So the answer is right, why would you want to use XFree now? I guess, he has unsupported hardware, ugly proprietary drivers, etc. I don't know of any hardware supported by XFree86 4.5 that X.Org 6.9/7.0 doesn't support. signature.asc Description: Digital signature
Re: fonts prbl in sid
On Mon, Apr 24, 2006 at 11:22:42AM +0200, A Mennucc wrote:
I use sid and Gnome ; I upgraded my box (after 3 weeks in which I did
not have time to) ; now I have serious problems with fonts.
Symptoms: some programs fail to find and use the fonts ,and are then
almost unusable ; including 'emacs-snapshot-gtk' 'display' 'xmms'
('xmms' is missing fonts for the menus but not for the main display);
'gpr' 'gnomecal' .
Sounds like the libfontenc issue. Try rebuilding it with
\$${datadir}/fonts/X11, instead of \$${datadir}/X11/fonts, in
debian/rules.
signature.asc
Description: Digital signature
Re: Bug#365010: Xserver G5 usb keyboard not loaded ...
On Sat, Apr 29, 2006 at 04:13:10PM +0200, Sven Luther wrote: So, with all that said, do you still believe it is normal that a perfectly running daily build was rejected in maybe a few minutes/hours after i sent that email, while i had offered to continue running it until a proper replacement was found, and some unstable solution has been used ever since, which doesn't even include to this day the miboot support ? If you're going to attempt to drag other people into your petty personal tiffs, you might as well at least try to rope in people who are sympathetic to your cause. signature.asc Description: Digital signature
Re: X11R7 and what this transition means for you
On Sun, Apr 16, 2006 at 06:44:20PM -0700, Steve Langasek wrote: 6) Finally, in addition to everything else that's moving out of /usr/X11R6/, packages providing fonts for X should now install to /usr/share/fonts/X11 instead of to /usr/X11R6/lib/X11/fonts. The heirarchy is the same as before, as are the commands to manage fonts; to ensure your font package's compatibility with the installed Xorg system, you should only need to bump your dependency on xutils to xutils ( 1:7.0.0). The plan is that xorg.conf will support both the old and new paths by default for this transition. If you're using debhelper's dh_installxfonts to install fonts for you, rather than doing it by hand, you need to explicitly Build-Depends on debhelper (= 5.0.29), in addition to fixing any references to /usr/X11R6/lib/X11/fonts, or /usr/lib/X11/fonts, in your package. Cheers, Daniel signature.asc Description: Digital signature
Re: X11R7 and what this transition means for you
On Mon, Apr 17, 2006 at 06:18:21PM +0800, Eugene Konev wrote: This part is broken now. So I ask you please _do not_ yet upload rebuilt packages if you use dh_installxfonts. Or you should handle your maintainer scripts by hand. The required (as from X11R6) changes are: * place your *.scale and *.alias files in /etc/X11/fonts/X11R7/category/ instead of /etc/X11/fonts/category/ I'd imagine this will be fixed. * call update-fonts-dir (-scale, -alias) with --x11r7-layout (or -7) switch. This is a bug in xfonts-utils that will be fixed. signature.asc Description: Digital signature
Re: Possible conflict with XFree 4.5
On Sat, Apr 15, 2006 at 04:17:28PM +0300, gustavo halperin wrote: I think that we have a problem when the common library between XFree and /usr/lib are update in /usr/lib. I currently have XFree 4.5, when the library libfontconfig1 was update to version 2.3.2-1 was also updated the file libfontconfig.so to the version 1.0.4 but in the XFree (/usr/X11R6/lib/) this library still be the version 1. The problem came we we use programs like Gimp that must at least version 1.0.2 of this library. I solve this problem by link the libfontconfig in /usr/X11R6/lib to the newest library in /usr/lib. That is the solution or that is a Bug in Debian System ?? I assume that you're installing XFree86 4.5 by yourself, since it wasn't packaged for Debian. In that case, local installation conflicts are your problem to sort out. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libgtk2.0-0: changelog.Debian.gz is not an upstream changelog
On Sun, Apr 16, 2006 at 12:02:42PM +0200, Christian Marillat wrote: Florian Weimer [EMAIL PROTECTED] writes: * Christian Marillat: Florian Weimer [EMAIL PROTECTED] writes: [...] Where are you reading that ? An upstream change is a change to the Debian package, too, and listing them is expressly allowed under the other changes option. I'm sorry but no. Read again. The Debian changelog is for Debian changes not upstream. For that we have a changelog file and a NEW file. Changes in the Debian version of the package should be briefly explained in the Debian changelog file `debian/changelog'.[1] This includes modifications made in the Debian package compared to the upstream one as well as other changes and updates to the package. Does it say that everything else is specifically excluded? Do you really have nothing better to do with your life than argue semantics about an ambiguous sentence[0]. Please get off this list and do something more productive with your time. [0]: One could well read it as, the Debian-specific changes, and also the upstream changes and anything else done to the package as a whole. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian package-has-a-duplicate-relation
On Sun, Apr 16, 2006 at 12:18:58PM +0200, [EMAIL PROTECTED] wrote:
Is there a way to force a specific library version known in
${shlibs:Depends} ?
Using Depends: ${shlibs:Depends} is not really fine, if I want to
force the library to be upgraded when the primary binary package is
updated.
However,
Depends: ${shlibs:Depends}, libmypackage1 (= ${Source-Version})
Will make lintian scream.
I could abandon the use of ${shlibs:Depends}, and list each dependencies
manually, but this is a bit annoying.
Any clever suggestions ?
Why? If your library's ABI is changing with every revision, you should
be bumping the soversion.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#354674: What on earth?
On Sun, Apr 16, 2006 at 04:31:10PM +0200, Pierre Habouzit wrote: I welcome the fact that you bear your responsabilities, that's a quality fewer of us have. Though, the .la problem is not the sole one the modular Xorg raised. - /usr/X11R6/bin/X disapearing broke login managers (gdm, kdm) This is being rectified, as a perfunctory glance at -x will tell you. - fonts transition was unanounced and users have either : * only non transitionned fonts if their xorg.conf was modified * only xorg ones if they use dexconf that's a mess. This is being rectified. - a lot of build depends were missing, something that the first build on autobuilders revealed, which makes me wonder if the XSF knows about pbuilder and friends ? This is being rectified, obviously, but I'm sure the people doing the packaging appreciate your slight at their skills. Well, knowing to apology is good, but knowing how to prepare a transition is also needed. I just can quote steve on this : » So far I'm very unimpressed with the resultant bug count from the » Xorg 7 transition. I can predict that the Xorg 7.0 will be the messiest debian will have to face in years, because everything is done in a hurry, and that each new uploads adds as many bugs (if not twice as many) as it solves. So maybe it's now time to calm down the upload rate (yeah unstable is broken, but it's too late for that anyway, and after all it's not called unstable for nothing), let's have some communication to have it fixed, instead of pile of clumsy patches. So, let me get this straight: on one hand you're complaining about bugs, and on the other hand, you're complaining about bugs being fixed? The workload of the XSF members getting things fixed is very admirable. Could please the XSF communicate, and announce what that damn transition implies for *everybody*, instead of letting anybody finds out that their package is broken. I suggest [1] as a very good template for what communicating about a transition means. Thanks a lot for your help. David has posted a couple of messages on debian-devel-announce discussing the transition (including xlibs-dev), and what it means for everyone. Most of the transition was co-ordinated in excruciating detail, including a long time in experimental where testing failed to uncover these sorts of problems. The rest are purely transitive. You don't need a plan to tell you that fonts are being migrated, that Build-Depends are being added as they're being caught, or that the /usr/X11R6/bin situation is nearly totally fixed. This is unstable. Sometimes the name rings true. With regards the .la files: mea culpa. I was partially unaware of the full extent of the damage, and partially unaware that the release team considered it such a problem. If you really don't like it, wait a few days until the transition blows over and the coast is clear. It's one of the biggest transitions Debian has had, and sometimes the problems aren't always clear. (Hence the delay in experimental, waiting for testers.) Daniel signature.asc Description: Digital signature
Re: Bug#354674: What on earth?
On Sun, Apr 16, 2006 at 10:52:21AM -0400, David Nusinow wrote: As for the build-depends, pbuilder is, as far as I've been able to understand it, completely incapable of handling such a massive beast as this. You can't point it easily at a custom repository in order to have it pull from there. If this has changed recently, I'd love to hear it, but when I was investigating this during the development of the packages I was unable to do it. Furthermore, the packages I pulled were autobuilding just fine on Ubuntu, so I had little reason to believe that they didn't have proper build-depends for Debian. Indeed, very few of the packages ftbfs'ed, and most of these were fixed within hours of being reported. I should point out that the FTBFSing packages were ones that were repackaged from the ground up to be more sensible, not pure imports from Ubuntu. That being said, I agree with the thrust of David's mail. And, on my behalf, apologise to the release team for any disruption incurred to Etch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#354674: What on earth?
On Sun, Apr 16, 2006 at 07:19:40PM +0200, Pierre HABOUZIT wrote: In-Reply-To: [EMAIL PROTECTED] On Sun, Apr 16, 2006 at 10:52:21AM -0400, David Nusinow wrote: I'd like for you to back this claim up. So far I've fixed dozens of bugs over the course of the past week at great personal and professional cost of my time, energy, and health. And I plan to keep whittling away at the bugs until the transition is as clean as I can possibly make it. well, like said, it's a bit late for that. And about your bug load, let me say it loud clear: the current load you are experiencing was created by your way to package X.org 7.0, not anticipating any of the problems. I won't say your current rate of bug fixing isn't remarkable outside from the current contexte. But please, when someone run into a wall, nobody will think that his survival is a remarkable thing. It's a bit late to back your claims up? Come on man, lay off the guy. David made a couple of mistakes in handling X in Debian. So did I. I made a ton more handling X outside of Debian. So what? He's apologised *repeatedly* for what he feels he needs to apologise for. Just move the hell on and stop being such a dick. I communicated, to the best of my knowledge, what the transition meant in the past [0]. I wasn't aware that I would be breaking a large amount of packages until after I uploaded to unstable. These packages have largely been in use in Ubuntu for several months already. They have been in experimental for several months as well, during which time I fixed every bug that came in about them. I communicated with the release team what my plans were at all stages, and while I didn't realize the scope of the disruption, I did my absolute best to keep everyone involved informed. Every single change I've done to these packages has been documented on debian-x via the svn commits, so everyone could see what I've been doing if they cared to look. I'm shocked that you didn't anticipate *any* of the problems you ran into. after all, you've broken : *dm, fonts, made FTBFS a lot of programs linking against xlibs, ... That looks to me like beeing an reasonnably complete coverage of the things X.org is supposed to achieve. The affirmation This worked fine in ubuntu looks like a very loose quality quality test for a first upload of a totally new layout of an X server. It worked fine in Ubuntu, across a couple of releases. It worked fine in experimental -- where I notice you haven't been testing. If you're concerned about xlibs-dev, maybe you should try subscribing to this list called debian-devel-announce? There were *two* posts to d-d-a about xlibs-dev, including a co-ordinated mass bug (and patch!) filing. I thought your complaint was both annoying and petty in the first place, but now you're provably wrong, to boot. Anyway, I'm going to continue to work hard on this. If you want to help dig us out of it, I'll welcome any patches you care to submit that are up to your standards of quality. I'm already fixing a huge load of RC bugs doing NMU to clean packages that are in a loosy shape since a lot of time, and that does not seem to have an active enough maintainer. I hope X.org does not qualify yet to those criteriums. Are you seriously suggesting that you would be a better X maintainer than David, assisted by his team? Are you suggesting that, under the circumstances, you could've done a better job with X11R7? Or (and I suspect this is more likely) are you just saying this because you like flaming people into the ground on mailing lists, for no apparent reason? If you want to do something productive[0], how about you go and fix some of these issues, instead of whining on debian-devel? In-Reply-To: [EMAIL PROTECTED] - /usr/X11R6/bin/X disapearing broke login managers (gdm, kdm) This is being rectified, as a perfunctory glance at -x will tell you. Are you serious ? Do you read debian-glibc@ each time you upload a package ? please, if something has te be known related to a migration, it has to come from the team that launched that migration. It's not to the others developpers to go read -x, it's up to you to inform them. It's not as much a migration issue as a bug. /usr/X11R6/bin should be a symlink to /usr/bin. Right now, in *some* cases, that doesn't happen. In most cases, it does. I don't expect to get personalised updates from seb128 every time Metacity introduces some bug which results in focus behaving very weirdly. I just expect that, in due course, the bug will get fixed and that the fix will work its way into unstable. If this is a little too much for you, may I suggest the testing branch? It's much less ... well ... unstable. So I really expect that in a really near future I'll hear from you (as a team member of the QT-KDE team that packages kdm), that gdm maintainer will hear from you as well, and that font packagers will see bugs go through the
Re: Bug#354674: What on earth?
On Sun, Apr 16, 2006 at 07:19:40PM +0200, Pierre HABOUZIT wrote: I'm complaining because *you* created the huge load of bugs you have to cope with, and a lot of other you don't warn other packagers about (what pissed me, and made me write my previous mail is yet-another-RC bug because of X we received on kdm recently...). And also in your answer to me, you ask to be sanctified because you are currently in a hurry to fix them ? In the interests of science, I dived into the debian-qt-kde archives[0]. I count: * 'Still happening?' pings from Adam Porter: 19. + Responses to same: 14. + Total: 33. * Testing migration mails: 9. * Spam: 7. * X-related bugs you were warned about via d-d-a: 2. * X-related bugs you weren't warned about via d-d-a: 2. * Other BTS: I stopped counting. I have better things to do. Again, if you're going to make outlandish claims in the name of chastising others, for god's sake, at least have the decency to be *right*. 'Oh my god, I'm drowning in bugs', indeed, Daniel [0]: http://lists.debian.org/debian-qt-kde/2006/04/threads.html signature.asc Description: Digital signature
Re: per-architecture Provides field
On Thu, Apr 13, 2006 at 12:13:57AM -0700, Erast Benson wrote: On Thu, 2006-04-13 at 00:04 +0200, Loïc Minier wrote: Why not simply Provide: sunwlxsl all of the time, doesn't it provide sunwlxsl on other arches? But how? sunwlxsl is something which is only present in OpenSolaris-based derivatives, such as NexentaOS? And I'd like to putback libxslt change (and similar) to upstream, so other derivative will not be polluted with mis-provided packages. So why not have an OpenSolaris core set of metapackages, with a sunwlxsl package that Depends on libxslt1, instead of polluting every package with this port-specific stuff? signature.asc Description: Digital signature
Re: Bug#354674: What on earth?
On Thu, Apr 13, 2006 at 11:12:06AM -0400, Adam C Powell IV wrote: Please tell me if I have this right: * You don't like .la files Yes. * So you're unilaterally removing them from a core package (libxcursor) with dozens of reverse-depends, breaking all of them Yes. * Even though they're a years-old and very well established technology .la files? I wouldn't call them 'very well established'. * Which upstream libtool has not yet decided to eliminate (It's already under discussion) And X.Org upstream are currently seriously discussing whether or not to eliminate libtool, at which point you get broken away. This, believe it or not, a) improves portability, and b) makes you immune to further changes. * And which has not been discussed on debian-devel or any other Debian list as far as I can tell (Google search). Yes. Can you really be serious? Yes. For example, if the maintainer of GLib decides (s)he doesn't like the way it handles modules, and upstream *might* at some point change the behavior, is that alone enough justification to change it and break all of its dozens of reverse-depending packages? If the dependent packages can be fixed with a rebuild, and the reason is solid, rather than, 'I'm bored'? Yes. Is a rebuild really that phenomenally onerous for you? In the time spent arguing this point, tons of packages could've been simply rebuilt. I don't see where the problem lies, unless you happen to enjoy random flamebait more than actual productive work. signature.asc Description: Digital signature
Re: What on earth?
On Thu, Apr 13, 2006 at 06:52:52PM +0200, Marco Cabizza wrote: I experienced the issue while recompiling some gnome packages. Is sed s##/usr/lib/libXrender.la ##g (in the .la references, ie libgdk-x11-2.0.la) the best temporary solution by now? s##/usr/lib/libXrender.la##-lXrender##g, I believe. Cheers, Daniel signature.asc Description: Digital signature
Re: removal of svenl from the project
On Fri, Mar 17, 2006 at 02:34:27PM +1100, Brian May wrote: I can't help but get the impression Daniel may have prematurely discounted the patch - admittedly I may not understand the issues though. I dismissed the X patch Sven sent me because it was fundamentally wrong. No amount of changes to it would've influenced the fact that I rejected the entire premise behind the patch. I had nothing to do with the kernel patch. Most likely all parties involved from room for improvement. Making a developer a scapegoat on a public mailing list isn't going to make anybody improve their behaviour FWIW, I do not think public mailing lists are the place for these kinds of arguments. I get the impression Sven has contributed a lot to get Linux working on Pegasos. Yes, he has. Do we really want to force him to leave? I think not. Apparently the people behind this motion do. Debian seems to have this peculiar disease where people think that the other side just can't possibly have understood what they're actually doing, so if you explain it in condescending tones on mailing lists, then surely they'll see the error of their ways and back down. 'Well, I *was* going to expel Sven, but someone on -devel asked a rhetorical question, followed by I think not, so I'm withdrawing my support.' Unfortunately for this school of thought, (most) Debian developers are capable of rational thought and reasoning, so this doesn't actually work. signature.asc Description: Digital signature
Re: removal of svenl from the project
On Thu, Mar 16, 2006 at 12:39:42PM +0100, Julien BLACHE wrote: So, this expulsion process looks more like a good way to hurt Sven than anything else. If it fails (hint: it will) Andres will be kind of singled-out, and this whole thing will turn into I can't bear this guy, please kick him out. In the meantime, we are wasting precious DD and DAM time to satisfy Andres' need for a revenge on Sven. [...] My statement was expressing this: getting singled-out as Andres will get once this process will have officially failed is a strong indication that maybe, just maybe, you'd better leave now. Isn't your whole mail just a rather petty waste of time designed only to hurt Andres? Not to mention, if this fails, you'll still have to work on the same project (i.e., Debian) with Andres, so if you fail in your attempt to kick him out in revenge for him attempting to kick Sven out, will *you* leave the Project? signature.asc Description: Digital signature
Re: removal of svenl from the project
On Wed, Mar 15, 2006 at 09:48:11AM +0100, Frank Küster wrote: Andres Salomon [EMAIL PROTECTED] wrote: 2) Yes, I have tried talking to him. After a number of blowups on the debian-kernel list, myself and a number of kernel team members have talked to him to calm him down (and in some cases getting him to apologize). The behavior he displays happens repeatedly, despite warnings and requests that he behave himself. The rest of the IRC log from when he threatened Jonas is basically me attempting to show Sven how destructive his behavior is. The fact that, a week later, he continues w/ this behavior (after years of doing the same thing) is why you're seeing this request. Have you considered banning him from the lists/channel? Right there, in the original mail ... On Tue, Mar 14, 2006 at 09:01:09PM -0500, Andres Salomon wrote: Sven's behavior has always been combative (and some might argue hostile), but this is beyond what is acceptable. He threatens bodily harm upon another developer in a public forum, and then a week later publically insults/taunts a developer (one of the Release Managers, even), behind his back. This is incredibly childish, aggressive behavior, and should not be tolerated within the project (IMO). Cheers, Daniel signature.asc Description: Digital signature
Re: removal of svenl from the project
On Wed, Mar 15, 2006 at 12:29:49PM +0100, Julien BLACHE wrote: Andres Salomon [EMAIL PROTECTED] wrote: I am going through the expulsion process to have Sven Luther removed from the project. I want to see you leave the Project if this expulsion process fails. There's a defined process to do that. Start it, if you believe so strongly that Andres's behaviour has been offensive to the project. signature.asc Description: Digital signature
Re: removal of svenl from the project
On Wed, Mar 15, 2006 at 08:08:27PM +0100, Sven Luther wrote:
I am still a bit disgusted of seeing a bug report i provided to ubuntu, with
patch and all the proper research immediately after the breezy beta go
unanswered and uncared for though, so this may color my relationship with
ubuntu, but i did also personally remove myself from all ubuntu channels and
lists in order to not bother you with my personal issues, so seeing matthew
bring this in here is i believe not correct.
Sven,
The following is technically a well-formed diff:
--- init/main.c.orig2006-03-15 23:11:48.0 +0200
+++ init/main.c 2006-03-15 23:12:23.0 +0200
@@ -653,6 +653,9 @@
static int init(void * unused)
{
+char *foo = NULL, *bar = NULL;
+strdup(bar, foo);
+
lock_kernel();
/*
* init can run on any cpu.
However I don't think you'd be right to hold a grudge against anyone
who refused to apply it. If Matthew raised some issues with your patch,
why did you not fix them? Surely removing a debugging printk and moving
the #include to the head of the file would've been pretty obvious.
It's not an isolated event, either. My refusal to apply a patch which
was unprecedented in the xorg packaging, for an issue that I feel (with
not insignificant justification) is a purely hardware issue was
presented as me hating on Pegasos. Similarly, your refusal to fix the
patch you provided was also presented as the kernel team despising you
and the Pegasos. (Money being paid or no. Principles are principles,
mmm?)
You seem to have this horrendous victim syndrome, exacerbated by bizzare
claims you have better things to do with your time[0] when you throw a
hissy fit and leave. Turning everyone's legitimate concerns into your
code into hate crusades against you and Genesi isn't in the least
productive, and I really wish you'd grow up and let it go.
Daniel
[0]: I say 'bizzare' because I guarantee it took you longer to write
that mail than it would've to fix up the kernel patch Matthew
pointed out legitimate issues in.
signature.asc
Description: Digital signature
Re: dpkg update
On Sat, Mar 11, 2006 at 09:31:29PM +0100, Michael Koch wrote: On Sat, Mar 11, 2006 at 12:06:40PM -0800, John Gee wrote: Guys honestly why aren't we as developers doing a massive overhaul on dpkg? I feel we are running on pre-historic machines here. There needs to be at least a little looking toward the future in our blood. What exactly are you missing in dpkg that isnt already addressed by the dpkg maintainers? Please do not feed the troll. This has been a community service announcement. signature.asc Description: Digital signature
Re: For those who care about stable updates
On Thu, Mar 09, 2006 at 07:05:24PM +0100, Josselin Mouette wrote: Le jeudi 09 mars 2006 à 16:39 +0100, Amaya a écrit : but when will we try to solve some of the real problems we have Hey! It's DPL election time! Lobby around. I really am biting my tongue, but you don't have to. Who are you going to lobby? The candidates who are playing an active role in the problem, or the ones who are just claiming there is no problem and that we should all be friends? Joss, Please point me to a candidate who is claiming that 'there is no problem and that we should all be friends'. I think you'll find what they're saying is, 'don't be an idiot on mailing lists'. And here you are, being an idiot on a mailing list, which is pretty fitting, I guess. (But it is a problem.) Cheers, Daniel signature.asc Description: Digital signature
Re: For those who care about stable updates
On Thu, Mar 09, 2006 at 08:06:33PM +0100, Josselin Mouette wrote: Le jeudi 09 mars 2006 à 20:49 +0200, Daniel Stone a écrit : I think you'll find what they're saying is, 'don't be an idiot on mailing lists'. And here you are, being an idiot on a mailing list, which is pretty fitting, I guess. (But it is a problem.) If pointing at problems is idiot, I prefer to be an idiot. I will not be the one to shut up when we are losing again to a group of individuals who are deliberately hurting the project by keeping their power positions safe. I don't see how your message follows from mine (and I notice you cleverly failed to answer the main question posed there), so I'm going to let it go. If you want to start an expulsion procedure against idiots, go ahead. If only ... signature.asc Description: Digital signature
Re: For those who care about stable updates
On Thu, Mar 09, 2006 at 10:18:22PM +0100, Josselin Mouette wrote: I haven't answered the question because it wasn't one. You are implicitly answering it the line after, and I already know we disagree on this matter. Let me rephrase: 'Who exactly are the candidates claiming there are no problems, and we should all just be excessively nice to each other?'. But I'm sure you're intelligent enough to deduce that question from my statement. I was reacting to your calling me an idiot. That must be your own way of following the code of conduct [1] you are campaigning for [2]. I didn't call you an idiot. I have every reason to believe you're a relatively intelligent person. I was labelling your actions on this list. People can do stupid things without being fundamentally stupid: people can do immature or ill-considered things without generally being same. And so on, and so forth. signature.asc Description: Digital signature
Re: the latest gnome
On Mon, Mar 06, 2006 at 07:05:34PM +0900, Miles Bader wrote: Michael Banck [EMAIL PROTECTED] writes: Anyway, I don't think GNOME bashing is really on-topic here. It's not gnome bashing, it's just airing of a very common gripe with gnome. If there were indeed a viable fork that improved on some bad thing about gnome, but kept the good things, I think it would be an appropriate topic for this list (however, it seems that there is not). Why on earth are you doing it on debian-devel, then? This list doesn't need any more pointless noise: take it somewhere else, please. signature.asc Description: Digital signature
Re: On binary compatibility
On Thu, Feb 23, 2006 at 07:56:42PM -0500, Michael Gilbert wrote: The solution would be to convince Ubuntu to branch from stable instead of sid. The problem is that this creates a lot of work for Ubuntu because they have to backport all of the desired bleeding-edge stuff. However, Debian developers could work with and contribute more to backports.org making it easier for Ubuntu. This is not useful. If Ubuntu branches from sid, and, hypothetically, their packages work to produce new packages for X.Org and GNOME, then these can be contributed straight back to sid. If they're done against sarge, then the packages are not immediately useful to Debian. I don't see which problem you're trying to solve. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Sat, Feb 18, 2006 at 06:12:36PM +0200, Lars Wirzenius wrote: la, 2006-02-18 kello 10:43 -0500, Michael Poole kirjoitti: What's the purpose of an assembler without assembly code to use it on? It can be used, for example, to assemble code you write yourself. That is, after all, the primary purpose of programming tools: to help programmers develop programs. Surely ndiswrapper can also run drivers you write yourself. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: architecture-specific release criteria - requalification needed
On Wed, 2005-09-21 at 17:05 +0200, Ingo Juergensmann wrote: Petter Reinholdtsen wrote: I'm starting to suspect you do not trust the release team nor the porters to make good judgement [...] ^^^ Nono... of course not! It's just my personal experience that this sort of guidelines need either to be precise or need to be judged by a common sense. ^^^ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mesag3 - xlibmesa-gl / libgl1-mesa-dri - xlibmesa-dri / libglu1-mesa - libglu1-xorg
On Sun, 2005-09-04 at 09:04 -0600, Marcelo E. Magallon wrote:
On Thu, Sep 01, 2005 at 02:58:19PM +1000, Daniel Stone wrote:
Right. My solution for that was to split them into a separate
mesa-utils source package, with a slightly hacked Makefile. They
build just fine independently.
Ah, you mean the utils! The demos are shipped in a separate tarball.
Ah, yes, sorry.
The programs in progs/util are not generally useful. I could include
them as examples in mesa-common or something like that.
And I don't know where glxinfo is going to end up. It's certainly not
included with mesa atm.
Hm? progs/xdemos/glxinfo.c.
The problem with Mesa Build-Depping on glut is so:
* mesa depends on glut to build, which depends on libgl1-mesa-dev
* buildd goes to install libgl1-mesa-dev to fulfill B-Ds
* libgl1-mesa-dev deps mesa-common-dev (= ${Source-Version})
* mesa-common-dev version n is in the archive from the maintainer
upload
* but libgl1-mesa-dev for, say, hppa, is still n-1
- uninstallable B-Ds
Uhm, are we talking about mesa (not mesademos)?
Yeah.
Mesa-6.3.2$ find ! -type d -print0 | xargs -r0 grep glut.h
./Makefile: $(DIRECTORY)/include/GL/glut.h \
./docs/download.html:a
href=http://www.opengl.org/resources/libraries/glut.html;
./docs/README.WINDML:- src/ugl/ugl_glutshapes.c
./include/GL/gl.h: * including only glut.h, since glut.h depends on windows.h.
./include/GL/gl.h: * glut.h or gl.h.
./include/GL/uglglutshapes.h:/* uglglutshapes.h - Public header GLUT Shapes */
./progs/util/dumpstate.c:#include GL/glut.h
./progs/util/glstate.c:#include GL/glut.h
./progs/util/glutskel.c:#include GL/glut.h
Like I said before, those programs are not generally useful, at least
not in compiled form.
Hrm. glxinfo still wants to link against libglut; I guess this is just
an artefact of the build system.
As a short-term move, since we don't have Glide support in 6.3
anyway, I just disabled the Glide packages and moved the headers
across.
I decided that Glide is too much of a hassle. It will probably work
again in 6.4, that's true, but I have decided to carry with the plan I
had sketched a couple of years ago:
* Regular drivers are built from the mesa package
* Troublesome drivers (not being kept up to date, etc) are built
from a second source package (mesa-legacy)
* Whenever a new Mesa upstream is released, I look at it, if nothing
breaks (and this has happened multiple times -- recall that mesa
uses a x.y.z scheme, where odd y means in development) then I
make an upload of the source package mesa to unstable
* If one of the weird drivers breaks in the new upstream, then
figure out if it's because of some small change. If that's the
case fix it. If not (as is the case with glide in 6.3) then
move the driver to the mesa-legacy package.
* Once I figure the driver is being actively maintained, move it
back to mesa
In this way I keep the same set of binary packages, meaning that users
won't be missing functionality, and I can keep the maintained drivers
up to date.
The mesa source package is structured in such a way that it allows for
building either mesa or mesa-legacy, after tweaking debian/control, of
course. There's a small duplication of code (the mesa and mesa-legacy
tarballs are sometimes the same file, sometimes not), but taking into
account that the binary packages are *much* larger than the source I
don't think that's something to gripe about.
Okay, this sounds fine to me.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: migrating wiki content from twiki (w.d.net) to moinmoin (w.d.org)
On Sat, 2005-09-03 at 01:34 +0200, Andreas Schuldei wrote: The wiki markup languages of twiki and moin-moin are not compatible. Still it would be nice to have some content moved from the old .net wiki to the new .org one. (the debconf team for one is interested in using the features of moin-moin for easier cooperation and to keep the existing pages.) The wiki admins (DSA) would be willing to untar a tarball with the converted content to depoly it on the new system. I did not find migration scripts between the two wikis. Do they exist? Is someone who is familiar with both wikis interested in writing one? Carl Worth wrote one for fd.o; I'll try to dig it up. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mesag3 - xlibmesa-gl / libgl1-mesa-dri - xlibmesa-dri / libglu1-mesa - libglu1-xorg
On Wed, 2005-08-31 at 22:00 -0600, Marcelo E. Magallon wrote:
On Thu, Sep 01, 2005 at 12:07:46PM +1000, Daniel Stone wrote:
Sorry, I've really just not had any time recently, and there are some
things I wanted to clean up before I fired off to you (e.g. the
Build-Dep on glut, which introduced horrible Build-Deps and other
hilarity which meant that the Arch: all build *had* to come last,
etc). I'll try to get it to you this week.
Oh, you got me there.
On GLUT? I didn't spot that one. The demos depend on GLUT, but I
haven't updated those yet.
Right. My solution for that was to split them into a separate
mesa-utils source package, with a slightly hacked Makefile. They build
just fine independently.
The problem with Mesa Build-Depping on glut is so:
* mesa depends on glut to build, which depends on libgl1-mesa-dev
* buildd goes to install libgl1-mesa-dev to fulfill B-Ds
* libgl1-mesa-dev deps mesa-common-dev (= ${Source-Version})
* mesa-common-dev version n is in the archive from the maintainer
upload
* but libgl1-mesa-dev for, say, hppa, is still n-1
- uninstallable B-Ds
As a short-term move, since we don't have Glide support in 6.3 anyway, I
just disabled the Glide packages and moved the headers across.
But don't rush, I was just wondering if the email got lost :-)
No, not at all.
Please do check the 6.3.2 packages, I suspect we have fixed the same
things each on our own. I introduced another of those .map hacks for
the drivers. I also tried to make it easier to disable building some
of the targets, guessing that other distros aren't interested in the
more exotic ones.
Oh, excellent. We're still building all the targets, but yeah. I did a
bit of .map hacking for the drivers, allowing you to restrict things to
prefix and postfix.
I'll hopefully get to having a look at your packages tomorrow. Again,
sorry I've been so slack, but I just haven't had any time.
Cheers,
Daniel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mesag3 - xlibmesa-gl / libgl1-mesa-dri - xlibmesa-dri / libglu1-mesa - libglu1-xorg
On Wed, 2005-08-31 at 17:25 -0600, Marcelo E. Magallon wrote: Daniel also said he'd send a package via email which I never got, so I went ahead and did my own thing. (No Matt, I'm not happy with the idea of fishing patches out of some random, cluttered, and very unusable webpage; everything I've fixed in Mesa over the years has found its way to Brian Paul in the format he wants it over the channels he wants it, so I expect the same from my downstreams). Sorry, I've really just not had any time recently, and there are some things I wanted to clean up before I fired off to you (e.g. the Build-Dep on glut, which introduced horrible Build-Deps and other hilarity which meant that the Arch: all build *had* to come last, etc). I'll try to get it to you this week. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: arch, svn, cvs (was: Bug#323855: ITP: opencvs -- OpenBSD CVS implementation with special emphasis in security)
On Fri, Aug 19, 2005 at 02:33:31PM +0200, martin f krafft wrote: also sprach Marc Haber [EMAIL PROTECTED] [2005.08.19.1422 +0200]: Compared to SVN from the view of somebody who is acquainted with CVS, arch sucks badly. I tend to agree with most of the things that Florian Weimer lists on http://www.enyo.de/fw/software/arch/design-issues.html I won't go through the trouble to compile the extensive list of problems and design issues with SVN. vim! emacs! zsh! bash! something else! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multi-User X machine (Was: runlevels remodeled)
On Mon, Aug 15, 2005 at 02:59:17PM +0200, Petter Reinholdtsen wrote: [Steinar H. Gunderson] How do you make this work? Last time I tried it, X would only show the one connected to the ???active??? virtual console, and blanked the other. It need some patches to the kernel and X. I'm not sure how many of these are included in the mainstream kernel and X implementation yet. Check out URL:http://wired-vig.wired.com/news/infostructure/0,1377,64163,00.html and URL:http://www.linuxjournal.com/article/7852 for the story of HPs system making four desktop seats available from one machine. Ubuntu implements this from the installer down (although only for the special cases of four nVidia, MGA, or ATI cards, and even then you may need to fiddle with the configuration a little bit), with a bunch of patches to xorg -- no kernel patches required. Those patches are now in X.Org HEAD. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multi-User X machine (Was: runlevels remodeled)
On Mon, Aug 15, 2005 at 06:19:08PM +0200, Petter Reinholdtsen wrote: [Daniel Stone] Ubuntu implements this from the installer down (although only for the special cases of four nVidia, MGA, or ATI cards, and even then you may need to fiddle with the configuration a little bit), with a bunch of patches to xorg -- no kernel patches required. Those patches are now in X.Org HEAD. Cool. Any URL with info on the details involved in this configuration? Check out the multiseat and multiseat-udeb packages: http://archive.ubuntu.com/ubuntu/pool/main/m/multiseat/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multi-User X machine (Was: runlevels remodeled)
On Mon, Aug 15, 2005 at 09:50:41PM +0200, Andreas Schuldei wrote: wasnt it me who included the interesting patches into the *debian* kernel a year ago? Depends if you want multiseat X or multiseat VTs, but hearty congratulations in any case. Well done. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependency problems with Xorg
On Sun, Jul 17, 2005 at 04:28:56PM +0200, Harald Dunkel wrote: I know, but as written before, IMHO the abi version number should not be encoded in the package name. Usually you just get a new abi, but no new functionality, so why introduce a new name? Just to work around the limitations of dpkg? It is my suggestion to extend dpkg instead. Look, nice theory, but we're dealing with the realities of Debian today. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to the X team!!
On Thu, Jul 14, 2005 at 11:02:09AM -0300, Gustavo Franco wrote: I see that yesterday a modularized xserver (xorg) entered ubuntu breezy (the current development branch) archives. I've some questions: Is XSF coordinating its work with them or what ? Is modularized xorg a goal for us ? I think that it's easy to do since some if not all xorg ubuntu maintainers are DDs too. Closing, congratulations for both teams anyway. The server hasn't been modularised yet, it's just that I split up all the packaging. I've been working closely with Josh Triplett on the libraries, and keeping David fully in the loop with everything I'm doing in Breezy, and I'm pretty sure that we're going to arrive at a common base for packaging when Debian gets over to the modular tree. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to the X team!!
On Thu, Jul 14, 2005 at 11:43:50AM -0300, Gustavo Franco wrote: On 7/14/05, Daniel Stone [EMAIL PROTECTED] wrote: The server hasn't been modularised yet, it's just that I split up all the packaging. I've been working closely with Josh Triplett on the libraries, and keeping David fully in the loop with everything I'm doing in Breezy, and I'm pretty sure that we're going to arrive at a common base for packaging when Debian gets over to the modular tree. Hi Daniel, Thank you for clarifying the topic. No worries. About the split up, is there a consensus in what to install exactly ? See, the user will install all the packages related to video drivers and dexconf will do its job and it's up to the user remove what is not needed ? I'm asking about Debian, because i guess that in Ubuntu you'll autodetect as much as possible in the install and just keep there what's necessary maybe using a different approach if the user change his video card, plug a new input device or whatever. Closing, what are the side effects (if any) that this split up and modularization will put on the loop for stuff like lessdisks and ltsp ? For the time being -- both in Debian and in Ubuntu -- everything will continue to be installed. It's more about not having to update everything at the same time, really. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian concordance
On Thu, Jun 16, 2005 at 12:54:08PM -0500, Ian Murdock wrote: Daniel Stone wrote: libc6 added interfaces between 2.3.2 and 2.3.5 and made several other major changes, so all packages built with .5 depend on .5 or above, in case you use one of the new interfaces. A binary built with 2.3.2 can run with .5, but a binary built with .5 can't necessarily run with .2. Then why not build your packages against 2.3.2? That would ensure maximum compatibility with Debian proper (which to most of the world is sarge, *not* sid, so don't answer that you're almost the same as sid). Hoary (like sarge) is built against 2.3.2. Breezy (like current sid) is built against 2.3.5. I don't begrudge your attempt to innovate, but I doubt your users consider a slightly newer libc innovation, particularly when it introduces problems like this. Ironically, the problem in this case stems from sid innovating too fast for Hoary, the latest stable Ubuntu release. Ho hum. I strongly suspect they're more interested in your X.org and GNOME 2.10. Given that, a lot of this divergence seems pretty gratutious to me. Yes, these are both very interesting to users. Which 'divergence' do you mean when you reference that -- X.Org/GNOME 2.10, or glibc? Cheers, Daniel signature.asc Description: Digital signature
X SI in Debian and Ubuntu (was: Re: Is Ubuntu a debian derivative or is it a fork?)
[Please CC me: I'm not subscribed.] On Thu, Jun 09, 2005 at 09:45:42AM -0700, Matt Zimmerman wrote: On Thu, Jun 09, 2005 at 10:36:25AM -0400, David Nusinow wrote: I'm sorry, this turned out to be very long-winded, but since many people are interested in what's going on with X.Org, I may as well explain to a larger audience than debian-x what's in store. Thanks for bringing concrete information to the discussion. Yeah, one which was definitely not in need of any more hot air ... What I've decided to do with X.Org is a compromise. I'm using the Ubuntu packages as a base, but I've spent the last month doing as careful an audit of them as I can, comparing them to the XFree86 packaging, and reverting what changes I don't agree with, keeping the ones that I like, etc. Did you discuss these plans with any Ubuntu developers? How much have you changed relative to the Ubuntu packages? From what I can tell from the changelog, Daniel merged a batch of changes from Debian XFree86 SVN into the Ubuntu packages in 6.8.2-16, but I don't know what portion of your changes this represents. I've been talking to David a lot both via email and IRC, and we've been feeding back to each other via both of these mechanisms. So far the delta has been minimal, and I'm confident we can keep it incredibly small. Furthermore, Branden has had plans to shift the packaging to a different patch system, and we plan to move ahead with that as soon as we have X.Org packages in the archive. We'll be branching off the trunk which is derived from the modified Ubuntu packaging, so while we're using the Ubuntu packages as a base (which were the Debian packages originally anyway) we're going to make some radical changes to the system. This packaging can potentially be used for the X.Org 6.9 release, which will be the last monolithic version to be releaseed during the transition to a modular tree. We may never release 6.9 packages in Debian, but this will provide us with a good foundation for it if we do. This work will be done independantly of Ubuntu (as no one from Ubuntu seems interested in helping) so we'll go it alone. Ubuntu isn't likely to spend time on another monolithic release, given that we're in the process of going modular right now. If your eventual goal is to use the modular tree as well, why wouldn't you do it immediately, given the opportunity to use Ubuntu's work as a base? I'm not bothering with 6.9, personally. I'll continue to maintain the 6.8 tree and make sure that the bits of it that aren't modularised are still usable and great quality, but I'm rapidly hacking bits off. As the upstream X.Org tree gets modularized, we're going to begin to work on packaging that instead. My personal preference is to use the modular tree (which will be entirely equivalent to the 6.9 release otherwise, except called 7.0) but if it's not ready for us, we can stick with 6.9, so as to get the latest drivers to our users. Members of both the XSF, including myself and Josh Triplett (who's already begun this work) and Ubuntu developers (Daniel Stone) will be working on this together. My goal is to have as close a tree for both Ubuntu and Debian as possible, preferrably the same tree, but again we'll have to see what happens. Again, I'd be interested to hear details of what you needed to change relative to the Ubuntu packages in order to achieve a result which you found suitable. Josh and I both started from different bases (me from a set of templates I'd written, largely based off my packages from mid-last year, and Josh from his own set of templates), but we're converging with the aim of having at least the entirety of xlibs in perfect harmony between the two. Right now, the only sticking point of any significance whatsoever is cdbs vs debhelper+dpatch. I plan to use the patch system Branden and I will develop for the monolithic tree in the modular tree, and if the Ubuntu developers decide that this isn't the best option then they can go their own route, unless they can demonstrate that an alternate system is preferrable. We would of course evaluate this decision based on technical merit, but my knee-jerk reaction would be why write yet another patch system? I've seen the patch system, and my comments on debian-x was that it was absolutely insane, and utterly doomed to failure. Nothing's changed. In short, we're getting there, just slowly. The only sticking point is that I think the proposed 6.8.2-1 for Debian is absolutely nonsensical (the source package format just doesn't make any sense to me, none at all, even if it is managed by Subversion, or if it was managed by something like Arch), and that Ubuntu will likely develop at a pace slightly more rapid than Debian's, given that 6.8.2-1 in sid looks to still be a long way off if the plan is still to rewrite the entire source packaging, and Ubuntu's breezy already has large chunks
Accepted xrender 0.9.0-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 9 May 2005 15:09:41 +1000 Source: xrender Binary: libxrender1-dbg libxrender-dev libxrender1 Architecture: source i386 Version: 0.9.0-1 Distribution: unstable Urgency: low Maintainer: Daniel Stone [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: libxrender-dev - X Rendering Extension client library (development files) libxrender1 - X Rendering Extension client library libxrender1-dbg - X Rendering Extension client library (unstripped) Closes: 257187 280092 Changes: xrender (0.9.0-1) unstable; urgency=low . * New upstream version. * Adopting package; set Maintainer to myself. * Set includedir to be /usr/X11R6/include with autoconf, not by moving it around, so the pkgconfig file and the libtool library no longer lie (closes: #257187, #280092). * Make libxrender-dev Depend (not B-D) on render-dev = 0.9, for the new protocol version. Files: df7bd9af7ff95cc752981b9d98c8372d 669 x11 optional xrender_0.9.0-1.dsc 8aadb283d417e0f732678fe08469ce6e 309386 x11 optional xrender_0.9.0.orig.tar.gz 14dbb528a203c8b0d8917c15d47deeae 10792 x11 optional xrender_0.9.0-1.diff.gz d26eb33f17033a3d3dacff0ddcbb1d81 26638 libs optional libxrender1_0.9.0-1_i386.deb bedab447958c90d12809b69e6094301e 335856 libdevel extra libxrender1-dbg_0.9.0-1_i386.deb 41ee1307c37bf2c0ec13163ca7b2997c 29860 libdevel optional libxrender-dev_0.9.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCfwDERkzMgPKxYGwRAg7vAJ4v1wDDJZyyao2lfrN7f+kC1BtA9wCeK0GN K7qa1LHcvtZpH4RSk4mMvng= =ixed -END PGP SIGNATURE- Accepted: libxrender-dev_0.9.0-1_i386.deb to pool/main/x/xrender/libxrender-dev_0.9.0-1_i386.deb libxrender1-dbg_0.9.0-1_i386.deb to pool/main/x/xrender/libxrender1-dbg_0.9.0-1_i386.deb libxrender1_0.9.0-1_i386.deb to pool/main/x/xrender/libxrender1_0.9.0-1_i386.deb xrender_0.9.0-1.diff.gz to pool/main/x/xrender/xrender_0.9.0-1.diff.gz xrender_0.9.0-1.dsc to pool/main/x/xrender/xrender_0.9.0-1.dsc xrender_0.9.0.orig.tar.gz to pool/main/x/xrender/xrender_0.9.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted render 0.9-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 9 May 2005 15:07:11 +1000 Source: render Binary: render-dev Architecture: source all Version: 0.9-1 Distribution: unstable Urgency: low Maintainer: Daniel Stone [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: render-dev - X Rendering Extension header files and documentation Changes: render (0.9-1) unstable; urgency=low . * New upstream version, including new trap requests. * Adopting package; change Maintainer to myself. Files: 145ce1294c5a679ac8d44be883fb88d5 554 libdevel optional render_0.9-1.dsc ecb76414bb9ade2be1d6f6ef17728b06 83205 libdevel optional render_0.9.orig.tar.gz f2f1e65a1a991e23f16d73aa0b2eda3e 3358 libdevel optional render_0.9-1.diff.gz e587eefdbe854fd9082312289146e1b4 25898 libdevel optional render-dev_0.9-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCfv+qRkzMgPKxYGwRAqEUAJwM6H3AoShCNpuQYxbhE4Ilei0KBQCdF1Sv AvUyj7xSlTGx3K9yoMjZjSg= =/eX6 -END PGP SIGNATURE- Accepted: render-dev_0.9-1_all.deb to pool/main/r/render/render-dev_0.9-1_all.deb render_0.9-1.diff.gz to pool/main/r/render/render_0.9-1.diff.gz render_0.9-1.dsc to pool/main/r/render/render_0.9-1.dsc render_0.9.orig.tar.gz to pool/main/r/render/render_0.9.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: my thoughts on the Vancouver Prospectus
On Sun, Mar 20, 2005 at 09:07:52AM +0100, Sven Luther wrote: On Sun, Mar 20, 2005 at 02:57:23AM +0100, Peter 'p2' De Schrijver wrote: * Three bodies (Security, System Administration, Release) are given independent veto power over the inclusion of an architecture. A) Does the entire team have to exercise this veto for it to be effective, or can one member of any team exercise this power effectively? It's expected that each team would exercise that veto as a *team*, by reaching a consensus internally. This is obviously unacceptable. Why would a small number of people be allowed to veto inclusion of other people's work ? And a non-elected, non-properly-delegated, self-apointed group of people at that. Are you suggesting replacing the entire release and ftp-master teams? If so, please suggest who you would like in that role instead (or if we should all vote on it -- because hey, every position in Debian needs to be elected). Are you suggesting that everyone in Debian who has not been elected to their position should be elected so? signature.asc Description: Digital signature
Accepted dbus 0.22-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 17 Aug 2004 00:42:56 +0100 Source: dbus Binary: dbus-glib-1 dbus-1-doc python2.3-dbus dbus-glib-1-dev dbus-1-utils dbus-1 dbus-1-dev Architecture: source i386 all Version: 0.22-1 Distribution: unstable Urgency: high Maintainer: Dbus Maintainance Team [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: dbus-1 - simple interprocess messaging system dbus-1-dev - simple interprocess messaging system (development headers) dbus-1-doc - simple interprocess messaging system (documentation) dbus-1-utils - simple interprocess messaging system (utilities) dbus-glib-1 - simple interprocess messaging system (GLib-based shared library) dbus-glib-1-dev - simple interprocess messaging system (GLib interface) python2.3-dbus - simple interprocess messaging system (Python interface) Changes: dbus (0.22-1) unstable; urgency=high . * New upstream release. + Urgency high so it slips into sarge before the freeze. Files: d61d86574a186db4938b2b62d469 891 devel optional dbus_0.22-1.dsc 6b1c2476ea8b82dd9fb7f29ef857cb9f 1248780 devel optional dbus_0.22.orig.tar.gz 24f45a812630cc82a8031307514f316b 12840 devel optional dbus_0.22-1.diff.gz 572665f1d002f6f6f9911ceb44b37fe4 815756 doc optional dbus-1-doc_0.22-1_all.deb 44ca17fc6127723b93f8168124abda58 306226 devel optional dbus-1_0.22-1_i386.deb 245de00aacf5217579ef41e5e9889761 100562 libs optional dbus-glib-1_0.22-1_i386.deb 4ec35827612f880e8e40a27a4a69a1ac 99298 utils optional dbus-1-utils_0.22-1_i386.deb 2aa29c1012c942d801253b2228110258 212102 libdevel optional dbus-1-dev_0.22-1_i386.deb ae40a69cc9506c07afebed44e28ff794 101922 libdevel optional dbus-glib-1-dev_0.22-1_i386.deb ff8a2680e3f4d228c502a05e0940e034 129794 python optional python2.3-dbus_0.22-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBIVRRcPClnTztfv0RAgq0AJ42REiH9Mcv5qFr/VJSI4GXQf463ACfT2DV MTOWWjSapxnyA1W97nR5MkY= =tmeY -END PGP SIGNATURE- Accepted: dbus-1-dev_0.22-1_i386.deb to pool/main/d/dbus/dbus-1-dev_0.22-1_i386.deb dbus-1-doc_0.22-1_all.deb to pool/main/d/dbus/dbus-1-doc_0.22-1_all.deb dbus-1-utils_0.22-1_i386.deb to pool/main/d/dbus/dbus-1-utils_0.22-1_i386.deb dbus-1_0.22-1_i386.deb to pool/main/d/dbus/dbus-1_0.22-1_i386.deb dbus-glib-1-dev_0.22-1_i386.deb to pool/main/d/dbus/dbus-glib-1-dev_0.22-1_i386.deb dbus-glib-1_0.22-1_i386.deb to pool/main/d/dbus/dbus-glib-1_0.22-1_i386.deb dbus_0.22-1.diff.gz to pool/main/d/dbus/dbus_0.22-1.diff.gz dbus_0.22-1.dsc to pool/main/d/dbus/dbus_0.22-1.dsc dbus_0.22.orig.tar.gz to pool/main/d/dbus/dbus_0.22.orig.tar.gz python2.3-dbus_0.22-1_i386.deb to pool/main/d/dbus/python2.3-dbus_0.22-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted hal 0.2.97-0.1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 16 Aug 2004 17:34:37 -0700 Source: hal Binary: libhal-dev hal-doc libhal0 hal Architecture: source i386 all Version: 0.2.97-0.1 Distribution: unstable Urgency: low Maintainer: Martin Waitz [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: hal- Hardware Abstraction Layer hal-doc- Hardware Abstraction Layer libhal-dev - Hardware Abstraction Layer - development files libhal0- Hardware Abstraction Layer - shared library Changes: hal (0.2.97-0.1) unstable; urgency=low . * NMU for New upstream release. + sarge freezes tomorrow, this should beat the deadline. + Works with D-BUS 0.22 and above. * Tighten D-BUS Build-Deps/Depends to = 0.22. Files: 39def719e1309b54b4c110221fbc4a70 736 admin optional hal_0.2.97-0.1.dsc d156860f508ea384282a367774fe85bb 1238713 admin optional hal_0.2.97.orig.tar.gz face51d9d95223e238e18a5b328f63a4 11692 admin optional hal_0.2.97-0.1.diff.gz 68ba4e501f2a7f253ef9a10f253982a3 645456 doc optional hal-doc_0.2.97-0.1_all.deb b1622c208ef852b65e65198e18bbfebc 202614 admin optional hal_0.2.97-0.1_i386.deb e2e4f7f4e2f5cc858f6f69a4aa5331a0 55216 libs optional libhal0_0.2.97-0.1_i386.deb 83122f5888d83bf5eac682c554393eda 57406 libdevel optional libhal-dev_0.2.97-0.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD4DBQFBIcFScPClnTztfv0RAnZ5AJ0Xmc+DLBclSD3+6UPJvekofzldpACXSIR4 dVeUDnzyIyztgPavQIz8IA== =Dgsf -END PGP SIGNATURE- Accepted: hal-doc_0.2.97-0.1_all.deb to pool/main/h/hal/hal-doc_0.2.97-0.1_all.deb hal_0.2.97-0.1.diff.gz to pool/main/h/hal/hal_0.2.97-0.1.diff.gz hal_0.2.97-0.1.dsc to pool/main/h/hal/hal_0.2.97-0.1.dsc hal_0.2.97-0.1_i386.deb to pool/main/h/hal/hal_0.2.97-0.1_i386.deb hal_0.2.97.orig.tar.gz to pool/main/h/hal/hal_0.2.97.orig.tar.gz libhal-dev_0.2.97-0.1_i386.deb to pool/main/h/hal/libhal-dev_0.2.97-0.1_i386.deb libhal0_0.2.97-0.1_i386.deb to pool/main/h/hal/libhal0_0.2.97-0.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dbtcp 0.1.17-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 17 Jun 2004 23:06:17 +1000 Source: dbtcp Binary: libdbd-dbftp-perl dbtcp php4-dbtcp Architecture: source i386 Version: 0.1.17-4 Distribution: unstable Urgency: low Maintainer: Daniel Stone [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: dbtcp - Miscellaneous command-line DBTCP utils libdbd-dbftp-perl - Perl bindings for DBTCP php4-dbtcp - PHP bindings for DBTCP Closes: 253805 Changes: dbtcp (0.1.17-4) unstable; urgency=low . * Makefile: + Apply patch to link with -fPIC, which fixes a FTBFS outside the cushy little i386 world. (closes: #253805) Files: 8ae29ab5117627284cf828247be0d6fa 630 net optional dbtcp_0.1.17-4.dsc d39f3be276a2fb50c60fad578d3d51ee 3621 net optional dbtcp_0.1.17-4.diff.gz 220c8f56214c4fe04203216df2b5eff2 14550 net optional dbtcp_0.1.17-4_i386.deb 0d5e99bb9b6f533ee9e80dd23cc7d6cb 25162 perl optional libdbd-dbftp-perl_0.1.17-4_i386.deb 7da3bcaf8309d504f27a5effe15d3ffd 12860 interpreters optional php4-dbtcp_0.1.17-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA0ZgZcPClnTztfv0RAoDEAKCC69mzjk2EL3XQngQXDh9RcClisACfbJXV nu+Q/yAe895Bs+Bx16lMAVw= =2Xlm -END PGP SIGNATURE- Accepted: dbtcp_0.1.17-4.diff.gz to pool/main/d/dbtcp/dbtcp_0.1.17-4.diff.gz dbtcp_0.1.17-4.dsc to pool/main/d/dbtcp/dbtcp_0.1.17-4.dsc dbtcp_0.1.17-4_i386.deb to pool/main/d/dbtcp/dbtcp_0.1.17-4_i386.deb libdbd-dbftp-perl_0.1.17-4_i386.deb to pool/main/d/dbtcp/libdbd-dbftp-perl_0.1.17-4_i386.deb php4-dbtcp_0.1.17-4_i386.deb to pool/main/d/dbtcp/php4-dbtcp_0.1.17-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dbus 0.21-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 21 Mar 2004 02:42:53 +1100 Source: dbus Binary: dbus-glib-1 dbus-1-doc python2.3-dbus dbus-glib-1-dev dbus-1-utils dbus-1 dbus-1-dev Architecture: source i386 all Version: 0.21-1 Distribution: unstable Urgency: low Maintainer: Daniel Stone [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: dbus-1 - simple interprocess messaging system dbus-1-dev - simple interprocess messaging system (development headers) dbus-1-doc - simple interprocess messaging system (documentation) dbus-1-utils - simple interprocess messaging system (utilities) dbus-glib-1 - simple interprocess messaging system (GLib-based shared library) dbus-glib-1-dev - simple interprocess messaging system (GLib interface) python2.3-dbus - simple interprocess messaging system (Python interface) Closes: 229274 Changes: dbus (0.21-1) unstable; urgency=low . * New upstream version. + Fixes varargs crap - cleaner patch from David Zeuthen applied. (closes: #229274) * Added provides/replaces/conflicts on dbus-1-utils 0.20-4, per -4's moving of manpages. Files: 2c5e36f5e09a4974245211abe8db2a04 824 devel optional dbus_0.21-1.dsc 311229d60154334ee3f908badc56747d 1152107 devel optional dbus_0.21.orig.tar.gz 84e4ad5b7df1ad13a27bc206117de2d5 10594 devel optional dbus_0.21-1.diff.gz d0299b9e5e12ca1ab7982c51ea6cb94a 793998 doc optional dbus-1-doc_0.21-1_all.deb 6526423dfebb5ef1704026de6814829d 289290 devel optional dbus-1_0.21-1_i386.deb 95a20aac0e2ba29e731da59ba8c4ddee 86278 libs optional dbus-glib-1_0.21-1_i386.deb 56250e12a9a0f17139f52cbcd59f547e 86406 utils optional dbus-1-utils_0.21-1_i386.deb 0efa30463e9cefbd84129e6701dace86 195754 libdevel optional dbus-1-dev_0.21-1_i386.deb b06fcbefdb27cf26a947e19af293bdeb 87432 libdevel optional dbus-glib-1-dev_0.21-1_i386.deb 03f6405a0e795a04f29fecb11e76c550 110472 python optional python2.3-dbus_0.21-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAXHbjcPClnTztfv0RAuVAAJ4g7RIJY5/LLMNprpwbjxN9oFfefwCcCodr mlZY0cOFTBV391YpgW8mhNc= =NzUe -END PGP SIGNATURE- Accepted: dbus-1-dev_0.21-1_i386.deb to pool/main/d/dbus/dbus-1-dev_0.21-1_i386.deb dbus-1-doc_0.21-1_all.deb to pool/main/d/dbus/dbus-1-doc_0.21-1_all.deb dbus-1-utils_0.21-1_i386.deb to pool/main/d/dbus/dbus-1-utils_0.21-1_i386.deb dbus-1_0.21-1_i386.deb to pool/main/d/dbus/dbus-1_0.21-1_i386.deb dbus-glib-1-dev_0.21-1_i386.deb to pool/main/d/dbus/dbus-glib-1-dev_0.21-1_i386.deb dbus-glib-1_0.21-1_i386.deb to pool/main/d/dbus/dbus-glib-1_0.21-1_i386.deb dbus_0.21-1.diff.gz to pool/main/d/dbus/dbus_0.21-1.diff.gz dbus_0.21-1.dsc to pool/main/d/dbus/dbus_0.21-1.dsc dbus_0.21.orig.tar.gz to pool/main/d/dbus/dbus_0.21.orig.tar.gz python2.3-dbus_0.21-1_i386.deb to pool/main/d/dbus/python2.3-dbus_0.21-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dbus 0.20-2 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 21 Jan 2004 11:07:37 +1100 Source: dbus Binary: dbus-1-utils dbus-qt-1-dev dbus-1-doc dbus-glib-1 dbus-glib-1-dev dbus-qt-1 python2.3-dbus dbus-1 dbus-1-dev Architecture: source i386 all Version: 0.20-2 Distribution: unstable Urgency: low Maintainer: Daniel Stone [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: dbus-1 - simple interprocess messaging system dbus-1-dev - simple interprocess messaging system (development headers) dbus-1-doc - simple interprocess messaging system (documentation) dbus-1-utils - simple interprocess messaging system (utilities) dbus-glib-1 - simple interprocess messaging system (GLib-based shared library) dbus-glib-1-dev - simple interprocess messaging system (GLib interface) dbus-qt-1 - simple interprocess messaging system (Qt-based shared library) dbus-qt-1-dev - simple interprocess messaging system (Qt interface) python2.3-dbus - simple interprocess messaging system (Python interface) Changes: dbus (0.20-2) unstable; urgency=low . * The gotta keep the ftpmaster cab^Whappy release. + Hey, I need the overrides ... * debian/python2.3-dbus.install: + Stop installing .a and .la files (thanks Daniel Silverstone). * debian/dbus-qt-1-dev.install: + Install the .la file ... yep, Daniel Silverstone * debian/patches/dbus-monitor.patch: + Patch from Daniel Silverstone to add suport for filters to dbus-monitor: only watch for certain events. * debian/rules: + Add --enable-verbose-mode to make debugging far more easier. - Daniel Silverstone strikes again! Files: 87a13b87b7d89361f5ef914fc3abc3f6 787164 doc optional dbus-1-doc_0.20-2_all.deb 04e8eb6fc61204b90b09c41a0d1938b6 288418 devel optional dbus-1_0.20-2_i386.deb 9c253a2e86d70c0e98f8adcd073bc441 83648 libs optional dbus-glib-1_0.20-2_i386.deb 0954c9958409b7041feebd61cbc9a53b 79198 utils optional dbus-1-utils_0.20-2_i386.deb f73fce5a98e4957f7d38f24ae5652c19 193890 libdevel optional dbus-1-dev_0.20-2_i386.deb 53f3081746935074bc6623bfd4fdc725 84860 libdevel optional dbus-glib-1-dev_0.20-2_i386.deb 2ada5950463abc65edbcec180b2ff1d3 68268 libs optional dbus-qt-1_0.20-2_i386.deb 1528c0ae9b0abd697c27b7b233eb45b0 67678 libdevel optional dbus-qt-1-dev_0.20-2_i386.deb a1dad573264328ac0f255ebb7ee46c2f 107804 python optional python2.3-dbus_0.20-2_i386.deb fcca84924bdfd22ad5a6736be830f499 811 devel optional dbus_0.20-2.dsc 52a474fdb4e2851241ce3fb685a72130 9817 devel optional dbus_0.20-2.diff.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFADdWEcPClnTztfv0RAjRyAJ9uzXp7ZaD9wipU883YsiOR3CIdvACfYBWZ KIptP550WCyzcWxptVRl7eE= =PexT -END PGP SIGNATURE- Accepted: dbus-1-dev_0.20-2_i386.deb to pool/main/d/dbus/dbus-1-dev_0.20-2_i386.deb dbus-1-doc_0.20-2_all.deb to pool/main/d/dbus/dbus-1-doc_0.20-2_all.deb dbus-1-utils_0.20-2_i386.deb to pool/main/d/dbus/dbus-1-utils_0.20-2_i386.deb dbus-1_0.20-2_i386.deb to pool/main/d/dbus/dbus-1_0.20-2_i386.deb dbus-glib-1-dev_0.20-2_i386.deb to pool/main/d/dbus/dbus-glib-1-dev_0.20-2_i386.deb dbus-glib-1_0.20-2_i386.deb to pool/main/d/dbus/dbus-glib-1_0.20-2_i386.deb dbus-qt-1-dev_0.20-2_i386.deb to pool/main/d/dbus/dbus-qt-1-dev_0.20-2_i386.deb dbus-qt-1_0.20-2_i386.deb to pool/main/d/dbus/dbus-qt-1_0.20-2_i386.deb dbus_0.20-2.diff.gz to pool/main/d/dbus/dbus_0.20-2.diff.gz dbus_0.20-2.dsc to pool/main/d/dbus/dbus_0.20-2.dsc python2.3-dbus_0.20-2_i386.deb to pool/main/d/dbus/python2.3-dbus_0.20-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libapache2-mod-xslt 0.9.9+rc1-7 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 29 Dec 2003 14:40:19 +1100 Source: libapache2-mod-xslt Binary: libapache2-mod-xslt Architecture: source i386 Version: 0.9.9+rc1-7 Distribution: unstable Urgency: high Maintainer: Daniel Stone [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: libapache2-mod-xslt - An apache2 module that does on-the-fly XSLT processing Changes: libapache2-mod-xslt (0.9.9+rc1-7) unstable; urgency=HIGH . * High urgency due to DoS bug. * This version merges the 6.0 debug changes, but I suspect it's apache2 at fault anyway. * src/xsltools.c: + Check if we have a User-Agent header before just blindly dereferencing it - fixes a DoS if you made a request sans User-Agent. Thanks to Aleksi Suhonen for discovery and the patch. Files: 7c94c52178cf9318b54a9f54bd3b89c9 17704 web optional libapache2-mod-xslt_0.9.9+rc1-7_i386.deb 687efa6912382d6496df1c9882d7ca8c 698 web optional libapache2-mod-xslt_0.9.9+rc1-7.dsc e13fc5e535cd9387aa71969287eb21ba 22165 web optional libapache2-mod-xslt_0.9.9+rc1-7.diff.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/77Q/cPClnTztfv0RAiZhAJ48tZMehD0yNFmz6nJwC5qfWoBrtQCfaYyk NZimQokW0GxzQpv/cWuqrjI= =BIBG -END PGP SIGNATURE- Accepted: libapache2-mod-xslt_0.9.9+rc1-7.diff.gz to pool/main/liba/libapache2-mod-xslt/libapache2-mod-xslt_0.9.9+rc1-7.diff.gz libapache2-mod-xslt_0.9.9+rc1-7.dsc to pool/main/liba/libapache2-mod-xslt/libapache2-mod-xslt_0.9.9+rc1-7.dsc libapache2-mod-xslt_0.9.9+rc1-7_i386.deb to pool/main/liba/libapache2-mod-xslt/libapache2-mod-xslt_0.9.9+rc1-7_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted apache2 2.0.48-4 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 16 Nov 2003 18:10:08 +1100 Source: apache2 Binary: apache2-prefork-dev apache2-mpm-prefork apache2-doc libapr0-dev apache2-mpm-threadpool apache2-mpm-worker libapr0 apache2-threaded-dev apache2-common apache2-mpm-perchild Architecture: source all i386 Version: 2.0.48-4 Distribution: unstable Urgency: medium Maintainer: Daniel Stone [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: apache2-common - Next generation, scalable, extendable web server apache2-doc - Documentation for apache2 apache2-mpm-perchild - Experimental High speed perchild threaded model for Apache2 apache2-mpm-prefork - Traditional model for Apache2 apache2-mpm-threadpool - Experimental High speed thread pool model for Apache2 apache2-mpm-worker - High speed threaded model for Apache2 apache2-prefork-dev - Development headers for apache2 apache2-threaded-dev - Development headers for apache2 libapr0- The Apache Portable Runtime libapr0-dev - Development headers for libapr Changes: apache2 (2.0.48-4) unstable; urgency=medium . * (Daniel Stone) - Change apache2-threaded-dev's Conflicts from apache2-perfork-dev to apache2-prefork-dev. Learn how to type, dude (thanks to Grzegorz Prokopski for spotting this one). Files: 3de7b7a41652df95e4a49fcf118166a6 2677008 doc optional apache2-doc_2.0.48-4_all.deb f0fd262c352ef44087fac2f93a1e2d41 160168 devel optional apache2-prefork-dev_2.0.48-4_all.deb bfc3bcd85059f44bdb3cf63f32208037 155686 devel optional apache2-threaded-dev_2.0.48-4_all.deb 596426e6dd733776c02e2c2b367a6776 808280 net optional apache2-common_2.0.48-4_i386.deb c42c02667b0f218b75852f575c15e4a2 206804 net optional apache2-mpm-worker_2.0.48-4_i386.deb 6b646920c4c600018d10ab28c30f1214 206340 net optional apache2-mpm-threadpool_2.0.48-4_i386.deb e89eb95ff9d133013b8bbd91ceb38734 207392 net optional apache2-mpm-perchild_2.0.48-4_i386.deb 5a635f6552f99646fd58e6135572229f 203062 net optional apache2-mpm-prefork_2.0.48-4_i386.deb 30aea86a9cf7e908e8152850a551a843 118300 net optional libapr0_2.0.48-4_i386.deb 22758793c2b5f826060a208dfa65c418 255142 libdevel optional libapr0-dev_2.0.48-4_i386.deb ff998476b1d0edec202edd13ac3d3646 1047 net optional apache2_2.0.48-4.dsc 3fe25ee8f33ccbd9c78f2e068cbe4f9a 73013 net optional apache2_2.0.48-4.diff.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/tyuDcPClnTztfv0RAo2rAKCOSsKZLhXeXd6td4QeMq0cYmKCcQCeOqQh LIWdPtkgVb/Khkkf7Lbb4as= =m0NH -END PGP SIGNATURE- Accepted: apache2-common_2.0.48-4_i386.deb to pool/main/a/apache2/apache2-common_2.0.48-4_i386.deb apache2-doc_2.0.48-4_all.deb to pool/main/a/apache2/apache2-doc_2.0.48-4_all.deb apache2-mpm-perchild_2.0.48-4_i386.deb to pool/main/a/apache2/apache2-mpm-perchild_2.0.48-4_i386.deb apache2-mpm-prefork_2.0.48-4_i386.deb to pool/main/a/apache2/apache2-mpm-prefork_2.0.48-4_i386.deb apache2-mpm-threadpool_2.0.48-4_i386.deb to pool/main/a/apache2/apache2-mpm-threadpool_2.0.48-4_i386.deb apache2-mpm-worker_2.0.48-4_i386.deb to pool/main/a/apache2/apache2-mpm-worker_2.0.48-4_i386.deb apache2-prefork-dev_2.0.48-4_all.deb to pool/main/a/apache2/apache2-prefork-dev_2.0.48-4_all.deb apache2-threaded-dev_2.0.48-4_all.deb to pool/main/a/apache2/apache2-threaded-dev_2.0.48-4_all.deb apache2_2.0.48-4.diff.gz to pool/main/a/apache2/apache2_2.0.48-4.diff.gz apache2_2.0.48-4.dsc to pool/main/a/apache2/apache2_2.0.48-4.dsc libapr0-dev_2.0.48-4_i386.deb to pool/main/a/apache2/libapr0-dev_2.0.48-4_i386.deb libapr0_2.0.48-4_i386.deb to pool/main/a/apache2/libapr0_2.0.48-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#219163: ITP: synaptic-touchpad -- Synaptics TouchPad driver for XFree86
On Thu, Nov 13, 2003 at 01:58:44PM -0500, Branden Robinson wrote: On Wed, Nov 12, 2003 at 11:32:14AM +1100, Daniel Stone wrote: On Tue, Nov 11, 2003 at 06:58:15PM -0500, Branden Robinson wrote: I think it would be really dumb for a driver author to re-use an existing name for a different purpose. Well, Synaptics could branch out and start making graphics cards, for example. I think it would probably be a bad design to have input drivers and display drivers stuffed into the same object. That doesn't mean it won't happen, but it should be rare enough that an ad-hoc approach will work. Right, but I'm just saying that you'd then have to have xfree86-driver-synaptics-input and xfree86-driver-synaptics-graphics, or whatever ... a more realistic example is Intel, who seem to be enjoying their current i8??G hegemony. Ad-hoc should still, as you say, work. -- Daniel Stone[EMAIL PROTECTED] Debian X Strike Force:http://people.debian.org/~branden/xsf/ pgph2KDhZ9jbK.pgp Description: PGP signature
Re: using freedesktop.org libs
On Tue, Nov 11, 2003 at 12:11:22PM +, Andrew Suffield wrote: On Tue, Nov 11, 2003 at 01:14:30AM +0100, Michel D?nzer wrote: I found this idea very interesting. I think that the debian project should take more advantage of the freedesktop.org libs. Glancing briefly at the packages in sid, we've been using the ones they have released for a while. Unreleased libraries do not belong in unstable. It's not about released vs. unreleased but XFree86 vs. freedesktop.org. Presumably you think freedesktop.org will do a better job of maintaining them. So why are you so eager to use things which they say aren't ready for release, if you trust their skills so much? Personally, I've come to believe that Jim Gettys has a vague idea of what he's doing. Also, note I specified no timeframe. I would've ITPed it already if I wanted it nownownow, only I don't. I want to wait until fd.o deems it ready. Getting tired of this, Daniel -- Daniel Stone[EMAIL PROTECTED] Debian X Strike Force:http://people.debian.org/~branden/xsf/ pgptpPMZhrwjn.pgp Description: PGP signature
Re: Bug#219163: ITP: synaptic-touchpad -- Synaptics TouchPad driver for XFree86
On Tue, Nov 11, 2003 at 06:58:15PM -0500, Branden Robinson wrote: On Mon, Nov 10, 2003 at 03:59:48PM +1100, Daniel Stone wrote: On Sun, Nov 09, 2003 at 11:56:04PM -0500, Branden Robinson wrote: I thought about the latter as well. It's not too long-winded if we expect having input and video modules with identical names. I can't particularly see this at the moment, but I'm sure something will rise up and prove us wrong. Yeah, well, if something turns out to be that perverse we'll just ad-hoc it. I think it would be really dumb for a driver author to re-use an existing name for a different purpose. Well, Synaptics could branch out and start making graphics cards, for example. -- Daniel Stone[EMAIL PROTECTED] Debian X Strike Force:http://people.debian.org/~branden/xsf/ pgpDmVSBJAQcZ.pgp Description: PGP signature
Bug#220345: ITP: xserver-freedesktop -- freedesktop.org X server (nee KDrive)
Package: wnpp Version: unavailable; reported 2003-11-12 Severity: wishlist * Package name: xserver-freedesktop Version : (unreleased) Upstream Author : Keith Packard [EMAIL PROTECTED] and other freedesktop.org hackers * URL : http://xserver.freedesktop.org * License : MIT/X11 Description : freedesktop.org X server (nee KDrive) The freedesktop.org X server is a faster, more featureful alternative to the XFree86 X server. It has features like the XDamage and aXe extensions, and a full composite model for aRGB windows. However, it does not yet have 3D support, and currently relies on VESA/framebuffer support. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux aedificator 2.4.22-pre6 #1 Wed Jul 16 15:23:20 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C
Bug#220347: ITP: xlibs-freedesktop -- X libraries (client-side) from freedesktop
Package: wnpp Version: unavailable; reported 2003-11-12 Severity: wishlist * Package name: xlibs-freedesktop Version : (unreleased) Upstream Author : Jim Gettys [EMAIL PROTECTED], and other freedesktop.org hackers * URL : http://xlibs.freedesktop.org * License : MIT/X11 Description : X libraries (client-side) from freedesktop The freedesktop.org X client-side libraries (originally from XFree86), are a collection of various essential client-side libraries for using X11; these are a replacement for the XFree86 libraries that currently reside under the 'xlibs' package. This will not be able to be uploaded until the xlibs build is separated from that of the rest of XFree86; maintainence will fall under the auspices of the X Strike Force (as will that of xserver-freedesktop). -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux aedificator 2.4.22-pre6 #1 Wed Jul 16 15:23:20 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C
Re: using freedesktop.org libs
On Tue, Nov 11, 2003 at 01:14:30AM +0100, Michel D?nzer wrote: On Tue, 2003-11-11 at 00:39, Andrew Suffield wrote: On Mon, Nov 10, 2003 at 09:44:20PM +, Anthraxz __ wrote: The freebsd developpers are making some changes to the XFree86 ports to reduce the pain associated with upgrading and maintaining XFree86. http://www.freebsdforums.org/forums/showthread.php?threadid=16052 Debian doesn't share freebsd's bug of building everything on the target system, so this doesn't really apply. That's not the only point, there's also 'I also expect the freedesktop.org libraries to stay better maintained and release more frequently than XFree86's', e.g. I, personally, am all for using the fd.o libs, instead of xfree86. It might be worth noting that fd.o/xlibs upstream is Jim Gettys. He has a clue or twelve. The main pain is in breaking it out, confwise, and then packaging-wise. OTOH, it could make the xlibs transition that much easier, if we're not doing it in the framework of a massive, massive package anyway. I found this idea very interesting. I think that the debian project should take more advantage of the freedesktop.org libs. Glancing briefly at the packages in sid, we've been using the ones they have released for a while. Unreleased libraries do not belong in unstable. It's not about released vs. unreleased but XFree86 vs. freedesktop.org. And about how responsive/cluey the upstreams are, specifically. Daniel, dreaming of source package Xu-ification (no really; it would be a good thing). -- Daniel Stone [EMAIL PROTECTED] The programs are documented fully by _The Rise and Fall of a Fooish Bar_, available by the Info system. -- debian/manpage.sgml.ex, dh_make template pgp4wtEMkbfW6.pgp Description: PGP signature
Re: Bug#219163: ITP: synaptic-touchpad -- Synaptics TouchPad driver for XFree86
On Sun, Nov 09, 2003 at 11:56:04PM -0500, Branden Robinson wrote: On Sun, Nov 09, 2003 at 10:03:14AM +1100, Daniel Stone wrote: There is one unreachable person; IIRC, he was a reasonably major contributor. Double bummer. Aye; sort of condemns it to external DDKdom. I was thinking about xfree86-driver-synaptics, or xfree86-driver-input-synaptics, but the last one is too unnecessarily longwinded. (I was going to package this as an XSF project, post-exams). I thought about the latter as well. It's not too long-winded if we expect having input and video modules with identical names. I can't particularly see this at the moment, but I'm sure something will rise up and prove us wrong. Is the XFree86 driver namespace subdivided in practice (i.e., in a name-resolution sense), or merely cosmetically via directory layout? I don't believe it's subdivided in a name-resolution sense, but I could be wrong. -- Daniel Stone [EMAIL PROTECTED] The programs are documented fully by _The Rise and Fall of a Fooish Bar_, available by the Info system. -- debian/manpage.sgml.ex, dh_make template pgpE01UhCz8i7.pgp Description: PGP signature
Re: Bug#219163: ITP: synaptic-touchpad -- Synaptics TouchPad driver for XFree86
On Sat, Nov 08, 2003 at 02:52:09PM -0500, Branden Robinson wrote: On Thu, Nov 06, 2003 at 08:04:21PM +0100, Mattia Dongili wrote: On Thu, Nov 06, 2003 at 01:23:09PM -0500, Branden Robinson wrote: Er, actually, last I heard, the author was still looking into relicensing it in a manner consistent with XFree86's requirements. (They don't accept GPLed code.) that's what he told me too. He also said he is still unable to contact every single contributor to confirm the license change. Bummer. There is one unreachable person; IIRC, he was a reasonably major contributor. hummm... I know... It took me a while to choose it :) Any suggestion? synaptic-touchpad-driver? synaptic-driver? What's the module name? synaptic? synaptics. If so, I recommend: xfree86-driver-synaptic Please be sure to mention in the package description that this is a driver module *for* the XFree86 X server, not a driver module *from* the XFree86 Project, Inc. I was thinking about xfree86-driver-synaptics, or xfree86-driver-input-synaptics, but the last one is too unnecessarily longwinded. (I was going to package this as an XSF project, post-exams). I'll package it. I'm a bit unsure about XFree configuration after installation. I'll simply provide a sample configuration and big fat README.Debian The synaptics README has sample configurations in it. -- Daniel Stone [EMAIL PROTECTED] The programs are documented fully by _The Rise and Fall of a Fooish Bar_, available by the Info system. -- debian/manpage.sgml.ex, dh_make template pgp74J9T3Qxu7.pgp Description: PGP signature
Accepted libapache2-mod-xslt 0.9.9+rc1-6 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 24 Oct 2003 12:32:43 +1000 Source: libapache2-mod-xslt Binary: libapache2-mod-xslt Architecture: source i386 Version: 0.9.9+rc1-6 Distribution: unstable Urgency: low Maintainer: Daniel Stone [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: libapache2-mod-xslt - An apache2 module that does on-the-fly XSLT processing Closes: 214572 Changes: libapache2-mod-xslt (0.9.9+rc1-6) unstable; urgency=low . * debian/control: + Bump debhelper build-dep to 4.0.4 to keep the woody people happy. (closes: #214572) Files: ac55fbc766b907eae566a2c47c18f1e3 675 web optional libapache2-mod-xslt_0.9.9+rc1-6.dsc e1b1e4b5975aa797aa022899442007d0 21554 web optional libapache2-mod-xslt_0.9.9+rc1-6.diff.gz 1fe078917527983bf481f867eac3d40d 17270 web optional libapache2-mod-xslt_0.9.9+rc1-6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/nZ7ecPClnTztfv0RApXuAJ9TIaQVxNJUSUzK1LFQLuYLeF6ongCfbZPX gmHilEYuGDXy0GlUTBcN2vA= =urEy -END PGP SIGNATURE- Accepted: libapache2-mod-xslt_0.9.9+rc1-6.diff.gz to pool/main/liba/libapache2-mod-xslt/libapache2-mod-xslt_0.9.9+rc1-6.diff.gz libapache2-mod-xslt_0.9.9+rc1-6.dsc to pool/main/liba/libapache2-mod-xslt/libapache2-mod-xslt_0.9.9+rc1-6.dsc libapache2-mod-xslt_0.9.9+rc1-6_i386.deb to pool/main/liba/libapache2-mod-xslt/libapache2-mod-xslt_0.9.9+rc1-6_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dbtcp 0.1.17-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 28 Oct 2003 09:32:56 +1100 Source: dbtcp Binary: libdbd-dbftp-perl dbtcp php4-dbtcp Architecture: source i386 Version: 0.1.17-3 Distribution: unstable Urgency: low Maintainer: Daniel Stone [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: dbtcp - Miscellaneous command-line DBTCP utils libdbd-dbftp-perl - Perl bindings for DBTCP php4-dbtcp - PHP bindings for DBTCP Changes: dbtcp (0.1.17-3) unstable; urgency=low . * debian/control: + Fix override disparities. - php4-dbtcp - Section: interpreters, - libdbd-dbftp-perl - Section: perl Files: de35dff2aa3627943e2793b02817f83b 630 net optional dbtcp_0.1.17-3.dsc 3abaf0205fe8bef27f0b888c18c95b41 3430 net optional dbtcp_0.1.17-3.diff.gz cf75b09d6128302ef2d6bead5c93f893 13880 net optional dbtcp_0.1.17-3_i386.deb 4d26ca9823a8f033bd01842d6b40f748 26622 perl optional libdbd-dbftp-perl_0.1.17-3_i386.deb 1ffc82bed7803d893c734cab13d8009e 11772 interpreters optional php4-dbtcp_0.1.17-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/nZ3FcPClnTztfv0RApMIAJ9ceX4fb9ZA4w8nR206upyAk5sQtACeI/R0 5q3wqreTWZbd0VqY1IHWx/k= =5k16 -END PGP SIGNATURE- Accepted: dbtcp_0.1.17-3.diff.gz to pool/main/d/dbtcp/dbtcp_0.1.17-3.diff.gz dbtcp_0.1.17-3.dsc to pool/main/d/dbtcp/dbtcp_0.1.17-3.dsc dbtcp_0.1.17-3_i386.deb to pool/main/d/dbtcp/dbtcp_0.1.17-3_i386.deb libdbd-dbftp-perl_0.1.17-3_i386.deb to pool/main/d/dbtcp/libdbd-dbftp-perl_0.1.17-3_i386.deb php4-dbtcp_0.1.17-3_i386.deb to pool/main/d/dbtcp/php4-dbtcp_0.1.17-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dbtcp 0.1.17-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 24 Oct 2003 11:56:52 +1000 Source: dbtcp Binary: libdbd-dbftp-perl dbtcp php4-dbtcp Architecture: source i386 Version: 0.1.17-2 Distribution: unstable Urgency: low Maintainer: Daniel Stone [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: dbtcp - Miscellaneous command-line DBTCP utils libdbd-dbftp-perl - Perl bindings for DBTCP php4-dbtcp - PHP bindings for DBTCP Changes: dbtcp (0.1.17-2) unstable; urgency=low . * debian/control: + Change my Maintainer address to [EMAIL PROTECTED] + Bump Standards-Version to 3.6.1. Files: 2060db1b5df53ec2f10232f3281c80a2 630 net optional dbtcp_0.1.17-2.dsc 4adab2c7ca55c397a465c70be168a3b1 3351 net optional dbtcp_0.1.17-2.diff.gz 8b018d084857d2b4e6f8230821fb97d9 13782 net optional dbtcp_0.1.17-2_i386.deb c26b51d6c0d326a104144b1454ed57f3 26516 net optional libdbd-dbftp-perl_0.1.17-2_i386.deb 99463f745fe9e9cec1aa53124997cff0 11676 net optional php4-dbtcp_0.1.17-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/mOUJcPClnTztfv0RApNhAJkBYVYn/Gd95THKRehCdlh9ZOAtlgCfWlMm PDM2V6aR85TYjo5FKLb1gfY= =co/O -END PGP SIGNATURE- Accepted: dbtcp_0.1.17-2.diff.gz to pool/main/d/dbtcp/dbtcp_0.1.17-2.diff.gz dbtcp_0.1.17-2.dsc to pool/main/d/dbtcp/dbtcp_0.1.17-2.dsc dbtcp_0.1.17-2_i386.deb to pool/main/d/dbtcp/dbtcp_0.1.17-2_i386.deb libdbd-dbftp-perl_0.1.17-2_i386.deb to pool/main/d/dbtcp/libdbd-dbftp-perl_0.1.17-2_i386.deb php4-dbtcp_0.1.17-2_i386.deb to pool/main/d/dbtcp/php4-dbtcp_0.1.17-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libapache2-mod-xslt 0.9.9+rc1-5 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Oct 2003 13:12:24 +1000 Source: libapache2-mod-xslt Binary: libapache2-mod-xslt Architecture: source i386 Version: 0.9.9+rc1-5 Distribution: unstable Urgency: low Maintainer: Daniel Stone [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: libapache2-mod-xslt - An apache2 module that does on-the-fly XSLT processing Changes: libapache2-mod-xslt (0.9.9+rc1-5) unstable; urgency=low . * debian/control: + Changing maintainer address to my Debian address. + Change section from net to web, eliminating override disparity. Files: 5f40911dbdae00f2b4da88c812747639 675 web optional libapache2-mod-xslt_0.9.9+rc1-5.dsc 0aa3b5b924b6e3ac59208aadd40580c5 21491 web optional libapache2-mod-xslt_0.9.9+rc1-5.diff.gz bdc41a2e76b8f52b1c26cca9392e2ac4 16884 web optional libapache2-mod-xslt_0.9.9+rc1-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/lf1icPClnTztfv0RAqMcAJ9+TZpK7bVsnHHzHkGE3qexXURx8ACeNe58 gi4NvswlpNld0cJ4iyqS5qI= =KDbn -END PGP SIGNATURE- Accepted: libapache2-mod-xslt_0.9.9+rc1-5.diff.gz to pool/main/liba/libapache2-mod-xslt/libapache2-mod-xslt_0.9.9+rc1-5.diff.gz libapache2-mod-xslt_0.9.9+rc1-5.dsc to pool/main/liba/libapache2-mod-xslt/libapache2-mod-xslt_0.9.9+rc1-5.dsc libapache2-mod-xslt_0.9.9+rc1-5_i386.deb to pool/main/liba/libapache2-mod-xslt/libapache2-mod-xslt_0.9.9+rc1-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dbus 0.13-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Oct 2003 13:54:53 +1000 Source: dbus Binary: dbus-glib-1-dev dbus-1-utils dbus-1 dbus-glib-1 dbus-1-doc dbus-1-dev Architecture: source i386 all Version: 0.13-1 Distribution: unstable Urgency: low Maintainer: Daniel Stone [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: dbus-1 - simple inter-process messaging system dbus-1-dev - simple inter-process messaging system (development headers) dbus-1-doc - simple inter-process messaging system (documentation) dbus-1-utils - simple inter-process messaging system (utilities) dbus-glib-1 - simple inter-process messaging system (GLib-based shared library) dbus-glib-1-dev - simple inter-process messaging system (GLib interface) Closes: 213914 Changes: dbus (0.13-1) unstable; urgency=low . * New upstream release. * debian/control: + Update Maintainer address to debian.org. + Add Recommends: dbus-glib-1 to dbus-1-utils, for the dbus-monitor program. (closes: #213914) Files: 3561b6b515fd2dec08413d7bc93c55d6 692 devel optional dbus_0.13-1.dsc b7f29a4b581445a1290df84d1fbb31ee 994063 devel optional dbus_0.13.orig.tar.gz 6575f14deb6ec73f0ea43cd1e6cc43c0 7998 devel optional dbus_0.13-1.diff.gz 95b5b23d5511b219795b7aff8539507d 751136 doc optional dbus-1-doc_0.13-1_all.deb 9659f9044defb5ebf00f3a1878c823b7 228066 devel optional dbus-1_0.13-1_i386.deb 7c0e5d5456d5d94fcc288b3532e61af4 60284 libs optional dbus-glib-1_0.13-1_i386.deb 455bfcb150d4c517e23cac87f07f80b1 66640 utils optional dbus-1-utils_0.13-1_i386.deb 8920b661afc08e0430486b8198a57033 151662 libdevel optional dbus-1-dev_0.13-1_i386.deb 7b22be19168675c481e5da87d1a57da8 60080 libdevel optional dbus-glib-1-dev_0.13-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/lgKbcPClnTztfv0RAh+mAJ90JdYH5XNm+RN+YGESMk00MLcyCACcDrfn Q36mXbTXfLOKK/z5hrfjjT8= =6B8u -END PGP SIGNATURE- Accepted: dbus-1-dev_0.13-1_i386.deb to pool/main/d/dbus/dbus-1-dev_0.13-1_i386.deb dbus-1-doc_0.13-1_all.deb to pool/main/d/dbus/dbus-1-doc_0.13-1_all.deb dbus-1-utils_0.13-1_i386.deb to pool/main/d/dbus/dbus-1-utils_0.13-1_i386.deb dbus-1_0.13-1_i386.deb to pool/main/d/dbus/dbus-1_0.13-1_i386.deb dbus-glib-1-dev_0.13-1_i386.deb to pool/main/d/dbus/dbus-glib-1-dev_0.13-1_i386.deb dbus-glib-1_0.13-1_i386.deb to pool/main/d/dbus/dbus-glib-1_0.13-1_i386.deb dbus_0.13-1.diff.gz to pool/main/d/dbus/dbus_0.13-1.diff.gz dbus_0.13-1.dsc to pool/main/d/dbus/dbus_0.13-1.dsc dbus_0.13.orig.tar.gz to pool/main/d/dbus/dbus_0.13.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libapache2-mod-xslt 0.9.9+rc1-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 28 Sep 2003 22:24:43 +1000 Source: libapache2-mod-xslt Binary: libapache2-mod-xslt Architecture: source i386 Version: 0.9.9+rc1-4 Distribution: unstable Urgency: low Maintainer: Daniel Stone [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: libapache2-mod-xslt - An apache2 module that does on-the-fly XSLT processing Changes: libapache2-mod-xslt (0.9.9+rc1-4) unstable; urgency=low . * debian/rules: + Add build-arch/build-indep etc sections to be compliant to the Standards-Version I said it was. Files: 5159b24e13a89a1ef3a66e13e2c382d0 677 net optional libapache2-mod-xslt_0.9.9+rc1-4.dsc 93e32fc88a11fb76cad4b6b9c5570cae 21397 net optional libapache2-mod-xslt_0.9.9+rc1-4.diff.gz adb8cc3cacf201d436fb71e6080ce146 17116 net optional libapache2-mod-xslt_0.9.9+rc1-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD4DBQE/dvENJYSUupF6Il4RAg1kAJ4srvptMEDst5IURsaEhiuTj0bjZACXbE94 K1neelJXezp10aMHaCmuWw== =btGi -END PGP SIGNATURE- Accepted: libapache2-mod-xslt_0.9.9+rc1-4.diff.gz to pool/main/liba/libapache2-mod-xslt/libapache2-mod-xslt_0.9.9+rc1-4.diff.gz libapache2-mod-xslt_0.9.9+rc1-4.dsc to pool/main/liba/libapache2-mod-xslt/libapache2-mod-xslt_0.9.9+rc1-4.dsc libapache2-mod-xslt_0.9.9+rc1-4_i386.deb to pool/main/liba/libapache2-mod-xslt/libapache2-mod-xslt_0.9.9+rc1-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dbus 0.12-4 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 22 Sep 2003 12:13:06 +1000 Source: dbus Binary: dbus-glib-1 dbus-1-doc dbus-glib-1-dev dbus-1-utils dbus-1 dbus-1-dev Architecture: source i386 all Version: 0.12-4 Distribution: unstable Urgency: low Maintainer: Daniel Stone [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: dbus-1 - simple inter-process messaging system dbus-1-dev - simple inter-process messaging system (development headers) dbus-1-doc - simple inter-process messaging system (documentation) dbus-1-utils - simple inter-process messaging system (utilities) dbus-glib-1 - simple inter-process messaging system (GLib-based shared library) dbus-glib-1-dev - simple inter-process messaging system (GLib interface) Closes: 209143 Changes: dbus (0.12-4) unstable; urgency=low . * debian/control: + Taking over from Colin as maintainer. + Bump debhelper Build-Dep to =4.1.46, when dh_installlogcheck was first introduced. + Bump Standards-Version to 3.6.1. + Add Replaces/Provides/Conflicts on earlier dbus-1 versions to dbus-1-utils. * debian/dbus-1.init: + Clean up after the daemon's pidfile mess, ensuring smooth upgrades. (closes: #209143) Files: 90affa86093d9781e52b86ffe3e8482b 694 devel optional dbus_0.12-4.dsc 574ad3afb8301a8ac0d6a90e35ae00d4 7916 devel optional dbus_0.12-4.diff.gz 6a74f4c034bcaf8c7a925216cfde8167 756528 doc optional dbus-1-doc_0.12-4_all.deb b992900a1f45a25dff6d8bf836ac0e84 242468 devel optional dbus-1_0.12-4_i386.deb 1c9baf2f3af9c931a06b42d3a5c373af 60022 libs optional dbus-glib-1_0.12-4_i386.deb 549a5fd096f746cfd748ead58aef6a4b 66362 utils optional dbus-1-utils_0.12-4_i386.deb 90375300b5ca9ccaafc1382c313793b4 156594 libdevel optional dbus-1-dev_0.12-4_i386.deb a277a85dddbd52a3a6bc057a0b57c22a 59734 libdevel optional dbus-glib-1-dev_0.12-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/br9yKb5dImj9VJ8RAs3CAJ9kr7AEWk1YivSyAbGKWM8QJxg9HQCbBse0 itFldq6dKSHrHYTHs3Puy9s= =P+H+ -END PGP SIGNATURE- Accepted: dbus-1-dev_0.12-4_i386.deb to pool/main/d/dbus/dbus-1-dev_0.12-4_i386.deb dbus-1-doc_0.12-4_all.deb to pool/main/d/dbus/dbus-1-doc_0.12-4_all.deb dbus-1-utils_0.12-4_i386.deb to pool/main/d/dbus/dbus-1-utils_0.12-4_i386.deb dbus-1_0.12-4_i386.deb to pool/main/d/dbus/dbus-1_0.12-4_i386.deb dbus-glib-1-dev_0.12-4_i386.deb to pool/main/d/dbus/dbus-glib-1-dev_0.12-4_i386.deb dbus-glib-1_0.12-4_i386.deb to pool/main/d/dbus/dbus-glib-1_0.12-4_i386.deb dbus_0.12-4.diff.gz to pool/main/d/dbus/dbus_0.12-4.diff.gz dbus_0.12-4.dsc to pool/main/d/dbus/dbus_0.12-4.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libapache2-mod-xslt 0.9.9+rc1-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 9 Sep 2003 22:18:23 +1000 Source: libapache2-mod-xslt Binary: libapache2-mod-xslt Architecture: source i386 Version: 0.9.9+rc1-3 Distribution: unstable Urgency: low Maintainer: Daniel Stone [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: libapache2-mod-xslt - An apache2 module that does on-the-fly XSLT processing Closes: 208996 Changes: libapache2-mod-xslt (0.9.9+rc1-3) unstable; urgency=low . * Rebuild for new apache2, fixing RC bug. (closes: #208996) * debian/control: + Change Maintainer field to my new email address. Files: 74a668bb4a48ee6928c7d0db6b741f78 677 net optional libapache2-mod-xslt_0.9.9+rc1-3.dsc f2ad7bbd163bab789d5daa1e86186433 21300 net optional libapache2-mod-xslt_0.9.9+rc1-3.diff.gz 8019d519b2aea695352eb9c0daf44b37 16974 net optional libapache2-mod-xslt_0.9.9+rc1-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/XfsSs10SPRMEYVURAvnuAJ4uab3+Fw5UGgX/HtXpbSFswbOOEgCglb+C kVAvsB46ezsfCR+nJlWc7nI= =Jl34 -END PGP SIGNATURE- Accepted: libapache2-mod-xslt_0.9.9+rc1-3.diff.gz to pool/main/liba/libapache2-mod-xslt/libapache2-mod-xslt_0.9.9+rc1-3.diff.gz libapache2-mod-xslt_0.9.9+rc1-3.dsc to pool/main/liba/libapache2-mod-xslt/libapache2-mod-xslt_0.9.9+rc1-3.dsc libapache2-mod-xslt_0.9.9+rc1-3_i386.deb to pool/main/liba/libapache2-mod-xslt/libapache2-mod-xslt_0.9.9+rc1-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dbtcp 0.1.17-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 31 May 2003 16:10:44 +1000 Source: dbtcp Binary: libdbd-dbftp-perl dbtcp php4-dbtcp Architecture: source i386 Version: 0.1.17-1 Distribution: unstable Urgency: low Maintainer: Daniel Stone [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: dbtcp - Miscellaneous command-line DBTCP utils libdbd-dbftp-perl - Perl bindings for DBTCP php4-dbtcp - PHP bindings for DBTCP Closes: 114398 Changes: dbtcp (0.1.17-1) unstable; urgency=low . * Initial release. (closes: #114398) * windows/: + Removed, as no source was available that I could find, thus its legality was questionable. * Numerous fixes for clean compilation, including to dbug/dbug.c, the PHP4 module Makefile (complete rewrite), and more. * dbtcp.1: + Removed: EXAMPLES I hate man Files: 0f26bfedba6b088ec5642b1482bf4a18 640 net optional dbtcp_0.1.17-1.dsc a1eb2eed242612d0ddfe59de2948eb4b 126144 net optional dbtcp_0.1.17.orig.tar.gz bacac61181299058178a3e60329284fb 3265 net optional dbtcp_0.1.17-1.diff.gz cbd80a75e3609528ba31671faa535a27 12968 net optional dbtcp_0.1.17-1_i386.deb a71dfb8719cdc96c41b2689379d40933 25034 net optional libdbd-dbftp-perl_0.1.17-1_i386.deb 31deb5d2c1dcb41b623b7deb9dfe0557 10934 net optional php4-dbtcp_0.1.17-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+7CdQwJ0/XSswJFIRAl+JAKCDNClxwE0UfATFFY4giDbR/ook1wCgoSqg foP3R6pFyyLQSATSUMFHLR8= =II1L -END PGP SIGNATURE- Accepted: dbtcp_0.1.17-1.diff.gz to pool/main/d/dbtcp/dbtcp_0.1.17-1.diff.gz dbtcp_0.1.17-1.dsc to pool/main/d/dbtcp/dbtcp_0.1.17-1.dsc dbtcp_0.1.17-1_i386.deb to pool/main/d/dbtcp/dbtcp_0.1.17-1_i386.deb dbtcp_0.1.17.orig.tar.gz to pool/main/d/dbtcp/dbtcp_0.1.17.orig.tar.gz libdbd-dbftp-perl_0.1.17-1_i386.deb to pool/main/d/dbtcp/libdbd-dbftp-perl_0.1.17-1_i386.deb php4-dbtcp_0.1.17-1_i386.deb to pool/main/d/dbtcp/php4-dbtcp_0.1.17-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#198602: ITP: debbackup -- Backup and restore Debian specifics (package status, conffiles)
Package: wnpp Version: unavailable; reported 2003-06-24 Severity: wishlist * Package name: debbackup Version : 0.1 Upstream Author : Daniel Stone [EMAIL PROTECTED] * URL : http://www.trinity.unimelb.edu.au/~dstone/debbackup/ (not functional yet) * License : GPL Description : Backup and restore Debian specifics (package status, conffiles) debbackup is a supplemental, Debian-specific, backup program. It backs up only what is needed to restore from a fresh install, with data recovered - package information (including holds/etc), conffile changes, Debconf information, and more. debrestore will restore this information - installing/updating required packages, restoring configuration files, and more. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux nanasawa 2.5.72-mm3 #1 Mon Jun 23 21:43:29 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C -- Daniel Stone [EMAIL PROTECTED] Developer, Trinity College, University of Melbourne pgpYc1ZAUSf7Q.pgp Description: PGP signature
Accepted libapache2-mod-xslt 0.9.9+rc1-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 1 Jun 2003 16:17:27 +1000 Source: libapache2-mod-xslt Binary: libapache2-mod-xslt Architecture: source i386 Version: 0.9.9+rc1-2 Distribution: unstable Urgency: low Maintainer: Daniel Stone [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: libapache2-mod-xslt - An apache2 module that does on-the-fly XSLT processing Changes: libapache2-mod-xslt (0.9.9+rc1-2) unstable; urgency=low . * src/xsltools.c, src/mod-xslt.c, debian/xslt.conf, doc/index.xml, README: + Changed MIME type to application/x-xsl to protect locale-cleanness; also made it aware of a couple of other common MIME types for XSL documents. * src/mod-xslt.c: + Add ourselves to the Server: header. * debian/copyright: + Whoops, clean this one up. * debian/control: + Bump Standards-Version to 3.5.10. + Version Build-Dep on apache2, as apxs moved back to apxs2. * debian/rules: + Add '--with-apxs=/usr/bin/apxs2' - it moved back to where it should be in 2.0.46-1. * debian/control, debian/libapache2-mod-xslt-doc.*, debian/libapache2-mod-xslt.examples, debian/rules: + Removed the libapache2-mod-xslt-doc package, moved index.x[ms]l into /usr/share/libapache2-mod-xslt/examples, so you don't need to have it cluttering up your docroot. Files: 867bd5d7a2413b6507f920c8574baceb 684 net optional libapache2-mod-xslt_0.9.9+rc1-2.dsc 8a2ac085cfb4d52f7f70c4d283d4b7ab 71103 net optional libapache2-mod-xslt_0.9.9+rc1.orig.tar.gz ec789d5ace8b79d88f266a0c30641fa7 21189 net optional libapache2-mod-xslt_0.9.9+rc1-2.diff.gz c8a33dbcfe913c6a173224cb5cb7eaa5 16572 net optional libapache2-mod-xslt_0.9.9+rc1-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+2eEHs10SPRMEYVURAhHOAKCeXlrpz+uT/NpGv2TcPPD0LhhY0wCfVnF6 tqxZxBT89GQGyKA/jWMVNsI= =zHv+ -END PGP SIGNATURE- Accepted: libapache2-mod-xslt_0.9.9+rc1-2.diff.gz to pool/main/liba/libapache2-mod-xslt/libapache2-mod-xslt_0.9.9+rc1-2.diff.gz libapache2-mod-xslt_0.9.9+rc1-2.dsc to pool/main/liba/libapache2-mod-xslt/libapache2-mod-xslt_0.9.9+rc1-2.dsc libapache2-mod-xslt_0.9.9+rc1-2_i386.deb to pool/main/liba/libapache2-mod-xslt/libapache2-mod-xslt_0.9.9+rc1-2_i386.deb libapache2-mod-xslt_0.9.9+rc1.orig.tar.gz to pool/main/liba/libapache2-mod-xslt/libapache2-mod-xslt_0.9.9+rc1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ATI Linux Driver Packages
On Sun, 1 Jun 2003 23:16:12 -0500, Adam Majer wrote: On Sun, Jun 01, 2003 at 09:42:10PM -0500, Chris Cheney wrote: Are these drivers much better then than XFree ones or is there a reason to be promoting nonfree drivers? I orginally packaged up the nvidia ones in the way they are done due to the fact the XFree ones had no 3d acceleration at all and that it was illegal to distribute nvidia's binaries directly. Also binary only drivers will taint the kernel and can cause the user to have trouble getting help with kernel related issues. I got rid of my nvidia cards (some poor sucker took them) and now use only ATI cards. 8) I think you might be the sucker. :) [ok, it's not a flame thing]. Does the radeon driver support 3D accel for cards beyond the R1xx level? ie. something like Radeon 7500. I don't think that Radeon 8500, 8800, etc..a are supported since they use the former FireGL GPU. The drivers from ATI fill the gap to support FireGL, and yes they are better. They can be used with Maya etc.. [at least it says that on ATI's site.] 3D acceleration exists for r[12]xx and r250; I'm not sure whether it exists for the rv280. Indeed, it's in the stock XFree86 4.3 debs previously distributed by myself, now distributed by the XSF. [EMAIL PROTECTED]:~/music/mixMasterMike/spinPsycle% glxinfo | grep OpenGL OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI R200 20020827 AGP 4x x86/MMX/3DNow! TCL OpenGL version string: 1.2 Mesa 4.0.4 OpenGL extensions: BUT, ATI doesn't have any drivers for new cards like Radeon 9800 and I do not think they will have any Linux drivers. The r3xx series is currently only supported (in both 2D and 3D form) by ATI's binary drivers. However, ATI have a standing offer of specs, hardware and developer access to any DRI developer who wants to write a driver for the r3xx series. On the other hand, I installed Debian for a frried and he had a GeForce 4 MX card. The driver from nVidia worked perfectly. Futhermore, I think that they only distribute the X driver that's precompiled. The kenrel part has to be compiled by hand (which is good). Binary-only drivers are best avoided, but when you have no other option, sure. Futhermore, I believe that nVidia have _much_ better support in X from nVidia than radeon ever had from ATI. The free 3D driver hacked together does not give good performance as does nVidia's propriatory driver. Frankly, I very much prefer that nVidia has in-house support for their cards while ATI has none (the ones for Radeon 8500, 8800, etc.. are just FireGL drivers). Uhh, that's utterly incorrect. My Radeon 9000 has out-of-the-box 3D support, as do original Radeons, and all Radeon 7xxx, 8xxx, and 9[01]00 cards. The 9200 *may*, but I'm unsure. Hell, GATOS will even give you VIVO support. The reason why you only get FireGL drivers is because you don't *need* those drivers for the cards I mentioned above. As for support, I've had pretty amazing support from ATI. ATI have developer contacts who regularly feed patches into XFree86 upstream and packagers (the entire 030 patch series was sent through ATI), and they have the standing offer I mentioned above. The only thing preventing capital-F-Free drivers being written right now is DRI developer time constraints, AIUI. nVidia have never offered any such deals to developers, or Free drivers (the current ATI driver was originally donated by ... yep, them - ATI). I personally buy ATI because not only are they currently the best card around (even when wrapped in OpenGL, the demo optimized for nVidia cards, by nVidia, to show off nVidia cards, runs over 15% faster on the 9800 Pro than the GeForce FX, and the 9800 Pro has been out longer than the FX. Not only that, but ATI have offered outstanding support to XFree86, and I can do my acceleration with a Free driver, not needing to depend on nVidia to fix my bugs, or make the kernel module not use up 1mb RSS, or whatever. Daniel, happily with his Freely out-of-the-box 3D-accelerated r250. -- Daniel Stone [EMAIL PROTECTED] [EMAIL PROTECTED] KDE: Konquering a desktop near you - http://www.kde.org pgpseTCKzQvX8.pgp Description: PGP signature
dbtcp RFP-ITP
retitle 114398 ITP: dbtcp -- A client for the MS Windows ODBC proxy server thanks [Please reply to me, Cc'ing the list, as per the M-F-T header]. Hi all! Just a quick note to say that I've packaged up dbtcp, and am thus taking over the RFA (#114398). It was pretty fun to package - a PHP4 module that ostensibly needs to be built in-tree. However, it took a nice hand-hacked Makefile to make it build out-of-tree, and even then it has some fun issues. PHP4 installs to /usr/lib/php4/date, where date is probably the release date (it's 20020429, currently). I can work out the directory to install to (php-config --extension-dir), but how should I handle this in package relationships? If the date changes, php4-dbtcp suddenly becomes useless - PHP's looking in a different directory for its extensions. Anyway, the debs are at: deb http://www.trinity.unimelb.edu.au/~dstone/debian/ dbtcp/ deb-src http://www.trinity.unimelb.edu.au/~dstone/debian/ dbtcp/ Cheers! :) d -- Daniel Stone [EMAIL PROTECTED] Developer, Trinity College, University of Melbourne pgpIMvUk8ZAZH.pgp Description: PGP signature
Re: Galeon 1.2.x on pila (finally!)
On Sun, Jun 01, 2003 at 09:06:40PM +1000, Daniel Stone wrote: Gentlemen, I've restored Galeon on pila to its former 1.2.x glory. A few packages (galeon, galeon-common, mozilla-browser, mozilla-psm, libnss3, libnspr4) are now on hold: don't touch them (and watch apt quietly playing with the hold), unless you want Galeon 1.3 again. And I've outdone myself. ;) Shortly after doing this, someone pointed out to me that there's actually a Galeon 1.2 rebuild against Mozilla 1.3, latest sid, etc. So, you can upgrade now, flagrantly disregarding the holds (there are none), but be aware that the package name is now galeon1.2, not galeon. :) d -- Daniel Stone [EMAIL PROTECTED] [EMAIL PROTECTED] KDE: Konquering a desktop near you - http://www.kde.org pgpFJTRWIOPjT.pgp Description: PGP signature
ignore (misdirected) parent (was: Re: Galeon 1.2.x on pila (finally!))
On Sun, Jun 01, 2003 at 10:07:07PM +1000, Daniel Stone wrote: [stuff utterly irrelevant to -devel] Please ignore the parent post; somehow, mutt managed to take a mail sent to 'oldk, bhat', and reply to -devel. *shrug*. Sorry, Daniel -- Daniel Stone [EMAIL PROTECTED] [EMAIL PROTECTED] KDE: Konquering a desktop near you - http://www.kde.org pgpEjF9F6KrKk.pgp Description: PGP signature
Re: X Strike Force SVN commit: rev 69 - branches/4.3.0/sid/debian
On Mon, May 26, 2003 at 01:54:57PM -0500, Branden Robinson wrote: 1) Should libstdc++-dev dependencies be made artificially strict in packages destined for sid so that it's harder for packages built against, say, libstdc++3 to accidentally sneak in and start regressing the C++ ABI transition progress? Well, this isn't a problem for buildds, because I made libstdc++5-dev the preference. 2) Is libstdc++5-3.3 ABI-compatible with libstdc+5? Does the former have any symbols that the latter lacks? I *believe* it's completely ABI-compatible, but I could be wrong. -- Daniel Stone [EMAIL PROTECTED] [EMAIL PROTECTED] KDE: Konquering a desktop near you - http://www.kde.org pgphpDyejfWsS.pgp Description: PGP signature
Accepted kdenetwork 4:3.1.1-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 19 Mar 2003 08:08:47 +1100 Source: kdenetwork Binary: libmimelib1-dev knewsticker ksirc kppp kpf knode kxmlrpc kmail libkdenetwork2 kdenetwork kget kit kmailcvt korn kdenetwork-kfile-plugins kgpgcertmanager krfb krdc libmimelib1 libkdenetwork2-dev ktalkd kdict lisa Architecture: source i386 all Version: 4:3.1.1-1 Distribution: unstable Urgency: low Maintainer: Christopher L Cheney [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: kdenetwork - KDE Network metapackage kdenetwork-kfile-plugins - KFile Email Plugin kdict - KDE Dictionary Client kget - KDE Download Manager kgpgcertmanager - KDE Certificate Manager kit- KDE AOL Instant Messenger Client kmail - KDE Email client kmailcvt - KDE KMail addressbook converter knewsticker - KDE news ticker knode - KDE news reader korn - KDE mail checker kpf- KDE public fileserver kppp - KDE dialer and frontend to pppd krdc - KDE Remote Desktop Client krfb - KDE Remote Screen Server ksirc - KDE IRC client ktalkd - KDE talk daemon kxmlrpc- KDE XML RPC Daemon libkdenetwork2 - KDE Network (common libraries) libkdenetwork2-dev - KDE Network (development files) libmimelib1 - KDE network mime library libmimelib1-dev - KDE network mime library (development files) lisa - LAN Information Server Changes: kdenetwork (4:3.1.1-1) unstable; urgency=low . * New upstream release. * Daniel Stone: + NMU with Maintainer's blessing. + Fixed debian/copyright to refer to both the GPL and Artistic licenses. Files: 85d498cf2ce45b3a1afaa0b82b784973 881 net optional kdenetwork_3.1.1-1.dsc ad3d42f9728b65a2c5139a3d4a5b181d 4696283 net optional kdenetwork_3.1.1.orig.tar.gz 19844574955d2a0b2e10802655ee3095 580166 net optional kdenetwork_3.1.1-1.diff.gz eb0eb4cc3dc5b3fae530a39bbf9c539e 9294 net optional kdenetwork_3.1.1-1_all.deb d1119c7f521ba1813261da2b63ea9c53 18772 net optional kdenetwork-kfile-plugins_3.1.1-1_i386.deb 404e74c91f4f6747afda15512d86a5dc 255410 net optional kdict_3.1.1-1_i386.deb 54728348d613ba87a88920a23f318524 208572 net optional kget_3.1.1-1_i386.deb aa5e102bc9316377ac4cde4cac395e39 69414 net optional kgpgcertmanager_3.1.1-1_i386.deb 861b0e9f8e461e3230a2de7800c965cb 141274 net optional kit_3.1.1-1_i386.deb 84a25483e54b19e603bd861729f81c0b 1038906 mail optional kmail_3.1.1-1_i386.deb 985b88a085b34a3929bf24678528b034 63264 mail optional kmailcvt_3.1.1-1_i386.deb 977b9f45f05b1b4fa6e34352717b8e1d 479830 web optional knewsticker_3.1.1-1_i386.deb fbd6c45edf9509ffc3157f2e4da70869 922774 news optional knode_3.1.1-1_i386.deb 5c8b8757ef65b16806b8080162dc493a 76838 mail optional korn_3.1.1-1_i386.deb faadd86eda928eb0ec01ca201129c982 167010 net optional kpf_3.1.1-1_i386.deb 2acf128055a53e47977eac26672d1afb 632154 net optional kppp_3.1.1-1_i386.deb b5734871b2202ecaa4cb62a91197dd3e 106796 net optional krdc_3.1.1-1_i386.deb b22d523c8cb72a64d4f43eb7a59b2d1a 540538 net optional krfb_3.1.1-1_i386.deb f448c3d091a683b8a788079356eac9ac 451612 net optional ksirc_3.1.1-1_i386.deb fe464b5c0054fe612ad4001a02f410fa 107396 net extra ktalkd_3.1.1-1_i386.deb 99fa20cf727a9408abd52dd824aa28d2 59072 net optional kxmlrpc_3.1.1-1_i386.deb 41048d480c74ae5df2f0236d813612a3 253526 libs optional libkdenetwork2_3.1.1-1_i386.deb 510733b99f8d84f2d828d28aa2d5afc9 9976 devel optional libkdenetwork2-dev_3.1.1-1_i386.deb 701044b4633605445aadec7de4db2643 79082 libs optional libmimelib1_3.1.1-1_i386.deb 33dc38a79304a6705a86be2420f537e2 59732 devel optional libmimelib1-dev_3.1.1-1_i386.deb 161eac460aab2ddb0138265e9f24 156198 net optional lisa_3.1.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+d5OXHPo+jNcUXjARAreiAKCOMjEc+ew4ePfGuerbzY9eSixHtQCfYmEK 5Rm8/bcgmvM1+dricpwCe6E= =0FL7 -END PGP SIGNATURE- Accepted: kdenetwork-kfile-plugins_3.1.1-1_i386.deb to pool/main/k/kdenetwork/kdenetwork-kfile-plugins_3.1.1-1_i386.deb kdenetwork_3.1.1-1.diff.gz to pool/main/k/kdenetwork/kdenetwork_3.1.1-1.diff.gz kdenetwork_3.1.1-1.dsc to pool/main/k/kdenetwork/kdenetwork_3.1.1-1.dsc kdenetwork_3.1.1-1_all.deb to pool/main/k/kdenetwork/kdenetwork_3.1.1-1_all.deb kdenetwork_3.1.1.orig.tar.gz to pool/main/k/kdenetwork/kdenetwork_3.1.1.orig.tar.gz kdict_3.1.1-1_i386.deb to pool/main/k/kdenetwork/kdict_3.1.1-1_i386.deb kget_3.1.1-1_i386.deb to pool/main/k/kdenetwork/kget_3.1.1-1_i386.deb kgpgcertmanager_3.1.1-1_i386.deb to pool/main/k/kdenetwork/kgpgcertmanager_3.1.1-1_i386.deb kit_3.1.1-1_i386.deb to pool/main/k/kdenetwork/kit_3.1.1-1_i386.deb kmail_3.1.1-1_i386.deb to pool/main/k/kdenetwork/kmail_3.1.1-1_i386.deb kmailcvt_3.1.1-1_i386.deb to pool/main/k/kdenetwork/kmailcvt_3.1.1-1_i386.deb knewsticker_3.1.1-1_i386.deb to pool/main/k/kdenetwork/knewsticker_3.1.1-1_i386.deb knode_3.1.1-1_i386.deb to pool/main/k/kdenetwork
Accepted kdepim 4:3.1.1-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 19 Mar 2003 08:33:19 +1100
Source: kdepim
Binary: knotes kdepim-dev kdepim-libs kdepim-kfile-plugins kdepim kandy ksync
kaddressbook kalarm kpilot korganizer karm kdepim-doc
Architecture: source i386 all
Version: 4:3.1.1-1
Distribution: unstable
Urgency: low
Maintainer: Christopher L Cheney [EMAIL PROTECTED]
Changed-By: Daniel Stone [EMAIL PROTECTED]
Description:
kaddressbook - KDE NG addressbook application
kalarm - KDE alarm message scheduler
kandy - KDE mobile phone utility
karm - KDE time tracker tool
kdepim - KDE Personal Information Management metapackage
kdepim-dev - KDE Personal Information Management (development files)
kdepim-doc - KDE Personal Information Management documentation
kdepim-kfile-plugins - KDE File dialog plugins for vcf files.
kdepim-libs - KDE PIM libraries
knotes - KDE Notes
korganizer - KDE personal organizer
kpilot - KDE Palm Pilot hot-sync tool
ksync - KDE Sync
Changes:
kdepim (4:3.1.1-1) unstable; urgency=low
.
* Chris Cheney, others:
+ New upstream.
+ Redo debian dir.
* Daniel Stone:
+ NMU with Chris's blessing.
+ debian/kaplan.install:
- Wildcard the kpinterfaces.so.1{,.0.0} reference.
+ debian/kdepim-dev.install:
- Fix kdepim-dev so it's actually installable - remove all the
/usr/lib/kde3/*.so's, which are in other packages as well.
+ debian/copyright:
- Change debian/copyright to more explicitly state the licenses, and
point people towards common-licenses, a la kdenetwork.
Files:
c35dda3364c0d289a6ee9a0e47e794f7 875 x11 optional kdepim_3.1.1-1.dsc
91ff8abd34511206db168da03eed7527 2861213 x11 optional kdepim_3.1.1.orig.tar.gz
7009e170d2cd0b98e4c6a8345a408a25 1115971 x11 optional kdepim_3.1.1-1.diff.gz
5915abe53b64ea4c526af74d1d67be62 4182 x11 optional kdepim_3.1.1-1_all.deb
9931373236b4c1fb00be96cb3189512f 2462440 doc optional kdepim-doc_3.1.1-1_all.deb
eecd406c29c06a62815d7753042cf8b2 31334 devel optional kdepim-dev_3.1.1-1_i386.deb
9242db84cbe3d2b52c5ccf1199888a70 322384 utils optional kaddressbook_3.1.1-1_i386.deb
9864407086ebe9d11ffabbaf7b1c34fb 307410 utils optional kalarm_3.1.1-1_i386.deb
908014f1d1a06cad74dbd52d06e73251 76152 utils optional kandy_3.1.1-1_i386.deb
1d1c6d8b0a1e21f7d47841a71b200ea2 85644 utils optional karm_3.1.1-1_i386.deb
a80f128b6030ee5a91633db59d81ef58 12688 utils optional
kdepim-kfile-plugins_3.1.1-1_i386.deb
186a40eda1f4c82fd3d670b7ddd4b2b1 406372 utils optional kdepim-libs_3.1.1-1_i386.deb
40d09a27760ac925c4b516e7db5871c9 87626 utils optional knotes_3.1.1-1_i386.deb
71e2522eb9fce6a0e74c4b1a2289b255 763798 x11 optional korganizer_3.1.1-1_i386.deb
6426445d8fbf20408ca1300097d0787b 763098 utils optional kpilot_3.1.1-1_i386.deb
f592a85003b1b518f847a5957205e19d 45394 utils optional ksync_3.1.1-1_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+d5iXHPo+jNcUXjARAlxGAJsHovjC41LvjiOUfJRSqxYN3pxxZgCdHZhq
tgu3i+uAxoxHTviTDt6zYwU=
=xU8S
-END PGP SIGNATURE-
Accepted:
kaddressbook_3.1.1-1_i386.deb
to pool/main/k/kdepim/kaddressbook_3.1.1-1_i386.deb
kalarm_3.1.1-1_i386.deb
to pool/main/k/kdepim/kalarm_3.1.1-1_i386.deb
kandy_3.1.1-1_i386.deb
to pool/main/k/kdepim/kandy_3.1.1-1_i386.deb
karm_3.1.1-1_i386.deb
to pool/main/k/kdepim/karm_3.1.1-1_i386.deb
kdepim-dev_3.1.1-1_i386.deb
to pool/main/k/kdepim/kdepim-dev_3.1.1-1_i386.deb
kdepim-doc_3.1.1-1_all.deb
to pool/main/k/kdepim/kdepim-doc_3.1.1-1_all.deb
kdepim-kfile-plugins_3.1.1-1_i386.deb
to pool/main/k/kdepim/kdepim-kfile-plugins_3.1.1-1_i386.deb
kdepim-libs_3.1.1-1_i386.deb
to pool/main/k/kdepim/kdepim-libs_3.1.1-1_i386.deb
kdepim_3.1.1-1.diff.gz
to pool/main/k/kdepim/kdepim_3.1.1-1.diff.gz
kdepim_3.1.1-1.dsc
to pool/main/k/kdepim/kdepim_3.1.1-1.dsc
kdepim_3.1.1-1_all.deb
to pool/main/k/kdepim/kdepim_3.1.1-1_all.deb
kdepim_3.1.1.orig.tar.gz
to pool/main/k/kdepim/kdepim_3.1.1.orig.tar.gz
knotes_3.1.1-1_i386.deb
to pool/main/k/kdepim/knotes_3.1.1-1_i386.deb
korganizer_3.1.1-1_i386.deb
to pool/main/k/kdepim/korganizer_3.1.1-1_i386.deb
kpilot_3.1.1-1_i386.deb
to pool/main/k/kdepim/kpilot_3.1.1-1_i386.deb
ksync_3.1.1-1_i386.deb
to pool/main/k/kdepim/ksync_3.1.1-1_i386.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: KDEE3 question
[Excuse the dodgy quality, I'm trying to construct a reply from DWN]. On Fri, 29 Nov 2002 15:03:05 +0100, Michael Meskes scrawled: but since gcc 2.95 is still standard in Debian I guess the switch to 3.2 will take much longer than the release of KDE 3.1 which is due next week. And the explanation we have no KDE 3 since we are still using gcc 2.95 doesn't sound too good because there is no technical reason to couple these two. First thing: KDE 3.1 will not be released this week. Expect a public announcement on this soon, but until then, I can say no more. Sorry, but it's out of my control. Secondly, ftpmasters have to add overrides for new packages, in case you didn't realize. That takes time: their time adding them, and our time waiting. We're trying to minimize the problems by ramming KDE3.1 in with gcc 3.2 and killing two birds with one stone. Not doing so just adds a stupid amount of work to both us (the Debian KDE maintainers - Chris, Ben Burton, Daniel Schepler, David Pashley, Ralf Nolden, and myself), and the ftpmasters. Until then, you'll just have to wait. More work also still has to be done on 2.2-3.1 upgrades before it goes into sid, but that's a completely moot point, because it probably won't go in for over a month, even if gcc 3.2 on SPARC is finally fixed. Daniel, occasional KDE package monkey -- Daniel Stone [EMAIL PROTECTED] Developer, Trinity College, University of Melbourne pgpvej4IVvfI5.pgp Description: PGP signature
Re: KDEE3 question
On Thu, Dec 05, 2002 at 10:02:34AM +0100, Michael Meskes scrawled: On Thu, Dec 05, 2002 at 05:17:19PM +1100, Daniel Stone wrote: Secondly, ftpmasters have to add overrides for new packages, in case you didn't realize. That takes time: their time adding them, and our time waiting. We're trying to minimize the problems by ramming KDE3.1 in with gcc 3.2 and killing two birds with one stone. Not doing so just adds a I see the logic behind this, don't get me wrong. The problem just is that the gcc movement is slowing down the KDE packages for quite some time. After all we could have had 3.0.3 or 3.0.4 in Debian for months now. Nope - the 3.0.x packages just were not ready to go into sid. Any package where the upgrade strategy is to purge the old and install the new just doesn't work. 3.1.x will be the first packages where upgrades from 2.2.x are clean. stupid amount of work to both us (the Debian KDE maintainers - Chris, Ben Burton, Daniel Schepler, David Pashley, Ralf Nolden, and myself), and the ftpmasters. I can understand that you want to minimize your workload, but then the packages are there. Ralf spend quite some time on the packages and I'm sure the others did as well. The only difference right now is that the packages are stored elsewhere and yes, the ftpmasters don't have to add them so far. I have not spent a huge amount of time, only a little bit of time preparing 3.0b[12] and 3.0rc[12345], as well as 3.0.3 and 3.0.3a. Karolina has been doing some unofficial packages, as has Ralf, and Ben, Daniel, David and, of course, Chris, have been spending a lot of time making sure current CVS (i.e. what's essentially 3.1), works fine; I have the packages on my laptop and they work flawlessly, thanks to the buildd a co-worker and I setup to do nothing but cvs up and debuild, 24x7. Until then, you'll just have to wait. More work also still has to be done on 2.2-3.1 upgrades before it goes into sid, but that's a completely moot point, because it probably won't go in for over a month, even if gcc 3.2 on SPARC is finally fixed. But then this work has to be spend anyway. Why not starting the testing cycle now with 3.0.5 so 3.1 goes in cleanly? Not without revamping debian/control. I'm also somewhat ... uncomfortable about putting 3.0.x in. If you know why 3.1 has been held up, then you'll know that 3.0.x is quite possibly a worse choice than 2.2.x with regards to that issue. Then again, I'm just an occasional package monkey who ceased to be authoriative with my disastrous 3.0rc5 packages (the last set I made), and, to a lesser degree, long before 3.0b1 when Chris and I divvied up the packages, and I devised my exit strategy. :) d -- Daniel Stone [EMAIL PROTECTED] Developer, Trinity College, University of Melbourne pgpbGZ3uikeE7.pgp Description: PGP signature
Re: [ANNOUNCE] Debian Developer Packages Overview
On Tue, Aug 27, 2002 at 2:43:29PM +0100, Daniel Silverstone wrote: Also, if you search for my GPG key id (20687895) then I get a listing of my packages and also those maintained by [EMAIL PROTECTED] We've had issues of my being mistaken for Daniel Stone in the past, and I don't appreciate it :) (Neither does he I should imagine :) You poor, poor bastard. I recommend a name change post-haste. I'd like to sincerely apologize to you for any humiliation caused for being confused with me. Cheers, The real DanielS (o/~ I'm the real DanielS ...) -- Daniel Stone [EMAIL PROTECTED] http://raging.dropbear.id.au KDE Developer [EMAIL PROTECTED]http://www.kde.org Kopete: Multi-protocol IM client http://kopete.kde.org pgpL5mBQbfWYr.pgp Description: PGP signature
Re: bind9-chroot again
On Tue, Jan 15, 2002 at 02:04:54AM +0100, martin f krafft wrote: remember: http://lists.debian.org/debian-devel/2001/debian-devel-200109/msg01393.html well, i have just installed a couple of bind9, and i am *tired* of chrooting them by hand. can we please have a final vote on whether chrooting bind should be a debconf option of the bind9 package, or whether i could create such a pseudo package, which would chroot an existing installation. i tend for the package just because it's modular, but Bdale said he'd want this functionality in the main package. I vote yes for the Debconfy bit. I chroot it by hand, and I find it insanely nifty, even though bind9 isn't plagued by the same security problems bind is. Helps me sleep better at night, or something. -- Daniel Stone[EMAIL PROTECTED] wolfie who needs a girlfriend wolfie i have a tamagotchi pgpywWtGUmcFJ.pgp Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
On Sat, Jan 12, 2002 at 01:12:37PM +1100, Steve Kowalik wrote: At 10:30 am, Saturday, January 12 2002, Rob Bradford mumbled: I'm now a happy evolution user, to converyt my mail i did cat Mail/lists/* | cat /var/spool/mail/rob Congratulations, you get today's Most Useless Use Of cat award. Plague, and LART will be forthcoming. If you're going to be a pedant, so am I. Firstly, your quoting style is wrong wrong wrong. Let me show you: BAD - on bar, foo wrote: don't fuck with me bitch i'll send the boys over, shithead GOOD - on baz, bar wrote: let's all sit around the fire and sing lesbian seagulls i love you man You see the difference? You don't leave a on the line trailing the quotation. That's just bad form. Also, wrt, Plague, and LART will be forthcoming: you're either missing a comma, or you've put an extra in. Should be either, Plague and LART will be forthcoming, or, preferably: Plague, and LART, will be forthcoming. But wait! Still more errors! You really mean, are forthcoming, not will be forthcoming, right? I hope so. -- Daniel Stone[EMAIL PROTECTED] bod subtle? bod and Overfiend in the same sentence? pgpeZ4UVRAScm.pgp Description: PGP signature
Re: serious bug. Evolution and Microsoft mentality.
On Sat, Jan 12, 2002 at 12:24:11PM +0100, Paul Slootman wrote: On Sat 12 Jan 2002, Daniel Stone wrote: On Sat, Jan 12, 2002 at 01:12:37PM +1100, Steve Kowalik wrote: At 10:30 am, Saturday, January 12 2002, Rob Bradford mumbled: I'm now a happy evolution user, to converyt my mail i did cat Mail/lists/* | cat /var/spool/mail/rob Congratulations, you get today's Most Useless Use Of cat award. Plague, and LART will be forthcoming. If you're going to be a pedant, so am I. Of course, Steve *is* right. Yeah, I'm not arguing that, but he has a habit of making stupid mistakes when being a pedant. *shrug*. -- Daniel Stone[EMAIL PROTECTED] Nuke can NE1 help me aim nuclear weaponz? /MSG ME!! pgp2drp6NuiCR.pgp Description: PGP signature
Re: [kde] and, for my next trick ...
On Sat, Jan 12, 2002 at 01:13:53PM +0100, Peter Makholm wrote: Daniel Stone [EMAIL PROTECTED] writes: Oh, there *appears* to be one? You mean the one I sent this message to, and the one that I'm subscribed to? Right! Thanks for the information! I sent it to -devel because not all KDE users are subscribed to -devel. And since when has users generally been subscribed to -devel? If we have a KDE-specific development list then please use that instead of -devel. If you want to reach users -devel is the wrong list anyways. I'll stop posting to -devel when you come up with the guideline that says don't post important stuff about one of the two major desktop environments breaking hardcore. Gladly. It was an important issue that affected many. -- Daniel Stone[EMAIL PROTECTED] Overfiend Centrx: Who are you? Are you a Debian Developer? Are in the New Maintainer queue? Who is your sponsor? What is your GPG public key ID? Do you understand the Social Contract? Clint_ Wow. This is just like checking into a French youth hostel. pgpUUFcwz3CPN.pgp Description: PGP signature
Re: [kde] and, for my next trick ...
On Sun, Jan 13, 2002 at 12:29:34AM +1100, Hamish Moffatt wrote: On Sun, Jan 13, 2002 at 12:00:30AM +1100, Daniel Stone wrote: I'll stop posting to -devel when you come up with the guideline that says don't post important stuff about one of the two major desktop environments breaking hardcore. Gladly. It was an important issue that affected many. Nonsense. It's not of general interest to developers in their role as developers. I'm not interested in SILC debs, the fact that Musixtex isn't going into testing, or a bug in libgd-perl, in my role as a developer, yet they're the threads immediately surrounding this one. -- Daniel Stone[EMAIL PROTECTED] * Kamion practices the ancient and traditional Debian art of annoying release managers pgp9Fi03X7kWs.pgp Description: PGP signature
[security] What's being done?
Considering that an upload hasn't been made to rectify this root hole, why hasn't something else been done about it - regular or security NMU? One would think that this is definitely serious. Oh and BTW, Slackware released an update today. Without trolling, I can say that I was honestly surprised to note that Debian, a distro with ~850 developers and a dedicated security team, is behind Slackware on security issues. d -- Daniel Stone[EMAIL PROTECTED] WARNING: The consumption of alcohol may make you think you have mystical Kung Fu powers, resulting in you getting your arse kicked. pgpXT5bGXE3PE.pgp Description: PGP signature
Re: [kde] and, for my next trick ...
On Fri, Jan 11, 2002 at 09:14:21AM -0800, Aaron Lehmann wrote: There appears to be a list named debian-kde. PLEASE use that. -devel is already clogged enough, and should be reserved for extremely general or miscellaneous discussion. Date: Thu, 10 Jan 2002 17:17:08 +1100 From: Daniel Stone [EMAIL PROTECTED] To: debian-kde@lists.debian.org Cc: debian-devel@lists.debian.org Subject: [kde] and, for my next trick ... Oh, there *appears* to be one? You mean the one I sent this message to, and the one that I'm subscribed to? Right! Thanks for the information! I sent it to -devel because not all KDE users are subscribed to -devel. Aaron, try thinking before you open your mouth to spurt shit. It can and will work wonders. -- Daniel Stone[EMAIL PROTECTED] Robot101 the UI SUCKS GOAT TESTICLES! bod oh c'mon Robot101, don't hold back... tell us what you *really* think rcw yeah, do you feel that way all over or just in spots? pgpparspz7MLz.pgp Description: PGP signature
Re: Work-needing packages report for Jan 11, 2002
On Fri, Jan 11, 2002 at 11:26:01PM +0100, Tollef Fog Heen wrote: * |libqt3-psql (#127709), orphaned 7 days ago Uhm, shouldn't Daniel Stone or Cheney (sp?) take this one as well, I guess it builds with the rest of qt3. I'm not sure if Chris is taking this along with libqt3. |qt-embedded (#127696), orphaned 7 days ago | Description: Embedded version of QT | Reverse Depends: libqt-emb-dev | |qt-embedded-free (#127697), orphaned 7 days ago | Reverse Depends: libqt3-emb-dev | |qt-x11-free (#127695), orphaned 7 days ago | Description: QT Gui Library | Reverse Depends: libqt3-mysql libqxt0 libqt3-odbc view3ds qt3-tools | libqt3-mt-dev libqt3-dev kascade psi And those? qt-x11 is qt2, qt-x11-free is qt3. Chris has been busy getting Qt2 and KDE2.2 working fully before he turns his attention to Qt3 and KDE3. His hard drive just also died, so give him a little breathing room. -- Daniel Stone[EMAIL PROTECTED] * wiggy points people to arcanum.co.nz wiggy apparently it's fun asuffield wiggy: the last time you said that we lost an entire weekend of useful activity to cocklefighting pgpI3Wyl2F7Mg.pgp Description: PGP signature
