Re: Debian Games Team
On Fri, 13 Jan 2006, Miriam Ruiz wrote: We've been recently talking about creating a group to maintain games in Debian in a collaborative way. Are you aware of the Debian-Junior project. While quite inactive in the last time a certain effort was done in classifying games by building some interesting meta packages. You might also consider to join the Custom Debian Distribution effort which might help to make your target better visible for the users. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trivial bug on apt-file (Was : Re: Development standards for unstable)
On Fri, Jan 13, 2006 at 02:34:32PM +0900, Charles Plessy wrote: On Fri, Jan 13, 2006 at 04:47:33AM +1000, Anthony Towns wrote : On Thu, Jan 12, 2006 at 06:48:38PM +0100, Luk Claes wrote: But if you read this bug (#307833), you'd see that the maintainer doesn't consider it a bug, and has documented why in the README file. It is a bug as the package is not usable without curl or wget installed. Though, I give him a chance to respond to my intention to NMU... An NMU is not the place to fix things that the maintainer has specifically said aren't bugs. Dear Anthony, As stated by the Debian Policy Manual : I'm not disputing whether it's a bug or not, the maintainer is. If you are *helping* the maintainer, then fine: do an NMU. But if you're specifically trying to do something against their wishes, do *not*, under any circumstances, NMU. Find a compromise the maintainer thinks is acceptable, or as a last resort talk to the tech ctte instead. To be clear: it's the maintainer that gets to judge whether what you're doing is helpful or not, not you. As complaining to the tech-ctte should not be done becaues I did not even try to contact the maintainer directly, I will either: - Forget about it, or - File a wishlist bug against packages.debian.org, or whatever appropriate, to suggest to stop suggesting the use of a broken package, or at least to mention the bug. Huh? What's wrong with - Contact the maintainer ? Sébastien, please fix your bug! Can you imagine Debian if all the packages, like yours, would need a manual inspection of the error messages to figure out on what it really depends ??? In my experience you almost always get a better response from people if you assume they've got a good reason for doing what they have been doing, rather than just trying to add extra punctuation to your sentences. Admittedly, punctuation is pretty cool... Cheers, aj signature.asc Description: Digital signature
Re: Need for launchpad
On Thu, Jan 12, 2006 at 07:36:06AM +, Martin Meredith wrote: But, also - and I've had this experience myself - there are some DD's who just plain and simple dont want the stuff from ubuntu. I've had a couple of times where I've had an issue with a package - and realised it was a problem in debian and upstream too. Usually - I've contacted both upstream and the DD via Email about this - and have had various responses - for example, for one package - I sent about 7 emails over the space of a month, emailed upstream, tried to contact the DD on IRC - many a thing - but well - no response - and I've tried a couple of times with different issues to contact that developer regarding those issues - but have never had any awknowledgement, reply etc etc. Out of curiosity, when emailing these DDs, do you send mail through the BTS? It's not unknown for developers to filter bts mail differently from mail sent to their maintainer addresses; and as missing (or over-committed) maintainers are a constant issue in an org as large as Debian, making sure information reaches the BTS makes it possible for a future maintainer to pick up the pieces more readily. To me though - and i will stress this highly - I don't think that it's a fact that ubuntu isnt contributing to debian - because it is. But I believe that some people (maybe a lot of people) for whatever issue aren't willing to work either way - as Ubuntu can't do all the work - and nor can debian - but - when one side isnt willing to work (I'm not on about projects as a whole - I'm on about individual people/maintainers) then it spoils the whole thing. FWIW, here's what I see in practice. We have Ubuntu saying that they give back to Debian; and then we have a fairly large divergence between what Debian has in unstable and what's going into the next Ubuntu release, with IME very little patch submission to the Debian BTS, plus particular individuals who are working diligently to make sure their own Ubuntu changes get integrated effectively into Debian. I haven't seen anything systematic that supports the giving back to Debian assertion, and I think a lot of this has to do with Ubuntu's development structures ensuring that re-merging with Debian is an afterthought, *not* the primary development modality encouraged by the leadership. Now, it may be that this is an unrealistic pipe dream on my part that's incompatible with Ubuntu's goals/release schedule, but it seems to me that everyone involved would get more mileage out of the giving-back process if there were more emphasis on trying to get changes made in sid *before* changing things in universe, wherever possible. I realize there are some practical issues on the Debian side that would need to be addressed to make this a reality, and I know there are plenty of cases when Ubuntu won't be able to wait for Debian before making particular changes, but I think it would greatly mitigate the concerns over divergence if people viewed universe as less of a sandbox for innovation than they seem to today. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Canonical's business model
On Thu, Jan 12, 2006 at 09:03:24PM -0200, Gustavo Noronha Silva wrote: Having said that, I'd also like to have non-ubuntu-specific patches be fed to our BTS; that would really make me feel there's a strong policy of giving back. While my relationship with people at ubuntu working on gksu is quite good, I still have to look for patches manually sometimes, like David Nusinow mentioned, and I have found patches that improved debian's gksu this way at least twice. It would have been much better to have them filed to the BTS. See ya, Hi Gustavo, would it be good for ubuntu to have a user-defined tag, like the BTS has, for 'ubuntu-specific' or conversly 'non-ubuntu-specific'? cheers, Kev -- counter.li.org #238656 -- goto counter.li.org and be counted! `$' $' $ $ _ ,d$$$g$ ,d$$$b. $,d$$$b`$' g$b $,d$$b ,$P' `$ ,$P' `Y$ $$' `$ $ ' `$ $$' `$ $$ $ $$g$ $ $ $ ,$P $ $$ `$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$ `Y$$P'$. `YP $$$P' ,$. `Y$$P'$ $. ,$. signature.asc Description: Digital signature
Re: Development standards for unstable
Jeroen van Wolffelaar [EMAIL PROTECTED] wrote: That said, I do believe that if a package is unpopular enough that nobody picks up maintaining it, even while it's orphaned, what the prospects of the package are, and how much use it has to prolong its life extraordinary. If you're sufficiently committed to a certain package, you can just as well adopt it after all. Hm, well, no. I do particularly care for one orphaned package, lmodern. But since it currently doesn't have any (real) RC bugs, I have more important things to do than adopt it on behalf of the debian-tetex-maint list (or talking Norbert Preining into creating it from his texlive sources). If any work is really badly needed, someone of us will for sure step in; but that doesn't mean that we're happy to have the additional burden. I'd rather have it marked as orphaned, so that a new maintainer candidate can clearly see that it needs care, than formally adopt it while we can in fact only care for RC bugs[1]. Therefore I don't think that merely being orphaned is a good criterion for removal; especially not until we make sure that all unmaintained or badly maintained packages are in fact orphaned. Regards, Frank [1] and the important one, which might turn out to be RC -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Debian Games Team
--- Eddy Petriºor [EMAIL PROTECTED] escribió: Can ome packaging can be done for non-free games? (I am thinking about a wrapper over the pristine installers/data/ to make the games installable through apt-get). To be honest, I'm not particulary interested in non-free software at all, including games, but I have nothing against it if we decide as a group to do so. In my oppinion there's so much work to do about free games that I don't think it's a good idea giving away our time to non-free projects. Of course, there's the usual balance to consider between freeness and users-friendliness, but, as it has happened to other kinds of programs in more critical areas, I think it might better to concentrate in improving free games than in packaging non-free stuff, and in the long term it might give better results. Greetings, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#347849: ITP: easychem -- Draw high-quality molecules and chemical 2D formulas
Chris Peterman [EMAIL PROTECTED] wrote: Package: wnpp Severity: wishlist * Package name: easychem Version : 0.6 Upstream Author : Francois-Xavier Coudert [EMAIL PROTECTED] * URL or Web page : http://easychem.sourceforge.net * License : GPL Description : Draw high-quality molecules and chemical 2D formulas You should think of a decent long description; the Why using EasyChem on the website seems to be a good start. And indicates that the package seems to be misnomed using the adjective Easy, maybe PowerChem would be better... , | The only tool able to draw press-quality molecules was... xfig, [...] | To solve this problem [...], I decided to develop my own software: | EasyChem. | | The problem I see in all existing programs is: they intend to be easy | to use at first try, kind of a quick-and-dirty approach. EasyChem | would be a bit difficult to learn, but when you master it, you can be | very fast, and with a huge precision. ` Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: initramfs-tools backport?
Am Donnerstag, 12. Januar 2006 23:31 schrieb Norbert Tretkowski: It was just uploaded. Great! Thanks! regards, Jörg -- Dipl.-Ing. Jörg Platte Institut für Roboterforschung - Abteilung Informationstechnik Universitaet Dortmund | phone: +49 231-755-6165 Otto-Hahn-Str. 4 (P1-01-116) | mobile: +49 178-2978865 44221 Dortmund, Germany | fax:+49 231-755-3251 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Development standards for unstable
Frank Küster wrote: Hm, well, no. I do particularly care for one orphaned package, lmodern. But since it currently doesn't have any (real) RC bugs, I have more important things to do than adopt it on behalf of the debian-tetex-maint list (or talking Norbert Preining into creating it from his texlive sources). If any work is really badly needed, someone of us will for sure step in; but that doesn't mean that we're happy to have the additional burden. I'd rather have it marked as orphaned, so that a new maintainer candidate can clearly see that it needs care, than formally adopt it while we can in fact only care for RC bugs[1]. Well, maybe the actual situation would be better reflected if one of the interested parties adopted the package and retitled the O bug to RFA? Therefore I don't think that merely being orphaned is a good criterion for removal; especially not until we make sure that all unmaintained or badly maintained packages are in fact orphaned. Can you elaborate on this? I'm not sure how the existence of more packages that should be orphaned invalidates dealing with those that presently are. There's 169 orphaned packages today, why not do something about them? Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Games Team
On 13-Jan-2006, Miriam Ruiz wrote: --- Eddy Petriºor [EMAIL PROTECTED] escribió: Can ome packaging can be done for non-free games? To be honest, I'm not particulary interested in non-free software at all, including games, but I have nothing against it if we decide as a group to do so. In my oppinion there's so much work to do about free games that I don't think it's a good idea giving away our time to non-free projects. Seconded. This Debian user would be much better pleased by Debian's efforts going to improving the packaging and coordination of free software games. -- \I took it easy today. I just pretty much layed around in my | `\ underwear all day. ... Got kicked out of quite a few places, | _o__) though. -- Bug-Eyed Earl, _Red Meat_ | Ben Finney [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Development standards for unstable
Thomas Viehmann [EMAIL PROTECTED] wrote: Well, maybe the actual situation would be better reflected if one of the interested parties adopted the package and retitled the O bug to RFA? Sounds right... Therefore I don't think that merely being orphaned is a good criterion for removal; especially not until we make sure that all unmaintained or badly maintained packages are in fact orphaned. Can you elaborate on this? I'm not sure how the existence of more packages that should be orphaned invalidates dealing with those that presently are. There's 169 orphaned packages today, why not do something about them? What I meant is that we would start removing moderately buggy, well usable packages (just because they are orphaned), but keep badly buggy, unmaintained packages with lots of annoying bugs - just because nobody has orphaned them, or because the maintainer only shows up to tell people to keep their fingers off the package. When browsing the BTS for a particular question, I frequently run into packages where I think this looks like unmaintained. But often I don't have time to check whether this is really true. I assume others experience the same, and therefore you can't expect every problematic package to be discussed with care and actually orphaned if found unmaintained. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Bug#347880: ITP: r-cran-eco -- GNU R routines for Bayesian ecological inference
Package: wnpp Severity: wishlist Owner: Chris Lawrence [EMAIL PROTECTED] * Package name: r-cran-eco Version : 2.2-1 Upstream Author : Kosuke Imai and Ying Lu * URL : http://imai.princeton.edu/research/eco.html * License : GPL Description : GNU R routines for Bayesian ecological inference This is a set of routines for GNU R that implement Imai and Lu's parametric and nonparametric Bayesian ecological inference algorithms using Markov chain Monte Carlo estimation. Ecological inference is a statistical technique designed to recover individual-level information from aggregate-level data. . The suggested r-cran-mcmcpack package includes other EI estimators that may be useful alternatives to those included in this package. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-rc5 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Games Team
Ben Finney wrote: On 13-Jan-2006, Miriam Ruiz wrote: --- Eddy Petriºor [EMAIL PROTECTED] escribió: Can ome packaging can be done for non-free games? To be honest, I'm not particulary interested in non-free software at all, including games, but I have nothing against it if we decide as a group to do so. In my oppinion there's so much work to do about free games that I don't think it's a good idea giving away our time to non-free projects. Seconded. This Debian user would be much better pleased by Debian's efforts going to improving the packaging and coordination of free software games. Thirded :D lol - I'd love to participate in this - but more on the side of game utilities like aabrowse :D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
Le jeudi 12 janvier 2006 à 21:12 +0400, Stepan Golosunov a écrit : Looking at them, I fail to see why debconf-i18n has to depend on debconf. Because /usr/share/doc/debconf-i18n is a symlink? Then this is something that can easily be fixed. Not as easily as with the classical foo - foo-data dependency, as debconf-english has the same symlink, but it's possible to keep these directories in the package. Gaining a few kilobytes on the hard disk to have the changelog in another package, at the cost of a circular dependency, is too expensive IMHO. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Need for launchpad
Steve Langasek wrote: FWIW, here's what I see in practice. We have Ubuntu saying that they give back to Debian; and then we have a fairly large divergence between what Debian has in unstable and what's going into the next Ubuntu release, with IME very little patch submission to the Debian BTS, plus particular individuals who are working diligently to make sure their own Ubuntu changes get integrated effectively into Debian. I don't think that patches-submitted-to-the-BTS is a good way to measure how much Ubuntu is contributing to Debian. Ubuntu's patches are readily available: http://people.ubuntulinux.org/~scott/patches/ If they were submitted to the BTS then that would just create more work for the Debian maintainer as well as for the Ubuntu maintainer, since the former would have to tag the report and ensure it gets closed on the next upload, etc. Yes, it might be more helpful than the current breakdown of patches into changelog and packaging components if there was a further breakdown into parts suitable for Debian and parts not suitable for Debian. However, to perform this breakdown would be for Ubuntu developers to make judgments about what is suitable for Debian, and I am sure that such judgments would provoke negative reactions from Debian developers. So I think that it is up to Debian maintainers to review the Ubuntu patches from time to time and to backport what appears to be suitable for Debian. I agree that it would be nice if Ubuntu developers tried to get their changes into sid. It is certainly not their responsibility to do so, but in my experience Ubuntu developers have been very cooperative when they have been approached. So I don't see a big problem. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Games Team
On 1/13/06, Ben Finney [EMAIL PROTECTED] wrote: Can ome packaging can be done for non-free games? Seconded. This Debian user would be much better pleased by Debian's efforts going to improving the packaging and coordination of free software games. I agree that free software is the priority, but I don't feel that packaging efforts would be wasted. In any case some experience is gathered and supporting games like Unreal Tournament, NWN, is not that hard as they release more rarely than free ones, imho. PS: I would love to have more free games like quake, but let's face it, games still are majorly non-free land (I felt this the most when I changed primary arch to ppc). -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Bug#347895: ITP: cnet -- A X11 TclTK based network simulator program
Package: wnpp Severity: wishlist Owner: Jesús Espino [EMAIL PROTECTED] * Package name: cnet Version : 2.0.9 Upstream Author : Chris McDonald [EMAIL PROTECTED] * URL : http://www.csse.uwa.edu.au/cnet/ * License : GPL Description : A X11 TclTK based network simulator program Cnet allows you to simulate data link layer network protocols, by programming it in C language. Also, you specify the topology of the simulated network. . Cnet compiles your source and dinamically links it, and the simulation begins. It is a graphical program, so you can view your simulated packets travelling on your virtual network. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-luc3m Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Re: Trivial bug on apt-file (Was : Re: Development standards for unstable)
On Fri, 13 Jan 2006, Charles Plessy wrote: dependancy on curl. However, declaring proper dependancies for the package is a should, not a must, so if a debian developper is free to creating uninstallable packages if he fancies this. Disclaimer: I am not talking about apt-file. QA hat on I sure hope no DDs have such sloppy standards for their work that they would upload such crap to unstable knowlingly. Note that transitory dependency problems are not what we are talking about. /QA hat on If you are going to violate a _should_ forever, you better be able to provide a full, acceptable technical explanation for your reasons. And for the sake of team work, that also means tagging a bug about the issue as wontfix, and adding the explanation to the bug logs. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dissection of an Ubuntu PR message
On 1/13/06, Andrew Suffield [EMAIL PROTECTED] wrote: On Thu, Jan 12, 2006 at 06:08:52PM -0200, Gustavo Franco wrote: We can't decide how they need to give us something MORE back and it's their problem? Whoever said they need to do that? They just need to stop bragging about shit they don't do. There's at least two ways to accomplish this. If they fail to contribute in a meaningful way, it just means more work for them (in trying to maintain a diverging fork). Hence, that's their problem. It's not really a problem for us. We can't say that Canonical/Ubuntu isn't contributing back. They're, as pointed out by some of us. e.g.: David said that Daniel helped him, but if he did that in his workhours it's under Canonical bless. It seems that the main problem is how they're handling the list of patches. If they want to spread the word that they're contributing, it seems that many of us want to be informed about the patches as we inform upstreams and not as it's today. I can't affirm if they're saying more than they're doing, but we are for sure. I was the only trying to prepare a list of things that we can ask them to change, and mdz (Ubuntu/Debian) tried to collect feedback too. We want cooperation, it seems that they want too but Debian by nature is a complicated project and Ubuntu will never satisfy all our needs, even for just handling and reporting back some patches. With that in mind, it would be good to hear about some internal discussion in Ubuntu camp too, maybe in the next online meeting or in London. It will proof that they want to be something different than a simple fork, as described by mako[0]. [0] = http://mako.cc/writing/to_fork_or_not_to_fork.html (long) -- Gustavo Franco
Re: Preparing the m68k port for the future.
Hi, On Fri, Jan 13, 2006 at 01:21:18PM +1000, Anthony Towns wrote: On Thu, Jan 12, 2006 at 07:17:48PM +0100, Wouter Verhelst wrote: Yes, 'm68k' and 'future' in one sentence. Amazing, isn't it? Surely we must be joking? Hey, I haven't seen any activity wrt m68k archive (re)qualificiation. You haven't been looking good enough, then. Given m68k's dropped back below the 95% cutoff (and has spent about 1/3rd of the last 90 days beneath it) and has a number of red squares still on the release arch qualification page it seems certain at this point that you won't get a release arch exception any time soon. That's being worked on. The backlog started because there were not enough build daemons to keep up with the extra work introduced by the move to GCC4. This has been remedied in the mean time, and we're back to 0 needs-build on a regular basis. Also, the extra CPU power that this new port will bring us is most certainly going to improve our position in that area. The fact that we're not completely caught up yet has everything to with a number of toolchain issues that need work. I'm trying to tackle them one at a time; currently I'm working on #340563 (which was cloned into #345574 for g++-4.0), and on which I intend to look a bit further sometime during next week or so. It doesn't help that I'm not all that familiar with the innards of the gcc and binutils code yet, but then I expect that by doing more work on such bugs and by doing work on the coldfire-support will help me to improve in that area. Your concern is grounded, though, and I'm not entirely confident at this point that we'll be able to make it, either--help in this area is most certainly appreciated. Anyway. To cope with the above issues, the m68k port's developers have been looking for alternatives for quite a while now. It has been suggested that we start employing distcc or similar things so that we would be able to use cross-compilers on much faster hardware, but for various reasons this is not practical. BTW, it's not very encouraging when you say Yes, we'll definitely try this and see how it works! then, six months later, fail to have ever bothered, and can only handwave it away as being impractical. No, I did try it. I did, however, neglect to bring out the results in the open. Mea culpa. Here goes: When I first tried to create this setup, about a month after DebConf5 (and about around the time when I announced this), it turned out that it was plain impossible to build a cross-compiler with the GCC4 code; not with toolchain-source (because that had not been updated yet to GCC4, so would be useless for this purpose) but also not with the upstream source and the scripts from kegel.com: Some internals of the GCC4 code expected that the compiler and the binutils would be called 'm68k-linux-foo', whereas other bits expected 'm68k-linux-gnu-foo'. Obviously this could be fixed by someone familiar with the gcc/binutils build system, but that's besides the point; the point is that rolling our own, very special, setup might introduce extra weaknesses (I had warned in Helsinki about the possibility that a cross-compiler might not produce the very exact same object code that a native build would, but had not considered the possibility that there might be bugs in the build system which would only occur when trying to build cross-compilers). This would complicate such a setup further. Additionally, Ingo told me when the mail about that meeting had come out that he'd already tried such a setup in the past (I didn't know that when we were in Helsinki, but it was before that), and that his setup, IIRC, was in fact slower than a native build because of the overhead of the network call to start the compiler--At least that's how I recall his explanation. I don't remember the details; if you have any questions, please ask him. Now it might be that with faster hardware (I don't know the specifics of Ingo's setup; I seem to recall he mentioned a Pentium III-class system as the distcc host, but I might be delirious) the distcc stuff will indeed work better, but if such a setup with a not /that/ old system is already slower than a native build, then I'm not very hopeful that a distcc setup is going to get us much benefit, while it _will_ give us a huge overhead. -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing the m68k port for the future.
On Fri, Jan 13, 2006 at 02:09:19PM +0100, Wouter Verhelst wrote: Hi, On Fri, Jan 13, 2006 at 01:21:18PM +1000, Anthony Towns wrote: On Thu, Jan 12, 2006 at 07:17:48PM +0100, Wouter Verhelst wrote: Yes, 'm68k' and 'future' in one sentence. Amazing, isn't it? Surely we must be joking? Hey, I haven't seen any activity wrt m68k archive (re)qualificiation. You haven't been looking good enough, then. Given m68k's dropped back below the 95% cutoff (and has spent about 1/3rd of the last 90 days beneath it) and has a number of red squares still on the release arch qualification page it seems certain at this point that you won't get a release arch exception any time soon. That's being worked on. The backlog started because there were not enough build daemons to keep up with the extra work introduced by the move to GCC4. This has been remedied in the mean time, and we're back to 0 needs-build on a regular basis. Also, the extra CPU power that this new port will bring us is For clarity: s/this new port/the support for the ColdFire/ [...] -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347907: ITP: libobject-signature-perl -- Signature - Generate cryptographic signatures for objects
Package: wnpp Severity: wishlist Owner: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] * Package name: libobject-signature-perl Version : 1.03 Upstream Author : Adam Kennedy [EMAIL PROTECTED] * URL : http://mirrors.kernel.org/cpan/modules/by-module/Object/Object-Signature-1.03.tar.gz * License : Perl: Artistic/GPL Description : Signature - Generate cryptographic signatures for objects Object::Signature is an abstract base class that you can inherit from in order to allow your objects to generate unique cryptographic signatures. . The method used to generate the signature is based on Storable and Digest::MD5. The object is fed to Storable::nfreeze to get a string, which is then passed to Digest::MD5::md5_hex to get a unique 32 character hexidecimal signature. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Thomas Hood writes: If they were submitted to the BTS then that would just create more work for the Debian maintainer as well as for the Ubuntu maintainer, since the former would have to tag the report and ensure it gets closed on the next upload, etc. That's exactly how I want to handle my packages. If I ever get around to looking at the Ubuntu stuff and find anything relevant (I don't know if they use any of my packages) I'll just put them in the BTS myself anyway. However, to perform this breakdown would be for Ubuntu developers to make judgments about what is suitable for Debian, and I am sure that such judgments would provoke negative reactions from Debian developers. Why? Don't we expect users to decide which of their local changes are suitable for Debian? I sometimes make local changes to Debian packages. Sometimes I send patches to the BTS and sometimes I decide that the change is only relevant to my local situation. Should I instead put them all up on a Web site and expect the maintainers to sort through them? I think of Ubuntu as just another (large) user. If they don't feel like filing bugs that's fine: it costs me nothing for them to use my work (if they indeed do). However, I can't see how putting up patches on a Web site is better than (or even as good as) filing bug reports. So I think that it is up to Debian maintainers to review the Ubuntu patches from time to time and to backport what appears to be suitable for Debian. Again, why should Ubuntu's patches be handled any differently than those of other users? I agree that it would be nice if Ubuntu developers tried to get their changes into sid. It is certainly not their responsibility to do so, but in my experience Ubuntu developers have been very cooperative when they have been approached. So I don't see a big problem. I don't either. After all, most users don't file bug reports, and Ubuntu is (in my view), a user. It would be nice to have their feedback since it is likely to be useful and of high quality, but we can live without it. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing the m68k port for the future.
On Fri, Jan 13, 2006 at 02:09:19PM +0100, Wouter Verhelst wrote: Additionally, Ingo told me when the mail about that meeting had come out that he'd already tried such a setup in the past (I didn't know that when we were in Helsinki, but it was before that), and that his setup, IIRC, was in fact slower than a native build because of the overhead of the network call to start the compiler--At least that's how I recall his explanation. I don't remember the details; if you have any questions, please ask him. Uhm, well, yes, I tried a distcc setup on m68k. Actually it's the opposite: Of course there's a overhead via network (I was using two m68ks with 450 km and 2 DSL dialups inbetween), but the test (kernel compile) showed approx. a total of 40-50% gain in build time. M68ks (well, Amigas at least) only have 10 Mbps NICs, so you won't have much faster transfers than 300-500 kB/s between hosts anyway. The m68k distcc worked quite well, but when I tried to setup a cross-distcc it failed on the crosscc side. Somehow the generation of the need cross files failed. Can't remember the specifics anymore. Now it might be that with faster hardware (I don't know the specifics of Ingo's setup; I seem to recall he mentioned a Pentium III-class system It was a PowerPC G4 1 GHz. ;) as the distcc host, but I might be delirious) the distcc stuff will indeed work better, but if such a setup with a not /that/ old system is already slower than a native build, then I'm not very hopeful that a distcc setup is going to get us much benefit, while it _will_ give us a huge overhead. I think, distcc will be nice for such things like qt-x11 and other long building stuff. For packages with shorter build times (1 hour or so) I don't see much gain, because the installation and removal of build-deps will take the most time and distcc certainly can't help there. ;) The benefit of distcc would be, that we can add flawlessly more CPU power whenever needed, but don't need to when there's no backlog, so we can build natively. The main showblocker with that is that package building doesn't support make -jX yet. I think other archs with SMP support might benefit as well when there would be a way to support this feature... -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij/public_key.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing the m68k port for the future.
On Fri, Jan 13, 2006 at 02:38:02PM +0100, Ingo Juergensmann wrote: On Fri, Jan 13, 2006 at 02:09:19PM +0100, Wouter Verhelst wrote: Additionally, Ingo told me when the mail about that meeting had come out that he'd already tried such a setup in the past (I didn't know that when we were in Helsinki, but it was before that), and that his setup, IIRC, was in fact slower than a native build because of the overhead of the network call to start the compiler--At least that's how I recall his explanation. I don't remember the details; if you have any questions, please ask him. Uhm, well, yes, I tried a distcc setup on m68k. Actually it's the opposite: Of course there's a overhead via network (I was using two m68ks with 450 km and 2 DSL dialups inbetween), but the test (kernel compile) showed approx. a total of 40-50% gain in build time. [...] Ah. Hmm. Well, then I must have misremembered somehow. Sorry about that. That would indeed change a few things, of course. But, still, I do think that the ability to start using hardware that is 4-8 times the speed of what we currently have is a better way to improve the average speed of our build daemons than to start using complex setups such as distcc. If that turns out to not be enough, we can still try distcc then. -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Friday 13 January 2006 12:04, Thomas Hood wrote: I agree that it would be nice if Ubuntu developers tried to get their changes into sid. It is certainly not their responsibility to do so, It isn't? Presumably they're that ones that want to remain close to Debian (as any divergence means more work for them?)? So how is it the Debian maintainers responsibility to go hunting for usefull patches? Debian maintainers for the most part would love to not have to duplicate work already done by Ubuntu. But at the moment I've seen lots of comments by maintainers saying that in most cases it's currently more work to find out if there's any usefull bits in the diffs between debian-ubuntu packages, then to do the work themselves (for various reasons, which have been mentioned before) but in my experience Ubuntu developers have been very cooperative when they have been approached. So I don't see a big problem. Ah, here we come to the heart of the problem: when they have been approached, this clearly points to the fact that the initiative for synchronization between ubuntu and debian lies with Debian not Ubuntu (by and large, some exceptions have been mentioned). In the mean while Ubuntu proudly calls ubuntu gives things back, whereas in reality we mostly have a situation of ubuntu will help debian maintainers that want to take things back - It's this misrepresentation of where (most of) the initiative lies which pisses people off. -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgp0THzWMuhMm.pgp Description: PGP signature
Re: Preparing the m68k port for the future.
On Fri, 13 Jan 2006, Ingo Juergensmann wrote:
On Fri, Jan 13, 2006 at 02:09:19PM +0100, Wouter Verhelst wrote:
The main showblocker with that is that package building doesn't support make
-jX yet. I think other archs with SMP support might benefit as well when
there would be a way to support this feature...
Enabling `-j' will probably expose concurrency problems in the build system for
lots of packages.
What about building different packages in parallel instead?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Games Team
I also would be interested in getting involved in this project. I believe there is much room to grow in the area of gaming, and since I am an avid gamer myself using both Free and Non-Free games on my Debian systems I would love to help out where I can. Regards, Brian PowellOn 1/13/06, Miriam Ruiz [EMAIL PROTECTED] wrote: Hi,We've been recently talking about creating a group to maintain games in Debianin a collaborative way. As a starting point, I've created a mailing list inalioth for coordination, and also for create discussion threads about the main problems related to game development and games packages in Debian. You canjoin that list at:http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel Here are some points that might be addressed by this group if there isinterested in it:- Maintaining games collaboratively, as they tend to share many points incommon.- Scale economy benefits: maintaining more packages, quicker an with less effort.- Open a way towards a larger involvement in Debian project to peoplemaintaining just one or few games.- Quick-fixing of security issues common to games.- Discussion of problems and facts relative to game packaging. - Discussion of how to DFGS might be interpreted regarding multimedia contentsand artwork in games.- Identify important games that are not packaged yet and package them.- Identify games that we were only maintainig out of inertia, and consider dropping them- Make it easier for users to know the games available in Debian, maybe withsome game selector interface, a web page, screenshots or whatever.You're welcome to join the group, or say whatever you think about this project.Greetings,Miry__LLama Gratis a cualquier PC del Mundo.Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com--To UNSUBSCRIBE, email to [EMAIL PROTECTED]with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]-- Regards,Brian Powell-= Debian GNU/Linux =-http://debian.org
Re: Anthony Towns: What I did today
Hi AJ, On Friday, 13 Jan 2006, you wrote: Things I did today: 2. Removed the empty SuperH architecture from the archive (binary-sh). Coincidence? You decide. URL: http://azure.humbug.org.au/~aj/blog/2006/01/13#2006-01-13-sh-irts Nice you have done this, but Planet is definitely not the correct place to document changes like this. I would find it more appropriate to inform fellow DDs either via debian-devel@ or [EMAIL PROTECTED] Not all developers read planet.debian.org. To get that clear, i don't want to criticize you removed unneeded SuperH architecture from the archive, but where you document changes like this. Greetings Martin PS: CC'ed -devel to get fellow developers informed about your changes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libecw
Scripsit Miriam Ruiz [EMAIL PROTECTED] I'm not sure if it's license ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293346 ) can be considered free enough to be in main: [...] ii) When modifications to the Software are released under this license, a non-exclusive royalty-free right is granted to the initial developer of the Software to distribute your modification in future versions of the Software provided such versions remain available under these terms in addition to any other license(s) of the initial developer. This is controversial at best. iii) You are not permitted to change the ECW file format. This, however, directly kills DFSG-freedom as well as GPL compatibility. If the library is actually linked with GPL code, as the authors seem to expect, the entire think becomes legally undistributable even in non-free. -- Henning Makholm Hi! I'm an Ellen Jamesian. Do you know what an Ellen Jamesian is? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
John Hasler wrote: I can't see how putting up patches on a Web site is better than (or even as good as) filing bug reports. The web site requires less labor to maintain than hundreds of bug reports. Again, why should Ubuntu's patches be handled any differently than those of other users? In short: because Ubuntu isn't just another user, but a whole distribution. cobaco wrote: So how is it the Debian maintainers responsibility to go hunting for usefull patches? I did not say that it is a DD's responsibility to go hunting for patches. As is well known, Debian developers don't have responsibilities (Constitution article 2.1). However, if a particular Debian Developer feels motivated to improve his package then he'd be well advised to examine what Ubuntu has done to it. Transfer of information requires two parties: a provider and a recipient. Ubuntu, the provider, has published its changes. The transfer can only be completed when the receiver is ready to receive, but this is not always the condition of Debian maintainers. So it is efficient if the transfer take place on the initiative of the latter. Once he or she is ready, he or she doesn't have to hunt, because the patches are all at a known location. http://people.ubuntulinux.org/~scott/patches/ Ah, here we come to the heart of the problem: when they have been approached, this clearly points to the fact that the initiative for synchronization between ubuntu and debian lies with Debian not Ubuntu (by and large, some exceptions have been mentioned). Right. In the mean while Ubuntu proudly calls ubuntu gives things back, whereas in reality we mostly have a situation of ubuntu will help debian maintainers that want to take things back I don't see a profound difference between helping to take and giving. Perhaps what you want is giving on a silver platter? - It's this misrepresentation of where (most of) the initiative lies which pisses people off. I think that people are pissed off for other reasons. (But I admit that I can only speculate. I can't read people's hearts and minds.) Suppose Ubuntu were to cease claiming[0] that it gives back to Debian. Would everyone be happy then? I doubt it. [0] Here: http://ubuntu.com/ubuntu/relationship?highlight=%28debian%29 there's a claim that they send their bugfixes to the Debian developers responsible for that package in debian and record the patch URL in the debian bug system. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
Adrian von Bidder [EMAIL PROTECTED] writes: From a graph algorithm point of view, if I'm not very mistaken, dependencies being guaranteed to be a directed graph instead of a generic graph should allow some simplifications/efficiency improvements in apt and other tools, too. For the record, dependencies are a directed graph by nature. Preventing circular dependencies will get you a directed acyclic graph (DAG) which is, IMHO, easier to handle. HTH -- Dominique Dumont Delivering successful solutions requires giving people what they need, not what they want. Kurt Bittner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dissection of an Ubuntu PR message
On Fri, Jan 13, 2006 at 10:45:48AM -0200, Gustavo Franco wrote: We can't say that Canonical/Ubuntu isn't contributing back. They're, as pointed out by some of us. e.g.: David said that Daniel helped him, but if he did that in his workhours it's under Canonical bless. Please stop trying to twist my words around. Canonical didn't contribute back. An individual who happened to work for Canonical did. If someone employed by the US government contributes to Debian of his own volition do we say that the US government gives back to Debian? Do we say that your employer gives back to Debian? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Friday 13 January 2006 16:27, Thomas Hood wrote: John Hasler wrote: I can't see how putting up patches on a Web site is better than (or even as good as) filing bug reports. The web site requires less labor to maintain than hundreds of bug reports. for Ubuntu that's true, for the Debian maintainer it's not However, if a particular Debian Developer feels motivated to improve his package then he'd be well advised to examine what Ubuntu has done to it. I've seen comments from maintainers that tried this and stopped doing so because it turned out to be more work then (re)doing things themself. The number of such comments I've come acrosss would lead me to believe that at the very least the ubuntu patch publishing needs (significant) work to be usefull in the majority of cases. So at the moment I'd say the above statement is false. Transfer of information requires two parties: a provider and a recipient. Ubuntu, the provider, has published its changes. The transfer can only be completed when the receiver is ready to receive, but this is not always the condition of Debian maintainers. So it is efficient if the transfer take place on the initiative of the latter. Once he or she is ready, he or she doesn't have to hunt, because the patches are all at a known location. as documented experience by maintainers who've tried that shows, this is inefficient enough that reimplementing is mostly faster (and definately more attractive, as it involves less drudgework) - ubuntu needs to improve efficiency _for_debian_maintainers_ if it wants them to use their patches (if it doesn't that's fine, though not ideal, from a Debian perspective) Ah, here we come to the heart of the problem: when they have been approached, this clearly points to the fact that the initiative for synchronization between ubuntu and debian lies with Debian not Ubuntu (by and large, some exceptions have been mentioned). Right. In the mean while Ubuntu proudly calls ubuntu gives things back, whereas in reality we mostly have a situation of ubuntu will help debian maintainers that want to take things back I don't see a profound difference between helping to take and giving. Perhaps what you want is giving on a silver platter? the difference is the one between push and pull, i.e. were the initiative lies. And Ubuntu is claiming it's pushing things where it's not. - Ubuntu not pushing things is just ducky in itself. - Ubuntu doing so while sayingthey are is _not_ okay (and that's the impression a lot DD's seem to have right now) - It's this misrepresentation of where (most of) the initiative lies which pisses people off. I think that people are pissed off for other reasons. (But I admit that I can only speculate. I can't read people's hearts and minds.) Suppose Ubuntu were to cease claiming[0] that it gives back to Debian. Would everyone be happy then? I'm pretty sure people would be happier with one of the following: - Ubuntu actually doing what it's claiming (i.e. pushing changes to debian) - Ubuntu stop the claiming take your pick. -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpevJbtDV4zh.pgp Description: PGP signature
Re: Debian Games Team
On Fri, 2006-01-13 at 09:15 +0100, Andreas Tille wrote: On Fri, 13 Jan 2006, Miriam Ruiz wrote: We've been recently talking about creating a group to maintain games in Debian in a collaborative way. Are you aware of the Debian-Junior project. Thanks for bringing this thread to my attention, Andreas, or I would have missed it. Miriam, I'm interested in your project and am joining the list to contribute ideas relating to Debian Jr. Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trivial bug on apt-file (Was : Re: Development standards for unstable)
On Fri, Jan 13, 2006 at 10:39:01AM -0200, Henrique de Moraes Holschuh wrote: On Fri, 13 Jan 2006, Charles Plessy wrote: dependancy on curl. However, declaring proper dependancies for the package is a should, not a must, so if a debian developper is free to creating uninstallable packages if he fancies this. Err, what? The RC issues for etch thing lists: Packages must include a Depends: line listing any other packages they require for operation, unless those packages are marked Essential: yes. Packages must include a Pre-Depends: line listing any packages required by their preinst. so violating that is definitely RC. 3.5 of policy uses must, not should. In apt-file's case, the maintainer is claiming the current dependencies are correct, aiui. If you are going to violate a _should_ forever, you better be able to provide a full, acceptable technical explanation for your reasons. And for the sake of team work, that also means tagging a bug about the issue as wontfix, and adding the explanation to the bug logs. Yes, this RC bug fetish is absurd; we should be spending our time on these shoulds, because the musts are already fixed... :-/ Cheers, aj signature.asc Description: Digital signature
Re: Preparing the m68k port for the future.
On Fri, Jan 13, 2006 at 02:09:19PM +0100, Wouter Verhelst wrote: On Fri, Jan 13, 2006 at 01:21:18PM +1000, Anthony Towns wrote: On Thu, Jan 12, 2006 at 07:17:48PM +0100, Wouter Verhelst wrote: Yes, 'm68k' and 'future' in one sentence. Amazing, isn't it? Surely we must be joking? Hey, I haven't seen any activity wrt m68k archive (re)qualificiation. You haven't been looking good enough, then. Put it in the wiki along with everyone else where it's obvious. Given m68k's dropped back below the 95% cutoff (and has spent about 1/3rd of the last 90 days beneath it) and has a number of red squares still on the release arch qualification page it seems certain at this point that you won't get a release arch exception any time soon. That's being worked on. That's fine, but it's irrelevant -- you need to be able to demonstrate you can keep up consistently for at least a three month period; at the moment you seem to be at least four months away from that, given how long it seems to take m68k to catch back up. That's fine, and there's no reason why m68k can't demonstrate that Debian can effectively maintain a toy or embedded or whathaveyou port that's *not* intended to release. But it does mean you've got no chance of a release requalification anytime soon, which means you need to be proactive about getting an archive qualification done. Cheers, aj signature.asc Description: Digital signature
Re: Anthony Towns: What I did today
On Fri, Jan 13, 2006 at 04:22:50PM +0100, Martin Zobel-Helas wrote: On Friday, 13 Jan 2006, you wrote: Things I did today: 2. Removed the empty SuperH architecture from the archive (binary-sh). Coincidence? You decide. URL: http://azure.humbug.org.au/~aj/blog/2006/01/13#2006-01-13-sh-irts Nice you have done this, but Planet is definitely not the correct place to document changes like this. I would find it more appropriate to inform fellow DDs either via debian-devel@ or [EMAIL PROTECTED] Not all developers read planet.debian.org. I think you'll find the correct place is the -sh list, which was notified: http://lists.debian.org/debian-superh/2002/04/msg00010.html The sh arch in unstable has consisted of Architecture: all packages only since then. HTH, HAND. Cheers, aj signature.asc Description: Digital signature
Re: Dissection of an Ubuntu PR message
David Nusinow [EMAIL PROTECTED] wrote: Please stop trying to twist my words around. Canonical didn't contribute back. An individual who happened to work for Canonical did. If someone employed by the US government contributes to Debian of his own volition do we say that the US government gives back to Debian? Do we say that your employer gives back to Debian? If it's an authorised use of company time, sure. Whether or not it is in this case, I don't know. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
... Suppose Ubuntu were to cease claiming[0] that it gives back to Debian. Would everyone be happy then? I doubt it. Is your goal to make everybody happy or be truthful? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dissection of an Ubuntu PR message
On 1/13/06, Matthew Garrett [EMAIL PROTECTED] wrote: David Nusinow [EMAIL PROTECTED] wrote: Please stop trying to twist my words around. Canonical didn't contribute back. An individual who happened to work for Canonical did. If someone employed by the US government contributes to Debian of his own volition do we say that the US government gives back to Debian? Do we say that your employer gives back to Debian? If it's an authorised use of company time, sure. Whether or not it is in this case, I don't know. Exactly my point Matthew, and calm down David, i wrote: e.g.: David said that Daniel helped him, but if he did that in his workhours it's under Canonical bless.. Do you see ? I just pointed out that there's a possibility that he was helping you in his workhours, but i won't cite you as a reference anymore. -- Gustavo Franco
Re: packages.debian.org service stop ?
On Thursday, January 12, 2006 11:59 PM, Junichi Uekawa [EMAIL PROTECTED] wrote: Hi, I've dug out some information from IRC logs: saens was overloaded around 5 Jan 2006, with load average of 140 or something, and eventually apache stopped. Since saens is one of ftp.debian.org, it had a large impact, and packages.debian.org is disabled temporarily as a workaround. FWIW, the same information is detailed in http://lists.debian.org/debian-project/2006/01/msg00035.html. Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing the m68k port for the future.
On Sat, Jan 14, 2006 at 01:42:32AM +1000, Anthony Towns wrote: On Fri, Jan 13, 2006 at 02:09:19PM +0100, Wouter Verhelst wrote: On Fri, Jan 13, 2006 at 01:21:18PM +1000, Anthony Towns wrote: On Thu, Jan 12, 2006 at 07:17:48PM +0100, Wouter Verhelst wrote: Yes, 'm68k' and 'future' in one sentence. Amazing, isn't it? Surely we must be joking? Hey, I haven't seen any activity wrt m68k archive (re)qualificiation. You haven't been looking good enough, then. Put it in the wiki along with everyone else where it's obvious. Given m68k's dropped back below the 95% cutoff (and has spent about 1/3rd of the last 90 days beneath it) and has a number of red squares still on the release arch qualification page it seems certain at this point that you won't get a release arch exception any time soon. That's being worked on. That's fine, but it's irrelevant I beg to differ. -- you need to be able to demonstrate you can keep up consistently for at least a three month period; at the moment you seem to be at least four months away from that, given how long it seems to take m68k to catch back up. I can't make time go faster. All I can do is make sure the problems do not come back, which I am trying to do as far as is possible. That's fine, and there's no reason why m68k can't demonstrate that Debian can effectively maintain a toy or embedded or whathaveyou port that's *not* intended to release. I'm not sure I correctly parse that sentence. But it does mean you've got no chance of a release requalification anytime soon, which means you need to be proactive about getting an archive qualification done. The point of my previous mail was to demonstrate that I am, in fact, trying to be proactive about getting the qualification done. Of course, we all have real life that does get in the way from time to time. Don't you? -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mirror split stuff
On 1/13/06, Anthony Towns aj@azure.humbug.org.au wrote: Hey all, First, the executive summary for mirror operators reading this: we'll be switching the primary mirror stuff for Debian to be for a small number of architectures rather than all of them; initially this will just be i386, but will probably expand to include amd64. Single architecture mirrors appear to need about 60GB of disk space, dual architecture mirrors will need about 80GB of disk space. A full mirror at the moment requires slightly over 170GB. We'll be trying to get in touch with you all further over the next week or two to make sure the changes go as smoothly as possible. Second, there's a call for help down below. Particularly for people with some web programming skillz. Okay, so! You've probably heard about this mirror split thing, also known as scc, second class citizens, and the evil plot by the cabal to make poor blighted amd64 developers and users suffer unduly. At present, most mirrors mirror all the archive, and at present almost all Debian users that use those mirrors use i386 [0]. But with the archive growing almost daily (recently breaking the 170GB mark, up from 130GB in July iirc), and mirrors often finding it hard to keep up, that's a bad tradeoff. That tradeoff becomes even worse when we're unwilling to add interesting new architectures because of the immediate increase in archive size they cause, in addition to the ongoing accretion. So obviously that tradeoff's changing in favour of partial mirrors, particularly by architecture. People have been able to do partial mirrors for a while now, and the anonftpsync [1] tool we offer includes explicit support for that. In further support of partial mirrors, we'll be doing these things: (a) allowing and in some cases encouraging official mirrors to mirror a limited number of archictures (b) limiting ftp.debian.org to i386 only (probably to also include amd64, depending on how popular that architecture actually is) (c) providing simple recommendations on running arch-specific mirrors (d) providing cc.arch.mirror.debian.org aliases to make it easy for users to find a local mirror that supports their preferred architecture As well as allowing additional architectures, these changes should make it plausible to think about a few other things, notably including additional suites in the archive (such as volatile or backports), and having the archive pulse occur more frequently than daily. But one of the things all this stuff requires is some good communication with our mirrors. That can use some work at the moment, and one thing that would be particularly helpful is some better tracking of who's mirroring what. At present we have the Mirrors masterlist [2], the mirrors pseudopackage on the BTS [3] (and its corresponding mailing list, which has public archives on master [4]) and the Debian mirror checker [5]. What would be helpful would to improve our tracking stuff so that: (a) the mirror checker can provide more detailed information on mirror stability such as that offered by the apache tracker [6] (b) the mirror checker script can verify which architectures a mirror actually carries (c) there's some easy way for mirror admins to add, remove and update their details in the masterlist, rather than waiting for a developer to review the changes (with additions confirmed automatically by the checker, ideally) (d) there are status fields to indicate whether the mirror supports pushing downstream mirrors by ssh trigger, in the same manner as the top level Debian mirrors (e) what mirror each mirror mirrors from (ideally checked automatically by looking in project/trace; and ideally with a pretty graph generated from the data, highlighting mirrors that are out of date) (f) whether the mirror is able to accept *.mirror.debian.org requests, so that if, eg, at.alpha.mirror.debian.org goes down, it can automatically be pointed at another site in Austria, or if none are available, another nearby alpha mirror. But that's not really something I'm good at, and the existing folks working on organising the mirrors haven't had time to magic it up either, so if other folks would like to try their hand at whipping something up that can be made official that'd be great. Having it be something that can be run with minimal priveleges, not require PHP or a large framework, something that supports the existing Mirrors masterlist format for input and output, and be something that is written to run efficiently would be great. Naturally it needs to be free software. Followups on #debian-mirrors on
Re: Preparing the m68k port for the future.
On Fri, Jan 13, 2006 at 03:05:10PM +0100, Geert Uytterhoeven wrote: Enabling `-j' will probably expose concurrency problems in the build system for lots of packages. What about building different packages in parallel instead? Isn't that what is done currently? -- gram -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
On Friday 13 January 2006 16:53, you wrote: Adrian von Bidder [EMAIL PROTECTED] writes: From a graph algorithm point of view, if I'm not very mistaken, dependencies being guaranteed to be a directed graph instead of a generic graph should allow some simplifications/efficiency improvements in apt and other tools, too. For the record, dependencies are a directed graph by nature. Preventing circular dependencies will get you a directed acyclic graph (DAG) which is, IMHO, easier to handle. Arrgh. Of course, just a confusion of terms. cheers -- vbi -- F: Was ist ein Pensch? A: Das mittlere Stück von einem Lam-pensch-irm pgp7OK8BFipey.pgp Description: PGP signature
Re: Preparing the m68k port for the future.
On Fri, Jan 13, 2006 at 06:04:00PM +0100, Wouter Verhelst wrote: Given m68k's dropped back below the 95% cutoff (and has spent about 1/3rd of the last 90 days beneath it) and has a number of red squares still on the release arch qualification page it seems certain at this point that you won't get a release arch exception any time soon. That's being worked on. That's fine, but it's irrelevant I beg to differ. Huh? You can differ all you like, but that doesn't make it any more relevant. -- you need to be able to demonstrate you can keep up consistently for at least a three month period; at the moment you seem to be at least four months away from that, given how long it seems to take m68k to catch back up. I can't make time go faster. No, you can't. But in the meantime you need to demonstrate that m68k is actually worth keeping in the archive, otherwise it'll be replaced by amd64 which has qualified as a release candidate, and kfreebsd-i386 and any other architectures which are able to demonstrate their usefulness. I mean, come on, surely you can demonstrate you're more useful than Hurd and GNU/kfreebsd. Hurd hasn't even been able to compile vim for a year! These aren't exactly high bars... But it does mean you've got no chance of a release requalification anytime soon, which means you need to be proactive about getting an archive qualification done. The point of my previous mail was to demonstrate that I am, in fact, trying to be proactive about getting the qualification done. The way you demonstrate a commitment to getting archive qualification done is filling out a page on the wiki like: http://wiki.debian.org/ArchiveQualification/hurd-i386 http://wiki.debian.org/ArchiveQualification/kfreebsd-i386 Of course, we all have real life that does get in the way from time to time. Don't you? According to the release qualification page for m68k there are four other m68k port maintainers who could also be doing this. The fact you don't have anyone able to make a working cross-compiler speaks somewhat poorly of the support available for the m68k toolchain, too. Cheers, aj signature.asc Description: Digital signature
Re: Trivial bug on apt-file (Was : Re: Development standards for unstable)
Anthony Towns wrote: On Thu, Jan 12, 2006 at 06:48:38PM +0100, Luk Claes wrote: But if you read this bug (#307833), you'd see that the maintainer doesn't consider it a bug, and has documented why in the README file. It is a bug as the package is not usable without curl or wget installed. Though, I give him a chance to respond to my intention to NMU... An NMU is not the place to fix things that the maintainer has specifically said aren't bugs. Well the maintainer doesn't tag the bugs wontfix nor closes them all, so he probably thinks it *are* bugs that don't need immediate attention? You could of course disagree about whether it's a bug or not, but in that case, you would want to appeal to the tech-ctte, not debian-devel. ...before going to the Technical Committee. I'm sure Florian'll be giving you a serve for being so threatening any moment now... Sorry, I don't meant to threaten anyone, I was just saying that I first want to try all other means before I would consider going to the Technical Committee. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: French cheese
Quoting Matt Zimmerman ([EMAIL PROTECTED]): Unfortunately, this conflicts with a development sprint we're having in London, so that won't be possible at that time. My heart breaks at the prospect of a missed opportunity to gorge myself on cheese... Well, it's just a matter of jumping in the first Eurostar in the morning, be at Gare du Nord around 8 or 9, go to Solutions Linux, drink, talk and eat cheese all day long with fellow Debian and Ubuntu people, then jump in another Eurostar back to London (with some cheese in your luggage) and be back for hacking with your fellow Ubuntu people late in the night. And, for next year, just plan your development sprint in Paris..:-) (I'm half-serious and even really serious here) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Games Team
Miriam Ruiz wrote: Hi, Hi Miriam We've been recently talking about creating a group to maintain games in Debian in a collaborative way. As a starting point, I've created a mailing list in alioth for coordination, and also for create discussion threads about the main problems related to game development and games packages in Debian. You can join that list at: [...] You're welcome to join the group, or say whatever you think about this project. I think it's a marvellous idea as gaming is one of the aspects that is IMHO still underrepresented in Debian :-) Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: Development standards for unstable
On Thu, 12 Jan 2006, Andreas Barth wrote: One can try to come up with some metric, yes. However, on the other hand feel free to create a common maintained packages team that adopts such packages :) This may happen sooner that one may think. The project collab-maint on alioth is actually empty but it will be used for that purpose ... possibly starting with packages created by Ubuntu's MOTU which are of generic interest for Debian too. http://wiki.debian.org/CollaborativeMaintenance This proposal has recently been discussed in the last Ubuntu MOTU meeting and hopefully something will come out of it. A+ -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing the m68k port for the future.
On Sat, Jan 14, 2006 at 03:24:42AM +1000, Anthony Towns wrote: On Fri, Jan 13, 2006 at 06:04:00PM +0100, Wouter Verhelst wrote: The point of my previous mail was to demonstrate that I am, in fact, trying to be proactive about getting the qualification done. The way you demonstrate a commitment to getting archive qualification done is filling out a page on the wiki like: http://wiki.debian.org/ArchiveQualification/hurd-i386 http://wiki.debian.org/ArchiveQualification/kfreebsd-i386 Oh, hm. Must've missed that. And the stuff I wrote before was because I misparsed your mail into thinking you were talking about stuff like m68kEtchReleaseRecertification, which is something totally different. Sorry 'bout that; working on it now. [...] The fact you don't have anyone able to make a working cross-compiler speaks somewhat poorly of the support available for the m68k toolchain, too. The issues with producing a working cross-compiler that I hit against were not m68k-specific. Also, they may or may not have been fixed in the mean time; I know for a fact that there is no updated toolchain-source package available, but there've been a few upstream updates in the mean time, and I didn't go out and check them anymore (since my previous attempts failed) -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trivial bug on apt-file (Was : Re: Development standards for unstable)
On Thu, Jan 12, 2006 at 12:07:02PM -0600, Bill Allombert wrote:
There are technical ways to solve the problem (e.g. to depend on
wget|curl and to detect which one is available at start up).
If the mainatiner is willing to give more input than 'it is not a bug'
on what behaviour he would accept, we can probably come up with a patch.
That would be an ideal solution, which was already proposed in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=307833;msg=75
And was responded on a mail (dunno remember if to the bug, to d-d or on IRC)
that the user can utilize several other download managers, but that defeats
the whole purpose of having it done automatically. Besides, if that is the
case, the maintainer can find the most common downloaders and put them as |
dependencies, and receive patches to add config snipets for the most common
case.
Depending on some basic utilities (wget is installed by default on a debian
system) and not providing a simple check for finding the one which is already
installed and use it, instead of giving an error that does not explain the
nature of the problem (heh,
[ -x $(which curl) ] || { echo install curl or modify /pathtoconf ; exit 1;}
would do it) is nonsensical.
The current intent to NMU is not solving the problem, since depending in
wget|curl and having to modify the config file leads to the same problem if
the config points to curl and the user has wget.
Besides, the maintainer gave some answers that i consider not technically
adecuate, and some might even say are arrogant:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=307833;msg=34
--
Jesus Climent info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.14|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69
Sick as a dog. Gonna vomit.
--Dr. Evil (Austin Powers: The Spy Who Shagged Me)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trivial bug on apt-file (Was : Re: Development standards for unstable)
Jesus Climent wrote:
On Thu, Jan 12, 2006 at 12:07:02PM -0600, Bill Allombert wrote:
There are technical ways to solve the problem (e.g. to depend on
wget|curl and to detect which one is available at start up).
If the mainatiner is willing to give more input than 'it is not a bug'
on what behaviour he would accept, we can probably come up with a patch.
That would be an ideal solution, which was already proposed in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=307833;msg=75
Indeed, though I think it's rather another wishlist bug...
And was responded on a mail (dunno remember if to the bug, to d-d or on IRC)
that the user can utilize several other download managers, but that defeats
the whole purpose of having it done automatically. Besides, if that is the
case, the maintainer can find the most common downloaders and put them as |
dependencies, and receive patches to add config snipets for the most common
case.
and this answers IMHO what the maintainer wants a patch for: a system
that would work with all download managers.
Depending on some basic utilities (wget is installed by default on a debian
system) and not providing a simple check for finding the one which is already
installed and use it, instead of giving an error that does not explain the
nature of the problem (heh,
[ -x $(which curl) ] || { echo install curl or modify /pathtoconf ; exit 1;}
would do it) is nonsensical.
The current intent to NMU is not solving the problem, since depending in
wget|curl and having to modify the config file leads to the same problem if
the config points to curl and the user has wget.
The current intent to NMU is proposing curl | wget which doesn't need
any modification to the config file if curl is installed. Though you're
right that you still need to change the config file when curl is not
installed. This is IMHO however not a *severe* bug as some packages need
configuration if you don't choose to use the default.
Cheers
Luk
--
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D
signature.asc
Description: OpenPGP digital signature
Re: Dissection of an Ubuntu PR message
On Fri, Jan 13, 2006 at 03:03:14PM -0200, Gustavo Franco wrote: On 1/13/06, Matthew Garrett [EMAIL PROTECTED] wrote: David Nusinow [EMAIL PROTECTED] wrote: Please stop trying to twist my words around. Canonical didn't contribute back. An individual who happened to work for Canonical did. If someone employed by the US government contributes to Debian of his own volition do we say that the US government gives back to Debian? Do we say that your employer gives back to Debian? If it's an authorised use of company time, sure. Whether or not it is in this case, I don't know. Exactly my point Matthew, and calm down David, i wrote: e.g.: David said that Daniel helped him, but if he did that in his workhours it's under Canonical bless.. Do you see ? I just pointed out that there's a possibility that he was helping you in his workhours, You've never done anything at work that wasn't officially sanctioned by your boss? - Matt signature.asc Description: Digital signature
Re: Dissection of an Ubuntu PR message
On 1/13/06, Matthew Palmer [EMAIL PROTECTED] wrote: On Fri, Jan 13, 2006 at 03:03:14PM -0200, Gustavo Franco wrote: On 1/13/06, Matthew Garrett [EMAIL PROTECTED] wrote: David Nusinow [EMAIL PROTECTED] wrote: Please stop trying to twist my words around. Canonical didn't contribute back. An individual who happened to work for Canonical did. If someone employed by the US government contributes to Debian of his own volition do we say that the US government gives back to Debian? Do we say that your employer gives back to Debian? If it's an authorised use of company time, sure. Whether or not it is in this case, I don't know. Exactly my point Matthew, and calm down David, i wrote: e.g.: David said that Daniel helped him, but if he did that in his workhours it's under Canonical bless.. Do you see ? I just pointed out that there's a possibility that he was helping you in his workhours, You've never done anything at work that wasn't officially sanctioned by your boss? No, because i'm the technology coordinator in a NGO and i'm free to contribute to the Debian project during my workhours since we develop a CDD for telecentres. I see your point, but you're mixing different stuff. AFAIK the 'contribute back to Debian' is endorsed by Canonical, so it's officially sanctioned there using your own words. -- Gustavo Franco
Re: Anthony Towns: What I did today
Hi Anthony, On Saturday, 14 Jan 2006, you wrote: On Fri, Jan 13, 2006 at 04:22:50PM +0100, Martin Zobel-Helas wrote: On Friday, 13 Jan 2006, you wrote: Things I did today: 2. Removed the empty SuperH architecture from the archive (binary-sh). Coincidence? You decide. URL: http://azure.humbug.org.au/~aj/blog/2006/01/13#2006-01-13-sh-irts Nice you have done this, but Planet is definitely not the correct place to document changes like this. I would find it more appropriate to inform fellow DDs either via debian-devel@ or [EMAIL PROTECTED] Not all developers read planet.debian.org. I think you'll find the correct place is the -sh list, which was notified: http://lists.debian.org/debian-superh/2002/04/msg00010.html The sh arch in unstable has consisted of Architecture: all packages only since then. Even so you informed the porters it would have been nice to just drop a mail on -devel? Where is the problem in writing a mail to -devel? Going this way everybody would be informed and noone can complain afterwards. Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Requesting pistachio removal in a week
Hi, Initially I packaged pistachio because it was supposed to be the next microkernel to be used by the Hurd. That's questionable now. Also the package suffers some problems that I don't want to spend time fixing, like it not building on all supposedly supported arches, upstream not being much active externally, although they develop on internal repos which cannot be pushed outside due to research and paper publications or master thesis. I'll be requesting its removal in one week, if someone wants to adopt it please notify me and upload directly. The package description is: L4Ka::Pistachio is built from ground up incorporating the research results of the last seven years of microkernel and multi-server research. The code is written in C++ with a strong focus on performance and portability. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Development standards for unstable
Thomas Viehmann [EMAIL PROTECTED] writes: Can you elaborate on this? I'm not sure how the existence of more packages that should be orphaned invalidates dealing with those that presently are. There's 169 orphaned packages today, why not do something about them? The thing is... most of the orphaned packages are in fairly good shape. Most of the orphaned packages are orphaned because they're obscure and the person who cared about the package has left the project or run out of time. However, they are probably still working fine for people with those obscure needs, and as such there isn't an obvious significant gain for Debian by getting rid of them. The packages in the worst trouble in Debian are not the orphaned ones. By pretty much every available QA measure we have (RC bugs, open bugs, bugs without a response, lintian errors, time since last upload, etc.), almost of the packages in the worst shape have a regular maintainer. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Fri, Jan 13, 2006 at 12:41:29AM -0800, Steve Langasek wrote: Now, it may be that this is an unrealistic pipe dream on my part that's incompatible with Ubuntu's goals/release schedule, but it seems to me that everyone involved would get more mileage out of the giving-back process if there were more emphasis on trying to get changes made in sid *before* changing things in universe, wherever possible. I realize there are some practical issues on the Debian side that would need to be addressed to make this a reality, and I know there are plenty of cases when Ubuntu won't be able to wait for Debian before making particular changes, but I think it would greatly mitigate the concerns over divergence if people viewed universe as less of a sandbox for innovation than they seem to today. I wouldn't say that it's quite a pipe dream, but I think it's an oversimplification. I'm puzzled that you seem to admit that this approach isn't really practical today, for reasons beyond the control of Ubuntu developers, and yet are still disappointed that it isn't happening that way. It may be that the issues are more obvious to me, given that I have substantial first-hand experience with both Debian and Ubuntu development. I realize that to many Debian developers, Ubuntu is a black box, because while our development process is just as open as Debian's, they simply have no interest in it, and I think this leads to many of the misunderstandings which surface in threads like this one. By way of illustration, consider this (intentionally) oversimplified view from the reverse perspective: If you want Ubuntu changes to propagate into Debian more quickly, the mechanics are very straightforward. Queue all Ubuntu source uploads, build, sign and upload to Debian incoming. Ubuntu uploads of packages inherited from Debian are versioned in an NMU-ish way where a following maintainer upload to Debian would override it. If you're concerned about branding changes (which, by the way, are few and far between on an ongoing basis), you could apply the same heuristic used in the Ubuntu patch archive to flag uploads which look like branding changes, and eyeball the changelog before letting them through. Each time one of these uploads is made, generate a debdiff relative to the existing source package in sid, and email a debdiff to the BTS with the patch tag. Ubuntu changes are now promptly made available in sid, and all of the patches are filed in the BTS. Done and done. It sounds awfully efficient compared to managing hundreds of patch queues by hand between individual developers, but anyone who has spent time in Debian can easily spot the holes in it. Likewise, a proposal that Ubuntu developers should put their changes into Debian instead sounds simple, but to an Ubuntu developer is obviously impractical. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
Bill Allombert wrote: Although sarge's aptitude did.. I don't know, there were no ways to upgrade to sarge's aptitude. The bug log contains a log of astronut doing the upgrade with sarge's aptitude.. -- see shy jo signature.asc Description: Digital signature
Re: Getting rid of circular dependencies, stage 3
Henning Glawe wrote: To illustrate the scenario: - Package A depends on package B, which in turn depends on A 0) User calls 'apt-get install long-list-of-packages1 A B long-list-of-packages2': 1) apt splits the whole list into smaller parts after sorting by dependency where, in case this bug occurs: part1=long-list-of-packages3 A part2=B long-list-of-packages4 2) apt calls 'dpkg --unpack' for each element of part1 and part2 == so far no problem == 3) apt calls 'dpkg --configure part1' and 'dpkg --configure part2' where the first step already fails, because B is not in part1, but A depends on B == complete failure, user has to recover manually: debconf will not break in this situation (BTW, it's not formally essential, but it needs to have the same qualities as essential packages, and does.) -- see shy jo signature.asc Description: Digital signature
Re: Anthony Towns: What I did today
* Martin Zobel-Helas [EMAIL PROTECTED] [2006-01-13 20:34:20]: ...and no one can complain afterwards. you underestimate your fellow nagg^Wdevelopers. signature.asc Description: Digital signature
Re: Need for launchpad
On Fri, Jan 13, 2006 at 07:48:56AM -0600, John Hasler wrote: Why? Don't we expect users to decide which of their local changes are suitable for Debian? I sometimes make local changes to Debian packages. Sometimes I send patches to the BTS and sometimes I decide that the change is only relevant to my local situation. Should I instead put them all up on a Web site and expect the maintainers to sort through them? This is a very interesting analogy. Over the years, I have worked at many sites which carried local changes to upstream software, changes which were never seen outside of the company. Usually this isn't because they don't care, but because no one got around to it, or because they didn't know how. As a Debian developer, you are comfortable with the process and motivated to follow it, while most end users are neither. You may expect users to do this, but in my experience, they most often don't. You simply don't hear about it. Again, why should Ubuntu's patches be handled any differently than those of other users? I would say that Ubuntu's patches are handled better than those of Debian end users in general and better than those of other Debian derivatives. Ironically, the fact that the patches are so visible has resulted in a recurring controversy over how they should be handled, while patches which rot unknown do not reflect on their creators at all. I don't either. After all, most users don't file bug reports, and Ubuntu is (in my view), a user. I disagree with this analogy; Ubuntu is a collaborative project with a sizeable number of developers, and it doesn't behave like a user to any meaningful degree. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Fri, Jan 13, 2006 at 05:08:33PM +0100, cobaco (aka Bart Cornelis) wrote: as documented experience by maintainers who've tried that shows, this is inefficient enough that reimplementing is mostly faster (and definately more attractive, as it involves less drudgework) This is at best an exaggeration, and clearly and demonstrably *not* the rule. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Fri, Jan 13, 2006 at 03:19:09PM +0100, cobaco (aka Bart Cornelis) wrote: But at the moment I've seen lots of comments by maintainers saying that in most cases it's currently more work to find out if there's any usefull bits in the diffs between debian-ubuntu packages, then to do the work themselves (for various reasons, which have been mentioned before) One generally only hears about the problems in these situations. Someone who quietly pulls a patch from Ubuntu and goes on with their life doesn't complain loudly in threads like these, but I see it all the time on debian-devel-changes. There are rather few cases where the diffs are truly hairy, as I've pointed out in previous threads with examples. In the mean while Ubuntu proudly calls ubuntu gives things back, whereas in reality we mostly have a situation of ubuntu will help debian maintainers that want to take things back - It's this misrepresentation of where (most of) the initiative lies which pisses people off. This is only the latest expression of the same general discontent which has been rehashed again and again on this list. A year ago it was Ubuntu aren't contributing, then Ubuntu aren't contributing in the right way, and now Ubuntu aren't contributing in the way that they say that they are. Ubuntu hasn't significantly changed its practices; it is only the accusation which has changed over time. The trouble is that those expressing this opinion seem to have misunderstandings about what has actually been said. They talk about what is said proudly, that Ubuntu is crowing or bragging about giving back, that it conceals its Debian roots, etc. If you read what is written on the Ubuntu website about the relationship between Ubuntu and Debian, it doesn't have this kind of tone at all, and certainly doesn't use the kind of language that many have attributed to Ubuntu in this thread. Some things that it does say: - Ubuntu is based on Debian, and what this means in terms of the movement of packages - Ubuntu differs from Debian in its philosophy, and how - The Ubuntu development methodology is different from Debian's, and how - Ubuntu classifies packages from Debian into different categories, how, and why - Ubuntu's release cycle differs from Debian's, and how - Ubuntu, unlike many other Debian derivatives, publishes all of its patches for Debian's benefit, and on a continuous basis, not only when a release is made - Ubuntu submits fixes for Debian bugs to the Debian BTS including a patch URL The information on the page is accurate (or was at the time of its writing; there seem to be some outdated bits) and much of it has been validated as such by virtue of being argued about on this very mailing list. It does not discuss the direct collaboration which takes place between certain Ubuntu developers and Debian developers who communicate regularly, though this practice is not uncommon either. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Anthony Towns: What I did today
On Fri, 13 Jan 2006, Andreas Schuldei wrote: * Martin Zobel-Helas [EMAIL PROTECTED] [2006-01-13 20:34:20]: ...and no one can complain afterwards. you underestimate your fellow nagg^Wdevelopers. Well, there are always people who complain. But posting development related mails to debian-devel is the intended purpose of this list and there is less reason to complain then it is if people do not at least mark their postings [OT] when they are chatting about other distributions on debian-devel. So, if you ask me it would be better if messages like the one Anthony blogged would be here in the first place and the blog would say: I just posted this or that to debian-devel ... :) Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On 10533 March 1977, Raphael Hertzog wrote: Hello fellow Debian developers, let me explain shortly why I'll speak of Ubuntu on a Debian announce [lalala] Whatever one may think about Ubuntu, d-d-a is the wrong list for an announcement about Ubuntu plans. Announcements of development issues like policy changes, important release issues c. -- bye Joerg D. You've just heard about this great program and would like to package it, what are your next steps? I would start off by sighing deeply and wishing I were already a DD. :-) [...] If I were already a DD, I would perform most of these same steps. I would omit the deep sigh and replace it with a gasp of excitement,[...] pgp7l5IXDwkuX.pgp Description: PGP signature
Bug#347993: ITP: optipng -- advanced PNG optimizer
Package: wnpp Severity: wishlist Owner: Nelson A. de Oliveira [EMAIL PROTECTED] * Package name: optipng Version : 0.4.8 Upstream Author : Cosmin Truta [EMAIL PROTECTED] * URL : http://www.cs.toronto.edu/~cosmin/pngtech/optipng/ * License : zlib/libpng Description : advanced PNG optimizer OptiPNG is a PNG optimizer that recompresses the image files to a smaller size, without losing any information. The idea has been inspired from pngcrush (http://pmt.sourceforge.net/pngcrush), and is explained in detail in the PNG-Tech article A guide to PNG optimization (http://www.cs.toronto.edu/~cosmin/pngtech/optipng.html). The implementation is carried forward in OptiPNG, which offers a faster execution per trial, and a wider search space. Nelson -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.13-rc5-mm1 Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1) (ignored: LC_ALL set to pt_BR) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Fri, Jan 13, 2006 at 01:14:18PM -0800, Matt Zimmerman wrote: The trouble is that those expressing this opinion seem to have misunderstandings about what has actually been said. They talk about what is said proudly, that Ubuntu is crowing or bragging about giving back, that it conceals its Debian roots, etc. If you read what is written on the Ubuntu website about the relationship between Ubuntu and Debian, it doesn't have this kind of tone at all, and certainly doesn't use the kind of language that many have attributed to Ubuntu in this thread. I don't buy this. The impression that just about everyone has of this didn't come from nowhere. http://www.ubuntulinux.org/ubuntu/relationship Sponsored by Canonical, the Ubuntu project attempts to work with Debian to address the issues that keep many users from using Debian. ... When Ubuntu developers fix bugs that are also present in debian packages -- and since the projects are linked, this happens often -- they send their bugfixes to the Debian developers responsible for that package in debian and record the patch URL in the debian bug system. ... First, Ubuntu contributes patches directly to Debian I think that's what serves to create a pretty strong impression that Ubuntu is actually working very closely with Debian to do things like address the issues that keep many users from using Debian. From the sound of this thread everyone would welcome what's on that page with open arms. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
On Fri, Jan 13, 2006 at 03:57:57PM -0500, Joey Hess wrote: Bill Allombert wrote: Although sarge's aptitude did.. I don't know, there were no ways to upgrade to sarge's aptitude. The bug log contains a log of astronut doing the upgrade with sarge's aptitude.. Yes, but only after having run 'aptitude install aptitude perl' with woody aptitude which did: 56 packages upgraded, 64 newly installed, 5 to remove and 547 not upgraded. which was a non trivial upgrade. So sarge aptitude was actually running on a smaller set of packages where the perl modules cicular-dep was no more present. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Mon, Jan 09, 2006 at 03:41:08PM -0800, Russ Allbery wrote: I'm not at all surprised that Ubuntu is drifting into closed-source software, as this is a standard development path for a company based around free software. I'm not upset. I'm simply not interested, and consider that path to be entirely predictable. Ubuntu, while its license policy is somewhat less strict than the DFSG, is not drifting into closed-source software. It's virtually unchanged since the project's inception. http://www.ubuntu.com/ubuntu/licensing And certainly, I would oppose blessing any closed-source toolset as part of Debian's infrastructure, regardless of its origins. So would I. I mean this in the same sense that I assume that you do, meaning the sort of software which we see and work with directly. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Fri, Jan 13, 2006 at 01:14:18PM -0800, Matt Zimmerman wrote: Some things that it does say: [...] - Ubuntu submits fixes for Debian bugs to the Debian BTS including a patch URL If that said sometimes or some people within Ubuntu, it would be correct. Not every relevant patch ends up in the BTS. I'd also echo David Nusinow's comments that the wording of some of the statements implies a far closer cooperation than is apparent from watching what actually happens. - Matt signature.asc Description: Digital signature
Re: Need for launchpad
On Sat, Jan 14, 2006 at 10:19:50AM +1100, Matthew Palmer wrote: On Fri, Jan 13, 2006 at 01:14:18PM -0800, Matt Zimmerman wrote: Some things that it does say: [...] - Ubuntu submits fixes for Debian bugs to the Debian BTS including a patch URL If that said sometimes or some people within Ubuntu, it would be correct. Not every relevant patch ends up in the BTS. I was afraid that this would start this kind of trivial semantic discussion. It doesn't say that Ubuntu fixes ALL Debian bugs, or any other absolute. It does say that Ubuntu submits bug fixes to Debian through the BTS, and there are in fact hundreds of such fixes in debbugs today. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Fri, Jan 13, 2006 at 05:49:40PM -0500, David Nusinow wrote: I don't buy this. The impression that just about everyone has of this didn't come from nowhere. Not from nowhere, no. The statements that Ubuntu steals users from Debian, wants to kill Debian, etc. came from somewhere, too, but that somewhere wasn't Ubuntu. http://www.ubuntulinux.org/ubuntu/relationship Sponsored by Canonical, the Ubuntu project attempts to work with Debian to address the issues that keep many users from using Debian. Ubuntu does attempt to work with Debian. When Ubuntu developers fix bugs that are also present in debian packages -- and since the projects are linked, this happens often -- they send their bugfixes to the Debian developers responsible for that package in debian and record the patch URL in the debian bug system. Ubuntu does submit such patches, though bugs which were reported to Debian and consequently fixed by Ubuntu developers would be more accurate. I'll suggest that change. First, Ubuntu contributes patches directly to Debian The word directly is somewhat misleading here; in general, Ubuntu developers are not allowed (by Debian) to make any change directly to Debian. I will suggest that it be removed. I think that's what serves to create a pretty strong impression that Ubuntu is actually working very closely with Debian to do things like address the issues that keep many users from using Debian. From the sound of this thread everyone would welcome what's on that page with open arms. I can't agree. From the sound of this and other threads, there are a number of folks who are unlikely to be satisfied with any behavior on the part of the Ubuntu project or its members. Fortunately, there are others who are actively cooperating to the mutual benefit of the two projects. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On Fri, Jan 13, 2006 at 11:35:24PM +0100, Raphael Hertzog wrote: I believe Ubuntu fills an important gap in the Debian world and as such Ubuntu is not part of the Debian world, because it does not share the values that found Debian. The Ubuntu people are certainly free to use our softwares, that is even the whole point of the exercise, but ourself should not direct our users (and developers) to distributions with lower standards by pretending they are 'part of the Debian world' because this amounts to self-destruction. If such gap exist, we should not abdicate our responsability to fill it to others that do not adhere to our principles. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Matt Zimmerman [EMAIL PROTECTED] writes: Ubuntu, while its license policy is somewhat less strict than the DFSG, is not drifting into closed-source software. It's virtually unchanged since the project's inception. The policy and development may be virtually unchanged since the project's inception since I have no idea how many other closed-source components such as Launchpad you've been working on from the beginning, but at least the public face is drifting as those projects are deployed and become part of the day-to-day work on Ubuntu. And hey, as I said, if that's what you want to do, more power to you. I'm well aware that many in the free software community are quite happy to use closed-source and/or commercial infrastructure toolsets and services. The advertising deluge that drowns me every time I try to look at Sourceforge is a good reminder of that. :) However, the more that you deploy and depend on closed-source tools, the less interesting Ubuntu is to me personally. (It's quite likely that you don't care, and that's fine. I don't really expect you to.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: French cheese
On Fri, Jan 13, 2006 at 06:15:16PM +0100, Christian Perrier wrote: Quoting Matt Zimmerman ([EMAIL PROTECTED]): Unfortunately, this conflicts with a development sprint we're having in London, so that won't be possible at that time. My heart breaks at the prospect of a missed opportunity to gorge myself on cheese... Well, it's just a matter of jumping in the first Eurostar in the morning, be at Gare du Nord around 8 or 9, go to Solutions Linux, drink, talk and eat cheese all day long with fellow Debian and Ubuntu people, then jump in another Eurostar back to London (with some cheese in your luggage) and be back for hacking with your fellow Ubuntu people late in the night. I'm afraid I really can't leave in the middle of things, though I'll be in a convenient time zone and available by voice or IRC much of the time. I will simply have to be content with imported cheese until DebConf. And, for next year, just plan your development sprint in Paris..:-) (I'm half-serious and even really serious here) Could happen... -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Fri, 13 Jan 2006 15:53:51 -0800, Matt Zimmerman [EMAIL PROTECTED] said: I can't agree. From the sound of this and other threads, there are a number of folks who are unlikely to be satisfied with any behavior on the part of the Ubuntu project or its members. Fortunately, there are others who are actively cooperating to the mutual benefit of the two projects. Whooo. This sounds like a bit of a smear -- either people are unsatisfiable cads who demand overmuch, or they are perfectly happily contributing back and forth. Nothing in between these extremes? Which group, pray, do you categorize me into? manoj -- It is undignified for a woman to play servant to a man who is not hers. Spock, Amok Time, stardate 3372.7 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
* Raphael Hertzog: I believe Ubuntu fills an important gap in the Debian world and as such I'm not satisfied when Ubuntu is diverging too much from Debian, and the only way to avoid divergence is to merge back what's useful and to provide better solution for derivatives when there's a need for a divergence. How can I request removal of a package which has been added to Ubuntu (universe, whatever that is), despite not being useful on Ubuntu? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Fri, Jan 13, 2006 at 07:19:53PM -0600, Manoj Srivastava wrote: Which group, pray, do you categorize me into? You, Manoj, are in a category all your own. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On Sat, Jan 14, 2006 at 02:54:30AM +0100, Florian Weimer wrote: * Raphael Hertzog: I believe Ubuntu fills an important gap in the Debian world and as such I'm not satisfied when Ubuntu is diverging too much from Debian, and the only way to avoid divergence is to merge back what's useful and to provide better solution for derivatives when there's a need for a divergence. How can I request removal of a package which has been added to Ubuntu (universe, whatever that is), despite not being useful on Ubuntu? The maintainers for the Ubuntu universe component can be reached at [EMAIL PROTECTED] -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dissection of an Ubuntu PR message
On Fri, Jan 13, 2006 at 03:03:14PM -0200, Gustavo Franco wrote: On 1/13/06, Matthew Garrett [EMAIL PROTECTED] wrote: David Nusinow [EMAIL PROTECTED] wrote: Please stop trying to twist my words around. Canonical didn't contribute back. An individual who happened to work for Canonical did. If someone employed by the US government contributes to Debian of his own volition do we say that the US government gives back to Debian? Do we say that your employer gives back to Debian? If it's an authorised use of company time, sure. Whether or not it is in this case, I don't know. Exactly my point Matthew, and calm down David, i wrote: e.g.: David said that Daniel helped him, but if he did that in his workhours it's under Canonical bless.. Do you see ? I just pointed out that there's a possibility that he was helping you in his workhours, but i won't cite you as a reference anymore. -- Gustavo Franco Hi Gustavo, Is it within the scope of Canonical employees to contribute code to Debian that is under the his copyright and not Canonical's? And especially since it is in the exact same area that he was employed by Canonical to do? Would this apply to Progeny and Debian, Progeny and Canonical, Linspire and ... Cheers, Kev -- counter.li.org #238656 -- goto counter.li.org and be counted! `$' $' $ $ _ ,d$$$g$ ,d$$$b. $,d$$$b`$' g$b $,d$$b ,$P' `$ ,$P' `Y$ $$' `$ $ ' `$ $$' `$ $$ $ $$g$ $ $ $ ,$P $ $$ `$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$ `Y$$P'$. `YP $$$P' ,$. `Y$$P'$ $. ,$. signature.asc Description: Digital signature
Re: Need for launchpad
David Nusinow [EMAIL PROTECTED] writes: http://www.ubuntulinux.org/ubuntu/relationship Sponsored by Canonical, the Ubuntu project attempts to work with Debian to address the issues that keep many users from using Debian. ... When Ubuntu developers fix bugs that are also present in debian packages -- and since the projects are linked, this happens often -- they send their bugfixes to the Debian developers responsible for that package in debian and record the patch URL in the debian bug system. ... First, Ubuntu contributes patches directly to Debian I think that's what serves to create a pretty strong impression that Ubuntu is actually working very closely with Debian to do things like address the issues that keep many users from using Debian. From the sound of this thread everyone would welcome what's on that page with open arms. But it doesn't describe Ubuntu's past behavior. Has there been an official change, or what? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Matt Zimmerman [EMAIL PROTECTED] writes: I can't agree. From the sound of this and other threads, there are a number of folks who are unlikely to be satisfied with any behavior on the part of the Ubuntu project or its members. Fortunately, there are others who are actively cooperating to the mutual benefit of the two projects. Really, it's very easy. I would be satisfied if both of the following were done: Every time you find a bug in an Ubuntu package, make some effort to determine if it is Ubuntu-specific or might rather affect all Debian users. If it is not Ubuntu-specific, then file a bug report, and optionally, a patch, in the Debian BTS. Every Ubuntu package should have a different Maintainer unless the Debian maintainer has agreed to be the Maintainer of the Ubuntu package as well. The Ubuntu package should, of course, continue to give credit to the upstream Debian maintainer, but not by designating that individual as the Maintainer in the Ubuntu package. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Matt Zimmerman [EMAIL PROTECTED] writes: It doesn't say that Ubuntu fixes ALL Debian bugs, or any other absolute. It does say that Ubuntu submits bug fixes to Debian through the BTS, and there are in fact hundreds of such fixes in debbugs today. Does Ubuntu do so for every bug it fixes, or only some? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Fri, Jan 13, 2006 at 08:34:33PM -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: I can't agree. From the sound of this and other threads, there are a number of folks who are unlikely to be satisfied with any behavior on the part of the Ubuntu project or its members. Fortunately, there are others who are actively cooperating to the mutual benefit of the two projects. Really, it's very easy. I would be satisfied if both of the following were done: Every time you find a bug in an Ubuntu package, make some effort to determine if it is Ubuntu-specific or might rather affect all Debian users. If it is not Ubuntu-specific, then file a bug report, and optionally, a patch, in the Debian BTS. Which might be ideal, but I don't think it's realistic to ask that they do this for *every* bug they find. Every Ubuntu package should have a different Maintainer unless the Debian maintainer has agreed to be the Maintainer of the Ubuntu package as well. The Ubuntu package should, of course, continue to give credit to the upstream Debian maintainer, but not by designating that individual as the Maintainer in the Ubuntu package. Which is not something that most Debian developers seem to be hung up on; and some maintainers seem to prefer to be credited in the packages. So if this is what it takes to satisfy you, I suspect you're going to have to live with your dissatisfaction. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Need for launchpad
Steve Langasek [EMAIL PROTECTED] writes: Every time you find a bug in an Ubuntu package, make some effort to determine if it is Ubuntu-specific or might rather affect all Debian users. If it is not Ubuntu-specific, then file a bug report, and optionally, a patch, in the Debian BTS. Which might be ideal, but I don't think it's realistic to ask that they do this for *every* bug they find. Why? Every time I find a bug in a package I maintain, which is a bug in the upstream version too, I report it. Isn't that normal? This is, in fact, just what is expected. It's what cooperation means to me. Every Ubuntu package should have a different Maintainer unless the Debian maintainer has agreed to be the Maintainer of the Ubuntu package as well. The Ubuntu package should, of course, continue to give credit to the upstream Debian maintainer, but not by designating that individual as the Maintainer in the Ubuntu package. Which is not something that most Debian developers seem to be hung up on; and some maintainers seem to prefer to be credited in the packages. Um, I have said nothing against crediting maintainers in the packages. I have only said that I would like Ubuntu to clearly label which is the Debian maintainer and which is the Ubuntu maintainer. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libecw
Miriam Ruiz wrote: I'm not sure if it's license ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293346 ) can be considered free enough to be in main: Some feedback from upstream is in this thread: http://lists.alioth.debian.org/pipermail/pkg-grass-general/2005-August/thread.html#1082 http://lists.alioth.debian.org/pipermail/pkg-grass-general/2005-August/001082.html http://lists.alioth.debian.org/pipermail/pkg-grass-general/2005-August/001083.html http://lists.alioth.debian.org/pipermail/pkg-grass-general/2005-August/001085.html http://lists.alioth.debian.org/pipermail/pkg-grass-general/2005-August/001086.html -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: For those who care about their packages in Ubuntu
On Sat, Jan 14, 2006 at 01:26:25AM +0100, Bill Allombert wrote: On Fri, Jan 13, 2006 at 11:35:24PM +0100, Raphael Hertzog wrote: I believe Ubuntu fills an important gap in the Debian world and as such Ubuntu is not part of the Debian world, because it does not share the values that found Debian. That's kind of a strange position to take, isn't it? Does this mean that the many users who use Debian directly sheerly on technical excellence alone, without sharing Debian's founding values, are not part of the Debian world? For that matter, I don't know of any derivative Debian distributions that require their developers to agree to the social contract; so by that standard, are *any* of them part of the Debian world? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Packet radio and foul language
On Wed, Jan 11, 2006 at 03:41:09PM +, Andrew Suffield wrote: On Tue, Jan 10, 2006 at 12:43:16PM -0600, Ron Johnson wrote: Manners/politeness is social lubricant. It makes society run smoother and less violently. I'm pretty sure that people who always take the path of least resistance are *precisely* how the world got so fucked up in the first place. Sacrificing long term gains for short term pleasures, perhaps, rather than *always* taking the path of least resistance. -- Chris. == Reproduction if desired may be handled locally. -- rfc3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Fri, Jan 13, 2006 at 03:53:51PM -0800, Matt Zimmerman wrote: First, Ubuntu contributes patches directly to Debian The word directly is somewhat misleading here; in general, Ubuntu developers are not allowed (by Debian) to make any change directly to Debian. I will suggest that it be removed. Heh. Ubuntu is certainly allowed to contribute patches directly to Debian -- anyone can mail patches to the BTS, including Ubuntu. I can't agree. From the sound of this and other threads, there are a number of folks who are unlikely to be satisfied with any behavior on the part of the Ubuntu project or its members. Fortunately, there are others who are actively cooperating to the mutual benefit of the two projects. While I'm sure there'll be some people who'll complain no matter what, I don't see what the problem with mailing patches directly to the BTS is. As far as tracking is concerned, making use of [EMAIL PROTECTED] usertags or similar would seem sensible. Cheers, aj signature.asc Description: Digital signature
Re: Need for launchpad
While I'm sure there'll be some people who'll complain no matter what, I don't see what the problem with mailing patches directly to the BTS is. As far as tracking is concerned, making use of [EMAIL PROTECTED] usertags or similar would seem sensible. Silly question, probably, but wouldn't this flood the BTS? If not, this sounds like an interesting suggestion and the shadow package maintenance team is opened to serve as a test case for this -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted coin 1.0.4-5 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 Jan 2006 23:55:07 -0500 Source: coin Binary: libcoin20-runtime libcoin20-dev libcoin20-doc libcoin20 Architecture: source all i386 Version: 1.0.4-5 Distribution: unstable Urgency: low Maintainer: Steve M. Robbins [EMAIL PROTECTED] Changed-By: Steve M. Robbins [EMAIL PROTECTED] Description: libcoin20 - high-level 3D graphics kit - runtime libcoin20-dev - high-level 3D graphics kit - development libcoin20-doc - high-level 3D graphics kit - documentation libcoin20-runtime - high-level 3D graphics kit - external data files Closes: 346641 Changes: coin (1.0.4-5) unstable; urgency=low . * debian/control: Replace build-dependency on xlibs-dev with 8 others. This is progress, apparently. Closes: #346641. Files: dc43ada3cdeb7378aaae974f4ed85553 716 graphics optional coin_1.0.4-5.dsc b1236414f341831a534be08fb4b3 79109 graphics optional coin_1.0.4-5.diff.gz ba7f3a38bc3bcb5b33941080d62d39e5 12770 libs optional libcoin20-runtime_1.0.4-5_all.deb f51f97fe6238549b22a413cc29d7c419 4018952 doc optional libcoin20-doc_1.0.4-5_all.deb e7f91f21cb9b8052cb1fe13d718432d9 1306252 libs optional libcoin20_1.0.4-5_i386.deb 91c560ffa4c7592aed06381c13c18e5d 1916394 libdevel optional libcoin20-dev_1.0.4-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDx1nm0i2bPSHbMcURAs7nAJ43WueDs55b1XwvqytDrCfUUL2LWwCeNsjF UEMHY+LCiYj+HSZqHC3/5Bk= =5eU3 -END PGP SIGNATURE- Accepted: coin_1.0.4-5.diff.gz to pool/main/c/coin/coin_1.0.4-5.diff.gz coin_1.0.4-5.dsc to pool/main/c/coin/coin_1.0.4-5.dsc libcoin20-dev_1.0.4-5_i386.deb to pool/main/c/coin/libcoin20-dev_1.0.4-5_i386.deb libcoin20-doc_1.0.4-5_all.deb to pool/main/c/coin/libcoin20-doc_1.0.4-5_all.deb libcoin20-runtime_1.0.4-5_all.deb to pool/main/c/coin/libcoin20-runtime_1.0.4-5_all.deb libcoin20_1.0.4-5_i386.deb to pool/main/c/coin/libcoin20_1.0.4-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted esound 0.2.36-3 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 13 Jan 2006 00:33:23 -0800 Source: esound Binary: libesd0 libesd-alsa0 libesd0-dev esound-clients esound esound-common Architecture: source i386 all Version: 0.2.36-3 Distribution: unstable Urgency: low Maintainer: Ryan Murray [EMAIL PROTECTED] Changed-By: Ryan Murray [EMAIL PROTECTED] Description: esound - Enlightened Sound Daemon - Support binaries esound-clients - Enlightened Sound Daemon - clients esound-common - Enlightened Sound Daemon - Common files libesd-alsa0 - Enlightened Sound Daemon (ALSA) - Shared libraries libesd0- Enlightened Sound Daemon - Shared libraries libesd0-dev - Enlightened Sound Daemon - Development files Closes: 347751 Changes: esound (0.2.36-3) unstable; urgency=low . * Only include *64 functions if necessary in libesddsp for things that check at runtime rather than compile time (closes: #347751) Files: fb818f12bfec69d923b84421e462b454 734 sound optional esound_0.2.36-3.dsc 4f21cfd653aec5489b36f81c3a7f4fca 135540 sound optional esound_0.2.36-3.diff.gz aaa4e84529e028b9bff91de12c4d7fa7 38152 sound optional esound-common_0.2.36-3_all.deb 471ea3cdb65262a030d3d5eaab559298 22662 sound optional esound_0.2.36-3_i386.deb 7f980354abfdf68d42fd20bf1aecda1f 35546 sound optional esound-clients_0.2.36-3_i386.deb a9e894883e56ae059dde09a00f3c 18854 libs optional libesd0_0.2.36-3_i386.deb 322fd06b8fef64c0954f42e0858f860e 23744 libdevel optional libesd0-dev_0.2.36-3_i386.deb 05cd220e6d807551214ddce40aec5ff8 21312 libs extra libesd-alsa0_0.2.36-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDx2ZeN2Dbz/1mRasRAofbAJsHZ6nQNUJJEpArTClb1IMv1zry+gCfRyAW rgzKYCWp8BM8C6eJU+9LcKk= =wHcA -END PGP SIGNATURE- Accepted: esound-clients_0.2.36-3_i386.deb to pool/main/e/esound/esound-clients_0.2.36-3_i386.deb esound-common_0.2.36-3_all.deb to pool/main/e/esound/esound-common_0.2.36-3_all.deb esound_0.2.36-3.diff.gz to pool/main/e/esound/esound_0.2.36-3.diff.gz esound_0.2.36-3.dsc to pool/main/e/esound/esound_0.2.36-3.dsc esound_0.2.36-3_i386.deb to pool/main/e/esound/esound_0.2.36-3_i386.deb libesd-alsa0_0.2.36-3_i386.deb to pool/main/e/esound/libesd-alsa0_0.2.36-3_i386.deb libesd0-dev_0.2.36-3_i386.deb to pool/main/e/esound/libesd0-dev_0.2.36-3_i386.deb libesd0_0.2.36-3_i386.deb to pool/main/e/esound/libesd0_0.2.36-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted caps 0.3.0-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 12 Jan 2006 15:06:50 +0100 Source: caps Binary: caps Architecture: source i386 Version: 0.3.0-1 Distribution: unstable Urgency: low Maintainer: Mario Lang [EMAIL PROTECTED] Changed-By: Mario Lang [EMAIL PROTECTED] Description: caps - C* Audio Plugin Suite Changes: caps (0.3.0-1) unstable; urgency=low . * New upstream release Files: 6a9ec29a776777cf3e9a2d893f77e4e5 563 sound optional caps_0.3.0-1.dsc ece235ac353092f39a4f15d365cfa46f 209075 sound optional caps_0.3.0.orig.tar.gz c46588c4294b20804cd49ff6207dae19 2746 sound optional caps_0.3.0-1.diff.gz 0656c96b80fc8f33f25acf0347fa2272 193978 sound optional caps_0.3.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDx2tw3/wCKmsRPkQRAl2WAJ41MHS1+P87l1DCbVspU62lzB8EKQCfT4My 296DqL0eDvge5b/lPrbRqQU= =1pqE -END PGP SIGNATURE- Accepted: caps_0.3.0-1.diff.gz to pool/main/c/caps/caps_0.3.0-1.diff.gz caps_0.3.0-1.dsc to pool/main/c/caps/caps_0.3.0-1.dsc caps_0.3.0-1_i386.deb to pool/main/c/caps/caps_0.3.0-1_i386.deb caps_0.3.0.orig.tar.gz to pool/main/c/caps/caps_0.3.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gamin 0.1.7-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 13 Jan 2006 10:33:59 +0100 Source: gamin Binary: gamin python2.3-gamin libgamin0 libgamin-dev Architecture: source i386 Version: 0.1.7-3 Distribution: unstable Urgency: low Maintainer: Debian GNOME Maintainers [EMAIL PROTECTED] Changed-By: Josselin Mouette [EMAIL PROTECTED] Description: gamin - File and directory monitoring system libgamin-dev - Development files for the gamin client library libgamin0 - Client library for the gamin file and directory monitoring system python2.3-gamin - Python binding for the gamin client library Changes: gamin (0.1.7-3) unstable; urgency=low . * libgamin0.shlibs: generate a dependency on libfam0, not libgamin0. Files: 03032ebeafd2a5b000123c66c18b5a8e 1633 admin optional gamin_0.1.7-3.dsc dbd227ca111aaac25211a290e0157128 4664 admin optional gamin_0.1.7-3.diff.gz 0a61c258f7c66f22094adf4ca906f961 61262 admin optional gamin_0.1.7-3_i386.deb 8ef8d9cf35af4f510c733848f096006e 34066 libs optional libgamin0_0.1.7-3_i386.deb 1588ce5ee7cd2e89a2a99132fddea567 48328 libdevel optional libgamin-dev_0.1.7-3_i386.deb 34acabf6cb7a60ae4723c38ab3322afb 27994 python optional python2.3-gamin_0.1.7-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDx3Wh4VUX8isJIMARAhx5AJ4wjrH7ocAsXFBNWkhhPq9MGgZrggCeJIir +mGgRi85tlA3v7HVFA8v/70= =vOoB -END PGP SIGNATURE- Accepted: gamin_0.1.7-3.diff.gz to pool/main/g/gamin/gamin_0.1.7-3.diff.gz gamin_0.1.7-3.dsc to pool/main/g/gamin/gamin_0.1.7-3.dsc gamin_0.1.7-3_i386.deb to pool/main/g/gamin/gamin_0.1.7-3_i386.deb libgamin-dev_0.1.7-3_i386.deb to pool/main/g/gamin/libgamin-dev_0.1.7-3_i386.deb libgamin0_0.1.7-3_i386.deb to pool/main/g/gamin/libgamin0_0.1.7-3_i386.deb python2.3-gamin_0.1.7-3_i386.deb to pool/main/g/gamin/python2.3-gamin_0.1.7-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libdbix-class-loader-perl 0.12-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 13 Jan 2006 09:51:42 +0100 Source: libdbix-class-loader-perl Binary: libdbix-class-loader-perl Architecture: source all Version: 0.12-1 Distribution: unstable Urgency: low Maintainer: Debian Catalyst Maintainers [EMAIL PROTECTED] Changed-By: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] Description: libdbix-class-loader-perl - Dynamic definition of DBIx::Class sub classes. Changes: libdbix-class-loader-perl (0.12-1) unstable; urgency=low . * New upstream release Files: 572a8a74a5d2107964424d602d69c516 895 perl optional libdbix-class-loader-perl_0.12-1.dsc 28ee0bef74cfdbb80d98582c86b541ae 9893 perl optional libdbix-class-loader-perl_0.12.orig.tar.gz 753159c5facea00aac904bf61f3e4bfe 2398 perl optional libdbix-class-loader-perl_0.12-1.diff.gz 6192252a5542f9934338bc6ff175f167 25916 perl optional libdbix-class-loader-perl_0.12-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDx24x+NMfSd6w7DERApA3AJ9NhnVk3YYveTiZWAHJO5V+NBF6aQCdHs+W iGPLn2QAWdzay1PlIvF4gVU= =dMb2 -END PGP SIGNATURE- Accepted: libdbix-class-loader-perl_0.12-1.diff.gz to pool/main/libd/libdbix-class-loader-perl/libdbix-class-loader-perl_0.12-1.diff.gz libdbix-class-loader-perl_0.12-1.dsc to pool/main/libd/libdbix-class-loader-perl/libdbix-class-loader-perl_0.12-1.dsc libdbix-class-loader-perl_0.12-1_all.deb to pool/main/libd/libdbix-class-loader-perl/libdbix-class-loader-perl_0.12-1_all.deb libdbix-class-loader-perl_0.12.orig.tar.gz to pool/main/libd/libdbix-class-loader-perl/libdbix-class-loader-perl_0.12.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ccrypt 1.7-9 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 13 Jan 2006 08:37:26 +0100 Source: ccrypt Binary: ccrypt Architecture: source i386 Version: 1.7-9 Distribution: unstable Urgency: low Maintainer: Chris Vanden Berghe [EMAIL PROTECTED] Changed-By: Chris Vanden Berghe [EMAIL PROTECTED] Description: ccrypt - secure encryption and decryption of files and streams Closes: 347493 Changes: ccrypt (1.7-9) unstable; urgency=low . * added patch to fix unaligned references problems on IA64 (closes: #347493) * changed email address Files: c7084b08568670466cdbfb69576f3d25 561 utils optional ccrypt_1.7-9.dsc 32039882db891943f123536cc05496d6 4277 utils optional ccrypt_1.7-9.diff.gz dd4854ac34c84841240277d837861cce 70854 utils optional ccrypt_1.7-9_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDx29afs2tQGwAhPwRAsjMAJ9nXfhPGC6QW3qRAnr/EilXdXRiSACggso+ Pmd6Rft4m0LLjfaq0hy0Og0= =i3qL -END PGP SIGNATURE- Accepted: ccrypt_1.7-9.diff.gz to pool/main/c/ccrypt/ccrypt_1.7-9.diff.gz ccrypt_1.7-9.dsc to pool/main/c/ccrypt/ccrypt_1.7-9.dsc ccrypt_1.7-9_i386.deb to pool/main/c/ccrypt/ccrypt_1.7-9_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mped 3.3.17-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 13 Jan 2006 11:23:22 +0100 Source: mped Binary: mped Architecture: source i386 Version: 3.3.17-1 Distribution: unstable Urgency: low Maintainer: Roberto Suarez Soto [EMAIL PROTECTED] Changed-By: Roberto Suarez Soto [EMAIL PROTECTED] Description: mped - Minimum Profit, a programmer's text editor Closes: 344666 345312 Changes: mped (3.3.17-1) unstable; urgency=low . * New upstream release. * Removed notice about locales and moved to NEWS.Debian, so: Closes: #344666 * As we no longer use debconf, I have also to refuse Miloslav Kure's gentle Czech translation of debconf messages. Sorry :-) Closes: #345312 * As this mped is compiled with GTK+ support, the menu entry has been changed to execute it directly, instead of inside of x-terminal-emulator. Files: e915b1cfcb7e275507556d1f6d94a18d 602 editors optional mped_3.3.17-1.dsc 40574eb7272ab137fbc6d9d450b436eb 266368 editors optional mped_3.3.17.orig.tar.gz f8f2f5d46ec3ff207130411756c42178 6620 editors optional mped_3.3.17-1.diff.gz 59a5001cf3bd366abc3accc124f6126e 161196 editors optional mped_3.3.17-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDx4OQUD+pp6pCQbIRAjbjAKDEYdiiRuThrGfIOIshEx2sd+8+VACfbpia bJhX5Rr6yq89+VKsmRM1Fpw= =f5jF -END PGP SIGNATURE- Accepted: mped_3.3.17-1.diff.gz to pool/main/m/mped/mped_3.3.17-1.diff.gz mped_3.3.17-1.dsc to pool/main/m/mped/mped_3.3.17-1.dsc mped_3.3.17-1_i386.deb to pool/main/m/mped/mped_3.3.17-1_i386.deb mped_3.3.17.orig.tar.gz to pool/main/m/mped/mped_3.3.17.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
