ya sabes que es gubiz.com?
Si no puedes ver las imágenes, Haz Clic Aquí http://www.gubiz.com/images/email/prospectos1/prospectos1.html https://www.gubiz.com/Inscripcion.aspx?utm_source=prpospectosutm_mediu m=cpcutm_medium=cpcutm_content=bannerlinkutm_campaign=prospectos1 http://targetimages.bfi0.com/common/spacer.gif Vende y Compra lo que tengas en mente! Gubiz.com es el primer mercado virtual de Guatemala donde podrás vender, regatear y comprar artículos nuevos y usados. Más de 6800 artículos a la venta y miles de ventas exitosas hacen de gubiz.com el mejor sitio de venta y compra por internet en Guatemala. Si aún no eres parte de Gubiz.com, Inscríbete hoy mismo https://www.gubiz.com/Inscripcion.aspx?utm_source=prpospectosutm_mediu m=cpcutm_medium=cpcutm_content=bannerlinkutm_campaign=prospectos1 ! inscribete GRATIS https://www.gubiz.com/Inscripcion.aspx?utm_source=prpospectosutm_mediu m=cpcutm_medium=cpcutm_content=bannerlinkutm_campaign=prospectos1 hogar https://www.gubiz.com/Inscripcion.aspx?utm_source=prpospectosutm_mediu m=cpcutm_medium=cpcutm_content=bannerlinkutm_campaign=prospectos1 hogar https://www.gubiz.com/Inscripcion.aspx?utm_source=prpospectosutm_mediu m=cpcutm_medium=cpcutm_content=bannerlinkutm_campaign=prospectos1 autos https://www.gubiz.com/Inscripcion.aspx?utm_source=prpospectosutm_mediu m=cpcutm_medium=cpcutm_content=bannerlinkutm_campaign=prospectos1 macotas https://www.gubiz.com/Inscripcion.aspx?utm_source=prpospectosutm_mediu m=cpcutm_medium=cpcutm_content=bannerlinkutm_campaign=prospectos1 varios https://www.gubiz.com/Inscripcion.aspx?utm_source=prpospectosutm_mediu m=cpcutm_medium=cpcutm_content=bannerlinkutm_campaign=prospectos1 industria https://www.gubiz.com/Inscripcion.aspx?utm_source=prpospectosutm_mediu m=cpcutm_medium=cpcutm_content=bannerlinkutm_campaign=prospectos1 http://targetimages.bfi0.com/common/spacer.gif Gubiz.Com https://www.gubiz.com/Inscripcion.aspx?utm_source=prpospectosutm_mediu m=cpcutm_medium=cpcutm_content=bannerlinkutm_campaign=prospectos1 compra y vende lo que tengas en mente Si no quieres recibir mas información de gubiz.com escribenos a [EMAIL PROTECTED]
Re: Best practices for cron jobs?
Hi Duncan! You wrote: Adding a sleep $[ $RANDOM % 60 ] is probably not a good idea as it will hold up all the other cronjobs that should be run. What about making sure the spamassassin cron.daily job is the last one to run (by calling it ZZspamassassin or so)? It might even be worth it to put the random wait in its own /etc/cron.daily/ZZ_randomwait, so that other packages could also benefit from the same construction. Regards, Bas. -- +--+ | Bas Zoetekouw | Sweet day, so cool, so calm, so bright, | || The bridall of the earth and skie: | | [EMAIL PROTECTED] | The dew shall weep thy fall tonight;| +|For thou must die. | +-+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Tuesday 12 June 2007 19:57, Joey Hess wrote: I had generally assumed that most programmers were reaonsable and used powers of 2, but this thread is certianly changing my mind about *that*. It's not that unreasonable. Humans generally count in base 10 - computers count in base 2. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) Exim is better at being younger, whereas sendmail is better for Scrabble (50 point bonus for clearing your rack) -- Dave Evans pgppaW9Zr6ibG.pgp Description: PGP signature
Bug#428643: ITP: maven-ant-helper -- package helper scripts for building Maven components with ant
Package: wnpp Severity: wishlist Owner: Paul Cager [EMAIL PROTECTED] * Package name: maven-ant-helper Version : 1.0 Upstream Author : Trygve Laugstøl [EMAIL PROTECTED] * URL : http://svn.debian.org/wsvn/pkg-java/trunk/maven-ant-helper * License : Apache Programming Lang: Java Description : package helper scripts for building Maven components with ant An environment that can be used to simplify the creation of Debian packages to support the Maven system. A modello ant task is also provided. . Homepage: http://svn.debian.org/wsvn/pkg-java/trunk/maven-ant-helper -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
* Lucas Nussbaum ([EMAIL PROTECTED]) [070612 23:17]: On 12/06/07 at 22:23 +0200, Luk Claes wrote: NO! unstable is meant for packages that should be in the next stable release, as such only packages that are in the maintainer's opinion ready to migrate to testing should be uploaded to unstable. Then shouldn't we have a more aggressive policy about removals from unstable, for packages that have failed to get into testing during the past n months ? We have that policy, just nobody who does the QA-bits needed to make that happen. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Wed, Jun 13, 2007 at 12:42:34AM +0100, Luis Matos wrote: - Smooth passages are not always smooth (who had a working xorg after the upgrade for 7, please raise their hands) AFAIR apart from having to edit a few config files it was quite painless (I've upgraded when Xorg was still in experimental). OTOH the current xserver-xorg-video-ati snapshot in experimental is not suitable for everyday use (the crash in DPMS is a blocker for me) so I'd be quite annoyed if it was uploaded to unstable; but being able to easily test new versions to see if the bugs are still there is very useful. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Tue, Jun 12, 2007 at 05:40:29PM -0300, Gustavo Franco wrote: I disagree, that's what we've with experimental today mainly due to the fact that there's just a few packages there. Consider everybody uploading every package for unstable instead. Experimental can and does contain packages that are _known_ to be broken and unusable. Uploading these to unstable would mean that no one would test unstable any more (right now you can _decide_ if you want to risk installing known-broken packages from experimental; removing experimental also removes that choice). And if no one tests unstable because it's just too broken, then bugs will not be found before packages migrate to testing (the method of migration, being manual or automatic does not matter here at ALL), meaning the quality of testing would drop significantly. I don't see that as an improvement... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Best practices for cron jobs?
On Wed, Jun 13, 2007 at 12:28:09AM -0400, Duncan Findlay wrote: What can I do to satisfy those with and without anacron, and to avoid hammering the sa-update servers at a specific time? Idea: - Generate a random minute number in the postinst - Set up an entry in cron.d that runs every hour at the above specified minute and calls a helper script that checks if the last invocation of sa-update was more than 23 hours ago (using a timestamp file) and if so calls sa-update Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: Two proposals for a better Lenny (testing related).
Ter, 2007-06-12 às 17:03 -0700, Steve Langasek escreveu: On Wed, Jun 13, 2007 at 12:42:34AM +0100, Luis Matos wrote: Ter, 2007-06-12 às 22:05 +0200, Frans Pop escreveu: Personally I think the current system is fine. just a note, as user: The current system is fine but: - priority from unstable should less than testing or stable ( as i think - not for sure - happens nowadays). On experimental has less priority. - There are no guaranties that testing is always working and stable. - there are no guaranties that testing is secure (please security team, can you clarify this?) You won't find a contractual guarantee from Debian about either of these things, for *any* of the Debian suites. look ... i don't want guaranties ... you know what i mean ... want a place where it says testing HAS security support, we focus on having it stable. I don't want written contract ... i want a desktop user to discard stable and use testing. For that debian needs do publicly advice the use of testing in these cases ... and i mean for real. There is a testing security team that addresses unembargoed security issues in testing. Fixes for embargoed security issues are generally not prepared in advance for testing. However, more people have access to work on the unembargoed security issues anyway (in the general case: anyone can upload to t-p-u), so it's not definite that stable is always more secure than testing. So, maybe, have more strict upload rules? Or, on the other way, maintainers can upload packages directly into testing (from t-p-u?). - There are no public, announced, snapshots from testing (so people can download and install). Other than the d-i betas? yes ... for example, every 6 months ... all teams can organize to ship a preview release of debian. Teams will know that day X at Y time full set of cd's will be built. so teams will have +/- stable packages in testing and debian will have an automatic version. d-i per se is not a debian release. This will give users another view of debian. For example, debian lenny preview A would be announced and people would install it and test it. Otherwise, no one will use it. - Testing simply moves too fast and the automatically passage process between unstble and testing *DOES* break testing. For one example, package foo requires package bar=0.3 but package bar 0.4 automatically passes to testing. Um, no. That does not happen automatically. In rare cases it happens because the release team has overridden the installability check for a package, because maintainers have not coordinated their transitions in unstable and as a result something needs to be broken to ever get any of the packages updated because you can't get 300 maintainers to get their packages in a releasable state *and* leave them alone long enough to transition to testing as a group. So please, don't do those oh, let them pass transitions ... they BREAK stuff ... for real. (... and this is why getting rid of experimental is a horrible idea.) i think we cannot give up of experimental ... it's a place for ... experimental packages and preview packages (samba 4, for example), - Smooth passages are not always smooth (who had a working xorg after the upgrade for 7, please raise their hands) raises hand you lucky person. :) - kernel modules simply die, when the kernel is upgraded, but the modules aren't ( people using non-free nvidia modules, raise their hands; people using wifi modules raise their hands) That's a problem of the packaging of those kernel modules, then, not a problem of testing per se; even if you track stable and therefore the problem only affects you once every two years, it's still a problem that should be addressed -- e.g., with metapackages like nvidia-kernel-2.6-686 (oh look, this one already exists). kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in time (they are not free, right?) ... kernel passes to testing ... automatically, the nvidia-module-2.6.50 uses 2.6.50 and not *.51, so ... after a reboot, my xorg server will not run... when it used to. this is a simple upgrade ... because kernel packages are always NEW, the kernel will pass because it has no reverse dependency problems in testing. And, just a note ... we are talking about testing, not stable. So ... automatically pass to testing ... is bad. Invalid premise - invalid conclusion. it's not invalid ... it's valid by the reasons above. So ... more package tests are need (such as test reverse depends) What do you mean? i mean that the passage f packages from unstable to testing needs to be more difficult. for example, if a package has, for example, important or serious bugs, should not pass to testing,even if it has security issues ... because it will break testing. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it
Re: Two proposals for a better Lenny (testing related).
On Wed, Jun 13, 2007 at 11:28:52AM +0100, Luis Matos wrote: kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in time (they are not free, right?) ... kernel passes to testing ... automatically, the nvidia-module-2.6.50 uses 2.6.50 and not *.51, so ... after a reboot, my xorg server will not run... when it used to. Then create an empty nvidia-module package that depends on the latest nvidia-module-X.Y.Z package and conflicts with linux-image-$ARCH X.Y.Z. Just because you're using non-free kernel modules does not mean that everyone else _not_ using those modules should be penalized. Or alternatively, just reboot with the old kernel just like you'd do when you found out that any random driver you happen depend on stops working in the new kernel version. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Wed, Jun 13, 2007 at 11:28:52AM +0100, Luis Matos wrote: The current system is fine but: - priority from unstable should less than testing or stable ( as i think - not for sure - happens nowadays). On experimental has less priority. - There are no guaranties that testing is always working and stable. - there are no guaranties that testing is secure (please security team, can you clarify this?) You won't find a contractual guarantee from Debian about either of these things, for *any* of the Debian suites. look ... i don't want guaranties ... you know what i mean ... want a place where it says testing HAS security support, we focus on having it stable. I don't want written contract ... i want a desktop user to discard stable and use testing. For that debian needs do publicly advice the use of testing in these cases ... and i mean for real. You are never going to get a statement from the Debian project telling users to use one suite or another (or at least, you shouldn't); the most we should be doing is giving users a list of pros and cons for each suite and letting them decide which fits their needs. I'm all in favor of reducing the number of decisions users have to make *in the software* :), but on something as high-level as which distro/suite to use, misestimating a user's needs is the kind of thing that will sour the user on Debian for a very long time. There is a testing security team that addresses unembargoed security issues in testing. Fixes for embargoed security issues are generally not prepared in advance for testing. However, more people have access to work on the unembargoed security issues anyway (in the general case: anyone can upload to t-p-u), so it's not definite that stable is always more secure than testing. So, maybe, have more strict upload rules? Or, on the other way, maintainers can upload packages directly into testing (from t-p-u?). More strict upload rules for what? - Testing simply moves too fast and the automatically passage process between unstble and testing *DOES* break testing. For one example, package foo requires package bar=0.3 but package bar 0.4 automatically passes to testing. Um, no. That does not happen automatically. In rare cases it happens because the release team has overridden the installability check for a package, because maintainers have not coordinated their transitions in unstable and as a result something needs to be broken to ever get any of the packages updated because you can't get 300 maintainers to get their packages in a releasable state *and* leave them alone long enough to transition to testing as a group. So please, don't do those oh, let them pass transitions ... they BREAK stuff ... for real. What? That's a problem of the packaging of those kernel modules, then, not a problem of testing per se; even if you track stable and therefore the problem only affects you once every two years, it's still a problem that should be addressed -- e.g., with metapackages like nvidia-kernel-2.6-686 (oh look, this one already exists). kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in time (they are not free, right?) ... kernel passes to testing ... That doesn't happen. this is a simple upgrade ... because kernel packages are always NEW, the kernel will pass because it has no reverse dependency problems in testing. False. -- 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reasonable maximum package size ?
Wouter Verhelst dijo [Sun, Jun 10, 2007 at 06:59:49PM +0100]: Honnestly, no, this is not true anymore nowadays. With a 500Gb sata hard drive, you're able to have a full debian mirror (all archs). Such a disk is around 100??? nowadays. ... but it will break down in three months with the typical usage pattern of a public Debian mirror. ftp.mx.debian.org has three desktop-class hard drives, which have faithfully served for ~1.5 years. We recently had hardware failures, but more related to the aging machine (a 450MHz Pentium II) than to the disks - And yes, we are getting a new machine :) Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On 6/12/07, Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Jun 12, 2007 at 04:40:54PM -0300, Gustavo Franco wrote: * What do you mean by switch unstable automatic nature to not automatic In a few words, move the 'NotAutomatic: yes' from experimental to unstable and burn experimental. So in your opinion, the glibc maintainers should upload glibc 2.6-0exp2 to unstable? Today, no? In a new scenario where unstable isn't automatic? Yes. Shall we try it and see whether all the release team quits in frustration and disgust, making lenny's release cycle the longest ever? FUD. regards, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Tue, 2007-06-12 at 15:52 +0100, Ian Jackson wrote: shirish writes (Using standardized SI prefixes): Please look at http://en.wikipedia.org/wiki/Binary_prefix . Urgh, these things are ugly and an abomination. We should avoid them. Ian. I'd really like to hear some real arguments against SI prefixes, besides being ugly or funny to pronounce or just because it has always been like that. Advantages of using SI prefixes has been mentioned in this thread. Please tell me the disadvantages so there can actually be a constructive discussion. Christof Krüger
Re: Two proposals for a better Lenny (testing related).
Gustavo Franco [EMAIL PROTECTED] writes: On 6/12/07, Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Jun 12, 2007 at 04:40:54PM -0300, Gustavo Franco wrote: * What do you mean by switch unstable automatic nature to not automatic In a few words, move the 'NotAutomatic: yes' from experimental to unstable and burn experimental. So in your opinion, the glibc maintainers should upload glibc 2.6-0exp2 to unstable? Today, no? In a new scenario where unstable isn't automatic? Yes. That idea is so crappy that you should probably be hit over the head with a stick. Each shlib-bumping upload of glibc to unstable means that it needs to transition before all other r-deps can move to testing. Uploading experimental glibcs that are far from ready to unstable is the perfect way to get the release team to quit. Marc -- BOFH #287: Telecommunications is downshifting. pgpObT6G2RIwM.pgp Description: PGP signature
Re: Two proposals for a better Lenny (testing related).
On 13/06/07 at 11:19 +0200, Andreas Barth wrote: * Lucas Nussbaum ([EMAIL PROTECTED]) [070612 23:17]: On 12/06/07 at 22:23 +0200, Luk Claes wrote: NO! unstable is meant for packages that should be in the next stable release, as such only packages that are in the maintainer's opinion ready to migrate to testing should be uploaded to unstable. Then shouldn't we have a more aggressive policy about removals from unstable, for packages that have failed to get into testing during the past n months ? We have that policy, just nobody who does the QA-bits needed to make that happen. What would be those QA bits ? It would be easy to get the list of packages that haven't reached testing in the n months (and have been in debian for more than n months). I could even work on that during debconf, but then, there's the problem of knowing who has the authority to remove packages from unstable. Such tasks don't get you a lot of karma points, so, if removals are not requested by someone with authority (release team or ftpmaster), this will probably result in a lot of flames. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Wed, Jun 13, 2007 at 08:02:53AM -0300, Gustavo Franco wrote: On 6/12/07, Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Jun 12, 2007 at 04:40:54PM -0300, Gustavo Franco wrote: * What do you mean by switch unstable automatic nature to not automatic In a few words, move the 'NotAutomatic: yes' from experimental to unstable and burn experimental. So in your opinion, the glibc maintainers should upload glibc 2.6-0exp2 to unstable? Today, no? In a new scenario where unstable isn't automatic? Yes. ITYM in a scenario where we stop bothering to use britney for modular transitions into testing because it no longer works, and we replace it instead with a periodic forklift copy from unstable to testing with all bugs and all installability problems caused by builds, and while we're at it let's go back to causing it frozen, HTH HAND. Shall we try it and see whether all the release team quits in frustration and disgust, making lenny's release cycle the longest ever? FUD. My bad, let me try to eliminate the uncertainty: you're designing in a vacuum, you haven't bothered to inform yourself how testing works and therefore have failed to understand the consequences of your proposal in spite of my efforts to hint you in the right direction, and it's a dumb idea. -- 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Lucas Nussbaum [EMAIL PROTECTED] writes: On 13/06/07 at 11:19 +0200, Andreas Barth wrote: * Lucas Nussbaum ([EMAIL PROTECTED]) [070612 23:17]: On 12/06/07 at 22:23 +0200, Luk Claes wrote: unstable is meant for packages that should be in the next stable release, as such only packages that are in the maintainer's opinion ready to migrate to testing should be uploaded to unstable. Then shouldn't we have a more aggressive policy about removals from unstable, for packages that have failed to get into testing during the past n months ? We have that policy, just nobody who does the QA-bits needed to make that happen. What would be those QA bits ? Automatic checks and reports. It would be easy to get the list of packages that haven't reached testing in the n months (and have been in debian for more than n months). Yes. One would just need to do it (and decide some basic rules)... I could even work on that during debconf, but then, there's the problem of knowing who has the authority to remove packages from unstable. Such tasks don't get you a lot of karma points, so, if removals are not requested by someone with authority (release team or ftpmaster), this will probably result in a lot of flames. I think that a package that has been in unstable for a whole release cycle without entering testing should probably live in experimental or not in Debian at all. I guess that is something most people can agree on. Marc -- BOFH #337: the butane lighter causes the pincushioning pgpRPbtyZsE2b.pgp Description: PGP signature
Re: Using standardized SI prefixes
One more opinion: If you consider a number more relevant than its nearest power of 2, then somebody else will consider every digit of that number relevant. In that case, don't use rounding by SI/IEC prefixes at all. For an example see Bug #420716. The first number, where the difference between base 1024 and base 1000 results in a greater inaccuracy than rounding to the next power of 2, is 2^150 vs 10^45. According to the cited wikipedia article, SI and IEC prefixes roughly go only half as far. So the difference between SI and IEC prefixes is immaterial. Regards, Mark Weyer P.S.: I am not subscribed to the list -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
* Gustavo Franco [Mon, 11 Jun 2007 18:20:17 -0300]: * Switch unstable (release) for not automatic updates This seems like the key of your proposal, and this is, in simple words and AIUI, why it would not bring any improvements: - Our main objective is to have as few bugs in testing as possible, since testing is what becomes stable. - Our current way to achieve that is by extensive testing of unstable; as Joey Hess pointed out, most bug reports come from people using unstable, and we use those bug reports to keep packages in bad shape out of testing, and thus out of stable. - By swithing unstable to NotAutomatic, you expect to get more users of testing instead, thus getting more people to test testing, and find bugs *there*. Which is bad, because bugs are discovered *once the packages have entered testing*, which is too late. HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org — As the ship lay in Boston Harbor, a party the colonists dressed as red Indians boarded the vessel, behaved very rudely, and threw all the tea overboard, making the tea unsuitable for drinking. Even for Americans. -- George W. Banks in “Mary Poppins” -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wed, 2007-06-13 at 12:51 +0200, Christof Krüger wrote: On Tue, 2007-06-12 at 15:52 +0100, Ian Jackson wrote: shirish writes (Using standardized SI prefixes): Please look at http://en.wikipedia.org/wiki/Binary_prefix . Urgh, these things are ugly and an abomination. We should avoid them. I'd really like to hear some real arguments against SI prefixes, besides being ugly or funny to pronounce or just because it has always been like that. Advantages of using SI prefixes has been mentioned in this thread. Please tell me the disadvantages so there can actually be a constructive discussion. User Confusion. Most users do not know what a tebibyte is, and they do not care. They know that a terabyte is about a million million bytes, and that is sufficient. Since you're rounding anyway, the loss of accuracy between about a million million bytes and just over a million million bytes is not significant. Certainly not at the expense at having to teach users another new unit. Hard drives are bought in gigabytes, memory is bought in gigabytes, etc. Quoting the same figures with a different unit in the operating system is pedantry for its own sake. Users have already learnt that the term gigabyte is approximate. Introducing new units has only added confusion, rather than removed it. Before the new units, we all knew that 1GB was an approximate figure and likely to be (for bytes) based on a power of 2. Now we have figures quoted in GB and GiB, some of which are power of 10, some of which are power of 2. Some figures quoted in GiB are wrong, and should be in GB; likewise some in GB should be GiB. And we still have many figures in both GB and GiB which are neither of the two! Renaming the 1.44MB floppy helps in neither case; it is neither 1.44MB or 1.44MiB. One could name it the 1.4MB or 1.47MiB floppy and confuse everyone into thinking it's a different thing, of course. Or maybe it should be the 1,440KB floppy, or the 1,475KiB floppy? Neither of these help the situation. Without the binary unit to consider, when we quote a drive as 1TB, we know that it has *at least* 1,000,000,000,000 bytes available. Depending on the drive, it may have anywhere between this and 1,099,511,627,776 bytes available. It's actually more likely to have something strange like 1,024,000,000,000 available. (And none of this takes into account partitioning and filesystem overhead!) I see no problem with this 1TB quote being approximate. It's rounded anyway. If you really want to know how many bytes are available, you can use this great unit called the byte which is accurate and not subject to change[0]. Scott [0] Unless you're older than 25. -- Scott James Remnant Ubuntu Development Manager [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Using standardized SI prefixes
On 13/06/07, Christof Krüger [EMAIL PROTECTED] wrote: I'd really like to hear some real arguments against SI prefixes, besides being ugly or funny to pronounce or just because it has always been like that. Advantages of using SI prefixes has been mentioned in this thread. Please tell me the disadvantages so there can actually be a constructive discussion. So far in this discussion i honestly thought that the arguments against SI prefixes were too obvious to bother mentioning. Let me start with a dumb example: For a child or uninterested commoner that flying critter is simply a birdie. For those in the know exactly the same entity is a Falco peregrinus. Even if simply calling it birdie or perhaps falcon would be easier, more user friendly more understandable for everyone it simply would not be /correct/. Therefore it must stay Falco peregrinus in all contexts where really conveying information matters. Computers deal with numbers in base two. Humans deal with numbers in base 10. When computers and humans interact (on a technical level) humans must adapt to the computer, because computers can not. Dealing with chunks of data, addresses, registers, etc. has to be done in base 2. Even if 1024 is close enough to 10^3 for a PHB or marketing humanoid, that will never make those two numbers equal. And it must never be allowed to. Computers, computer designers, computer technicians and most computer programmers will always deal with the _real_ base 2 numbers like 1024. Another example. Pi is an irrational number starting with 3.14 Sure, it would be easier to standardize it to 3.00. Done deal. It would be easier to remember and more marketable. It would also be totally useless AND completely wrong. AFAIK some very dumb people actually managed to decree by law that pi was to equal 3. They had to stop doing that. In the same was as with pi redefining or standardizing kilobytes and megabytes would be totally useless AND completely wrong. Computers have always, do, and will continue to deal with their numbers along the progression of 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, etc... So, when dealing with computers, must we. One does not redefine Falco peregrinus to birdie because that would make it more understandable for the commoner. Ornithologists need it to stay Falco peregrinus in the future. One does not redefine pi to a value of 3 because that would make it more understandable for the commoner. Mathematicians, architects (and basically everyone else) need it to stay ~3.1415926535 in the future. One does not redefine kilobyte to mean 1000 (base 10) because that would make it more understandable for the commoner. Real computer people need it to stay 1024 (base 10). A well-known and very common trait of language is that one given word can often have more than one specific meaning. When this is the case you need a context to be sure. This is considered normal, and never a real problem. This should hold true regarding computers and counting as well. Finally a personal and subjective thought. At times one has to chose whether to oversimplify facts and information to the point where everyone understands it, (If this happens they DO NOT understand it; they are given the illusion of understanding) or whether to educate the public. I am very convinced the correct solution is always to educate the public. The world is not flat. The earth is not the center of the universe. Pi is not 3. A kilobyte is not 1000; it is 1024 because that is the way computers work. Regards, Bjørn Ingmar Berg -- blog.bergcube.net/
Bug#428676: ITP: snowballz -- fun RTS game featuring snowball fights with penguins
Package: wnpp Severity: wishlist Owner: Miriam Ruiz [EMAIL PROTECTED] * Package name: snowballz Version : 0.9.3 Upstream Author : Joey Marshall [EMAIL PROTECTED] Upstream Author : Matthew Marshall [EMAIL PROTECTED] * URL : http://joey101.net/snowballz/ * License : GPL Programming Lang: Python Description : fun RTS game featuring snowball fights with penguins Take command of your army of penguins as you blaze your path to victory! March through snow laden forests to conqueror new frontears and grow your small army. Ambush enemy lines with blasts of freezing snowballs. But don't neglect your home, invaders are just over the next snow drift! Gather fish for your cold penguins to munch on as they warm up in your cozy igloo. It's a snowy world you don't want to miss! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wed, 2007-06-13 at 15:01 +0100, Alex Jones wrote: 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no less. No it doesn't. The meaning of 1 TB depends on the context, and has always done so. Scott -- Scott James Remnant Ubuntu Development Manager [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Using standardized SI prefixes
Hallo, On 6/13/07, Scott James Remnant [EMAIL PROTECTED] wrote: The meaning of 1 TB depends on the context, and has always done so. Wrongly. -- -alex http://www.ventonegro.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On 6/13/07, Lucas Nussbaum [EMAIL PROTECTED] wrote: It would be easy to get the list of packages that haven't reached testing in the n months (and have been in debian for more than n months). Such a list exists: http://bjorn.haxx.se/debian/oldest.html -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wed, 2007-06-13 at 14:29 +0100, Scott James Remnant wrote: Without the binary unit to consider, when we quote a drive as 1TB, we know that it has *at least* 1,000,000,000,000 bytes available. Depending on the drive, it may have anywhere between this and 1,099,511,627,776 bytes available. It's actually more likely to have something strange like 1,024,000,000,000 available. 10% error is no good for me. You can continue to play the at least card, but what about when it's more important if it is at most something? And seeing as this error only goes up exponentially, at which prefix do you draw the line and say no more? And no-one uses floppy disks any more. Let's just bury them all and forget about them. :D I see no problem with this 1TB quote being approximate. It's rounded anyway. If you really want to know how many bytes are available, you can use this great unit called the byte which is accurate and not subject to change[0]. 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no less. If they want to actually put 1.024 TB on the disk then they can say 1 TB (approx.) like any other industry (detergent, bacon, etc.). -- Alex Jones http://alex.weej.com/
Re: Using standardized SI prefixes
On Wednesday 13 June 2007 15:29, Scott James Remnant wrote: On Wed, 2007-06-13 at 12:51 +0200, Christof Krüger wrote: On Tue, 2007-06-12 at 15:52 +0100, Ian Jackson wrote: [...] Please tell me the disadvantages so there can actually be a constructive discussion. User Confusion. Most users do not know what a tebibyte is, and they do not care. They know that a terabyte is about a million million bytes, and that is sufficient. Since you're rounding anyway, the loss of accuracy between about a million million bytes and just over a million million bytes is not significant. Certainly not at the expense at having to teach users another new unit. This is a hurdle to adoption, a one time cost. It is not an argument against IEC prefixes per se. The long-term benefits outweigh the costs, IMO. Hard drives are bought in gigabytes, memory is bought in gigabytes, etc. Quoting the same figures with a different unit in the operating system is pedantry for its own sake. Users have already learnt that the term gigabyte is approximate. No, it's not. It's ambiguous. A given number can be exact or approximate regardless of the unit. 1.0 GB can mean either 1.0·10^9 byte or 1.0·2^30 byte, but whether the real value is exactly one or the other or something near one or the Introducing new units has only added confusion, rather than removed it. New concepts can always cause initial confusion. Relearning is harder than learning something right from the beginning. The same argument has been used against metrication in the US. Again, it's a one-time cost. Before the new units, we all knew that 1GB was an approximate figure and likely to be (for bytes) based on a power of 2. Now we have figures quoted in GB and GiB, some of which are power of 10, some of which are power of 2. Some figures quoted in GiB are wrong, and should be in GB; likewise some in GB should be GiB. And we still have many figures in both GB and GiB which are neither of the two! You're talking a lot about approximation. If I understand you correctly, you're saying that any stated quantity of data must either be an exact number, e.g. 23 368 986 120 bytes, or an approximation with a single significant digit. That is *stupid*. You want to deny people the *possibility* of consistence, unambiguity and accuracy (without resorting to numbers on the form 3.1·10¹²), just because you won't think that you'll need that possibility most of the time. There *is* reason to state rounded numbers with two or three digits, in which case the difference between MB and MiB or GB and GiB definitely matters, and even with a single significant digit, 8 GiB (exactly) is 9 GB when rounded to the nearest whole number. Renaming the 1.44MB floppy helps in neither case; it is neither 1.44MB or 1.44MiB. One could name it the 1.4MB or 1.47MiB floppy and confuse everyone into thinking it's a different thing, of course. Or maybe it should be the 1,440KB floppy, or the 1,475KiB floppy? Neither of these help the situation. The 1 440 KiB floppy is dead. Let it rest in pieces. The fact that a marketing department screwed up long ago by thinking that 1 440 kB equals 1.44 MB, which it would have done, had that really *been* 1 440 kB and not 1 440 KiB, is not a case against IEC prefixes. On the contrary, it may well be a prime example of a confusion that wouldn't have happened if the IEC prefixes had been adopted by then. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpQnKqXRd0XO.pgp Description: PGP signature
Re: Getting package translations into the mirrors (was Re: APT 0.7 for sid)
On Sun, Jun 10, 2007 at 07:16:49PM +0200, Martijn van Oosterhout wrote: On 6/10/07, Frank Küster [EMAIL PROTECTED] wrote: That's because they're not the latest files. The latest output form the DDTP project is here: http://ddtp.debian.net/debian/dists/sid/main/i18n/ There have been requests to have the FTP site mirror from there or have some other mechanism to get the data to the main servers. As far as I know it needs an FTP master to fix. I understand the reason for it not having been done earlier was lack of support in apt? Have you submitted a bug against ftp.d.o? I couldn't find one. I havn't because I didn't think it was my problem. But I found it here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=109955 It's six years old, the URLs have changed but thats it. I came to this rather late so I don't know the story. Just google for apt-i18n brings up some stuff. There's this: http://lists.debian.org/debian-i18n/2006/06/msg00107.html http://lists.debian.org/debian-devel-announce/2006/06/msg3.html When I last asked about it I was told to wait, so I've done nothing. I've CCed grisu, perhaps he knows what's going on... Thanks for the info. I close the bug. The files are already on the ftp master (see ftp://ftp.debian.org/debian/dists/unstable/main/i18n/) as translation files. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Ziemlich viele Firmen, die alle kein Linux benutzen, würden nach Abschaltung der Linux-Rechner erst mal ins Schwimmen kommen. -- Matthias Peick pgpTY1wj54j1F.pgp Description: PGP signature
Re: Two proposals for a better Lenny (testing related).
On 13/06/07 at 15:19 +0100, Paul Wise wrote: On 6/13/07, Lucas Nussbaum [EMAIL PROTECTED] wrote: It would be easy to get the list of packages that haven't reached testing in the n months (and have been in debian for more than n months). Such a list exists: http://bjorn.haxx.se/debian/oldest.html Yes, but there's a bug. Let's take eglade as an example. The list says 1341 days. Actually, it is 1341 days since that package last entered testing. But it was in testing on 2006-11-20 (it was removed from testing on 2006-11-21). Which is much shorter than 1341 days, and also more acceptable. The correct fix for this would probably be to analyze the Sources files on snapshot.d.n... -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Lucas Nussbaum [EMAIL PROTECTED] writes: On 13/06/07 at 15:19 +0100, Paul Wise wrote: On 6/13/07, Lucas Nussbaum [EMAIL PROTECTED] wrote: It would be easy to get the list of packages that haven't reached testing in the n months (and have been in debian for more than n months). Such a list exists: http://bjorn.haxx.se/debian/oldest.html Yes, but there's a bug. Let's take eglade as an example. The list says 1341 days. Actually, it is 1341 days since that package last entered testing. But it was in testing on 2006-11-20 (it was removed from testing on 2006-11-21). Which is much shorter than 1341 days, and also more acceptable. Yeah, but I guess you need to ignore that day anyway, because I seem to remember that this was a britney problem that marked all packages as rc-bug-free or something. Marc -- Fachbegriffe der Informatik - Einfach erklärt 134: Benutzerfreundlichkeit Der Benutzer hat zum Admin freundlich zu sein. (Thorsten Fenk) pgpuPk4XvlAdY.pgp Description: PGP signature
Re: Using standardized SI prefixes
On Wed, 2007-06-13 at 12:51 +0200, Christof Krüger wrote: On Tue, 2007-06-12 at 15:52 +0100, Ian Jackson wrote: shirish writes (Using standardized SI prefixes): Please look at http://en.wikipedia.org/wiki/Binary_prefix . Urgh, these things are ugly and an abomination. We should avoid them. I'd really like to hear some real arguments against SI prefixes, besides being ugly or funny to pronounce or just because it has always been like that. Advantages of using SI prefixes has been mentioned in this thread. Please tell me the disadvantages so there can actually be a constructive discussion. User Confusion. Most users do not know what a tebibyte is, and they do not care. They know that a terabyte is about a million million bytes, and that is sufficient. Since you're rounding anyway, the loss of accuracy between about a million million bytes and just over a million million bytes is not significant. Certainly not at the expense at having to teach users another new unit. Hard drives are bought in gigabytes, memory is bought in gigabytes, etc. Quoting the same figures with a different unit in the operating system is pedantry for its own sake. Users have already learnt that the term gigabyte is approximate. Wrong most users think of gigabyte as absolute rather than approximation. If that was not the case then http://en.wikipedia.org/wiki/Binary_prefix#Legal_disputes wouldn't have happened. Most of the users when they burn a CD/DVD use the approximation GB to say a burn a movie DVD. Most of the DVD media is marketted as 4.78 GB while its 4.38 GiB hence when they download a movie (legally downloaded or otherwise) or do mixed mode stuff. Also I don't know many users who go down to byte-size level see how much space is remaining. I do get support calls over this quite a bit. Thinking that users know its an approximate IMHO is an oversimplification. Introducing new units has only added confusion, rather than removed it. The same could be said of relatively newer concepts like free software, open source, copyright, creative licenses, .PNG, .SVG all the newer stuff that the web keeps pouring in. Micro formats anyone. That doesn't mean we stop learning, it just means we adjust ourselves to the new reality. Before the new units, we all knew that 1GB was an approximate figure and likely to be (for bytes) based on a power of 2. Now we have figures quoted in GB and GiB, some of which are power of 10, some of which are power of 2. Some figures quoted in GiB are wrong, and should be in GB; likewise some in GB should be GiB. And we still have many figures in both GB and GiB which are neither of the two! Renaming the 1.44MB floppy helps in neither case; it is neither 1.44MB or 1.44MiB. One could name it the 1.4MB or 1.47MiB floppy and confuse everyone into thinking it's a different thing, of course. Or maybe it should be the 1,440KB floppy, or the 1,475KiB floppy? Neither of these help the situation. Right, although it doesn't completely solve the situation it does take things to a nearer perfect answer. I do see that it would take time for us to make that change but its a better change IMO. Without the binary unit to consider, when we quote a drive as 1TB, we know that it has *at least* 1,000,000,000,000 bytes available. Depending on the drive, it may have anywhere between this and 1,099,511,627,776 bytes available. It's actually more likely to have something strange like 1,024,000,000,000 available. (And none of this takes into account partitioning and filesystem overhead!) I see no problem with this 1TB quote being approximate. It's rounded anyway. If you really want to know how many bytes are available, you can use this great unit called the byte which is accurate and not subject to change[0]. Do you think most common users are ever going to go down to byte size level to see if things fit or not. It would actually be a good test for Novell . I believe they do desktop tests for HIG see how users actually do stuff. Not techies but day-to-day the Johns Janes. Scott [0] Unless you're older than 25. -- Scott James Remnant Ubuntu Development Manager [EMAIL PROTECTED] Cheers -- Shirish Agarwal This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/ 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17
Re: Using standardized SI prefixes
I demand that Alex Jones may or may not have written... And no-one uses floppy disks any more. Let's just bury them all and forget about them. :D I used one yesterday to do a BIOS upgrade. :-) 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no less. It means 1024^4 bytes, no more and no less. :-þ -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | URL:http://www.youmustbejoking.demon.co.uk/progs.packages.html We'll get along fine as soon as you realise that I'm God!
Re: Using standardized SI prefixes
On Wednesday 13 June 2007 15:19, Bjørn Ingmar Berg wrote: Let me start with a dumb example: (OK, dumb example duly deleted) Computers deal with numbers in base two. Humans deal with numbers in base 10. When computers and humans interact (on a technical level) humans must adapt to the computer, because computers can not. I don't agree with that. Compilers generally understand numbers in base 10, for example. More about that later. Dealing with chunks of data, addresses, registers, etc. has to be done in base 2. Even if 1024 is close enough to 10^3 for a PHB or marketing humanoid, that will never make those two numbers equal. And it must never be allowed to. Computers, computer designers, computer technicians and most computer programmers will always deal with the _real_ base 2 numbers like 1024. So? This is why there needs to be a separate set of prefixes for powers of 2. As for that falcon, it's just another example of why there needs to be a well-defined vocabulary even if the common people don't care about the details. Another example. Pi is an irrational number starting with 3.14 Sure, it would be easier to standardize it to 3.00. Done deal. It would be easier to remember and more marketable. It would also be totally useless AND completely wrong. AFAIK some very dumb people actually managed to decree by law that pi was to equal 3. They had to stop doing that. In the same was as with pi redefining or standardizing kilobytes and megabytes would be totally useless AND completely wrong. Computers have always, do, and will continue to deal with their numbers along the progression of 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, etc... So, when dealing with computers, must we. Again, computers are perfectly capable of presenting numbers in base ten or any other base, depending on what is most convenient. Otherwise we might have been forced to input numbers in binary and get answers like Total distance: 10011.1 km back (with k meaning 2^10, of course). That SI prefixes have been used to express powers of two is more specifically an artifact of memory addressing. The sizes of memory banks are normally a power of two. In that case it's convenient to say that the memory capacity is 64 MiB when you mean that it's 67 108 864 byte. But for data on a wire, or even files on a disk, there isn't anything constraining sizes to a power of two (block sizes are a number of KiB, but you rarely need to think of that as a user). One does not redefine pi to a value of 3 because that would make it more understandable for the commoner. Mathematicians, architects (and basically everyone else) need it to stay ~3.1415926535 in the future. One does not redefine kilobyte to mean 1000 (base 10) because that would make it more understandable for the commoner. Real computer people need it to stay 1024 (base 10). It's not about redefining kilobyte to mean 1000, because, as has been pointed out repeatedly, a kilobyte is currently either 1000 byte or 1024 byte depending on context. There is no exact definition, just a rather vague convention. This is about once and for all ending that mess. Your analogy with redefining pi as exactly 3 is way off, because pi is a natural constant and as such has been defined since the beginning of time. Redefining pi would be like trying to alter the shape of the universe or the laws of nature. Deciding that SI prefixes shall be SI prefixes even in computer context is not like trying to strip 24 bytes off every block of 1024, or mandating that computers always have to use BCD internally. A well-known and very common trait of language is that one given word can often have more than one specific meaning. When this is the case you need a context to be sure. This is considered normal, and never a real problem. This should hold true regarding computers and counting as well. That doesn't make vagueness and ambiguity *desirable*. It is common to have a well-defined terminology wherever people need to communicate efficiently without misunderstandings. Two examples are the SI units and prefixes. Finally a personal and subjective thought. At times one has to chose whether to oversimplify facts and information to the point where everyone understands it, (If this happens they DO NOT understand it; they are given the illusion of understanding) or whether to educate the public. I am very convinced the correct solution is always to educate the public. Good. Let's then teach the public that borrowing well-defined SI prefixes and giving them a different meaning in some situations was a bad idea, and that an adequate solution exists. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgp3oIOldbVpg.pgp Description: PGP signature
How to package software with binaries in tarball?
Hi! What is a recommended practice of packaging programs, for which distributed tarball contains binaries (generated from the sources)? Specifically, newly released erlang distribution includes prebuilt architecture-independent binary files. Should we remove them from the original tarball, or is it better to leave them? Best wishes! -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to package software with binaries in tarball?
Sergei Golovan [EMAIL PROTECTED] wrote: What is a recommended practice of packaging programs, for which distributed tarball contains binaries (generated from the sources)? Specifically, newly released erlang distribution includes prebuilt architecture-independent binary files. Should we remove them from the original tarball, or is it better to leave them? Unless there is a huge a gain in tarball size I would keep the pristine source. It is rather nice to be able take debian's tar.gz and verify with md5sum or a detached gpg sig that upstream's tarball is identical. OTOH if I needed to repackaged the source tarball anyway since it contains non DFSG free material I would remove the binaries too. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to package software with binaries in tarball?
On 6/13/07, Andreas Metzler [EMAIL PROTECTED] wrote: Should we remove them from the original tarball, or is it better to leave them? Unless there is a huge a gain in tarball size I would keep the Tarball without binaries is about 11Mb, with binaries is about 37Mb. pristine source. It is rather nice to be able take debian's tar.gz and verify with md5sum or a detached gpg sig that upstream's tarball is The original tarball contains non-free RFCs, so it is recreated anyway. identical. OTOH if I needed to repackaged the source tarball anyway since it contains non DFSG free material I would remove the binaries too. OK. I see your point. Thanks! -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Mike Hommey wrote: On Tue, Jun 12, 2007 at 09:25:13PM +, Evgeni Golov [EMAIL PROTECTED] wrote: On Tue, 12 Jun 2007 15:42:08 -0300 Paulo Marcondes wrote: billion = 10^6 * 10^6 (IIRC, as used in Portugal - no jokes here!) =10^12 :) and Germany, France, former UdSSR, insert your country here Anywhere where milliard is 10^9, basically... Which includes England, according to Merriam-Webster [1]. The Spanish Royal Academy also defines[2] it as 10^12, which would mean every Spanish speaking country uses that definition too. [1] http://www.m-w.com/mw/table/number.htm [2] http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3LEMA=bill%F3n -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Let me start with a dumb example: For a child or uninterested commoner that flying critter is simply a birdie. For those in the know exactly the same entity is a Falco peregrinus. Even if simply calling it birdie or perhaps falcon would be easier, more user friendly more understandable for everyone it simply would not be /correct/. The word birdie is a generalization of quite every critter that can fly. So it is correct, the critter Falco peregrinus is a birdie, too. Calling this critter falco peregrinus is correct, too. The example just doesn't apply here because KB is not a generalization of KiB and vice versa. Computers deal with numbers in base two. Humans deal with numbers in base 10. When computers and humans interact (on a technical level) humans must adapt to the computer, because computers can not. Dealing with chunks of data, addresses, registers, etc. has to be done in base 2. Even if 1024 is close enough to 10^3 for a PHB or marketing humanoid, that will never make those two numbers equal. Right, and this is the reason why having the same name for different things is not good. And it must never be allowed to. Computers, computer designers, computer technicians and most computer programmers will always deal with the _real_ base 2 numbers like 1024. Unfortunately, computer designers, technicians etc. are not living in an isolated world (well.. maybe some of them). No one wants to forbid the computer people to use base 2 numbers. They are just asked to write KiB instead of KB if they mean base 2 quantities, because the rest of the world already uses kilo as 1000. Changing the rest of the world makes no sense and having distinct names for distinct thing does no harm. Another example. Pi is an irrational number starting with 3.14 Sure, it would be easier to standardize it to 3.00. Done deal. It would be easier to remember and more marketable. It would also be totally useless AND completely wrong. AFAIK some very dumb people actually managed to decree by law that pi was to equal 3. They had to stop doing that. Well, another example that does not apply here. Nobody wants to change something true to something wrong. The status quo is that KB can mean either 1000 or 1024 bytes depending on the context (or shoe size of the developer or whatever). So there is an ambiguity here. Introducing SI prefixes would eliminate ambiguities if applied consistently. Pi is well defined. There is no ambiguity. Computers have always, do, and will continue to deal with their numbers along the progression of 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, etc... So, when dealing with computers, must we. Yup, I totally agree. But why do we call it kilo then, when we actually mean 1024? Someone found it handy dozens of years ago and everybody has adapted it. So back then, someone was redefining your pi to 3 because it was close enough and now we should leave it this way? Remember that until computers have been invented (or binary logic), kilo has always meant 1000. A well-known and very common trait of language is that one given word can often have more than one specific meaning. When this is the case you need a context to be sure. This is considered normal, and never a real problem. This should hold true regarding computers and counting as well. This is called a homograph. An example taken from wikipedia: shift n. (a change) shift n. (a period at work) I agree that in normal life you can guess the meaning from the context because it has completely different meanings. However, I don't agree that this should hold true in computer science. One possible meaning of KB is 1000 bytes. The other is 1024 bytes. Now take the sentence: Hello John. I've got a file here and want to send it to you. It's 25KB large. Now please extract from the context which meaning is significant here? The problem is that the both possible meanings depict exactly the same: a quantity of bytes. Finally a personal and subjective thought. At times one has to chose whether to oversimplify facts and information to the point where everyone understands it, (If this happens they DO NOT understand it; they are given the illusion of understanding) or whether to educate the public. I think that you base your argumentation on wrong assumptions. The purpose of introducing SI prefixes is *not* to make the newbie's life simpler, at least not as primary goal. Surely, there are situations where it really doesn't matter (e.g. if you are interested in the order of magnitude 10% error may be totally acceptable). However, SI prefixes make life easier for technical stuff where it is important to be exact without having to guess the context, ask every time or consider the professional background of your communication partner. Regards, Christof Krüger
Re: Using standardized SI prefixes
On Wed, 2007-06-13 at 14:08 -0400, Felipe Sateler wrote: Mike Hommey wrote: On Tue, Jun 12, 2007 at 09:25:13PM +, Evgeni Golov [EMAIL PROTECTED] wrote: On Tue, 12 Jun 2007 15:42:08 -0300 Paulo Marcondes wrote: billion = 10^6 * 10^6 (IIRC, as used in Portugal - no jokes here!) =10^12 :) and Germany, France, former UdSSR, insert your country here Anywhere where milliard is 10^9, basically... Which includes England, according to Merriam-Webster [1]. [...] [1] http://www.m-w.com/mw/table/number.htm The American usage has been becoming more common in England (and the rest of Britain :-) over the past few years, particularly in science and finance related usage. I could be wrong, but I suspect most British people have never even heard of a milliard. It's usually referred to either as a billion or an American billion. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Le mercredi 13 juin 2007 à 15:06 +0100, Scott James Remnant a écrit : On Wed, 2007-06-13 at 15:01 +0100, Alex Jones wrote: 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no less. No it doesn't. The meaning of 1 TB depends on the context, and has always done so. The meaning of 1 TB is approximate only for approximate people. I'd expect more rigor from people working in computer science (if we can call it a science). -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Best practices for cron jobs?
On Wednesday 13 June 2007 06:28:09 Duncan Findlay wrote: I imagine it would be relatively simple to have the postinst generate a random time during the day for a cron script to run, but this doesn't work with anacron -- many users would never get updates. how would this break anacron? What can I do to satisfy those with and without anacron, and to avoid hammering the sa-update servers at a specific time? personally, i would do something like this: - generate the crontab with a random hour/minute into a temp file - register the temp file /etc/cron.d/yourpackage via ucf sean signature.asc Description: This is a digitally signed message part.
Re: Best practices for cron jobs?
* sean finney [Wed, 13 Jun 2007 20:46:42 +0200]: On Wednesday 13 June 2007 06:28:09 Duncan Findlay wrote: I imagine it would be relatively simple to have the postinst generate a random time during the day for a cron script to run, but this doesn't work with anacron -- many users would never get updates. how would this break anacron? Because anacron can't run stuff only present in /etc/cron.d. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org As scarce as truth is, the supply has always been in excess of the demand. -- Josh Billings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Christof Krüger [EMAIL PROTECTED] writes: I'd really like to hear some real arguments against SI prefixes, besides being ugly or funny to pronounce or just because it has always been like that. Advantages of using SI prefixes has been mentioned in this thread. Please tell me the disadvantages so there can actually be a constructive discussion. Trying to change every piece of software in existence is a waste of time and energy for a problem that isn't that serious. IMO, that's the *real* objection; most of the arguments are justifications for that position or are about things that we'd get over if this issue were addressed (like the silly words -- there are sillier words in English that just don't sound that way because we're used to them). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Best practices for cron jobs?
Duncan Findlay wrote: Adding a sleep $[ $RANDOM % 60 ] is probably not a good idea as it will hold up all the other cronjobs that should be run. How about using a sub shell, so that other cron jobs can continue? ( sleep $[ $RANDOM % 60 ] sa-update ) (or something like this) Cheers Jan-Pascal signature.asc Description: OpenPGP digital signature
Re: Using standardized SI prefixes
On Wed, 2007-06-13 at 14:29 +0100, Scott James Remnant wrote: [...] And we still have many figures in both GB and GiB which are neither of the two! okay ... reading on ... [...] I see no problem with this 1TB quote being approximate. It's rounded anyway. So you don't care if it is approximate? Then you should care less if it's even exact! However, I find that tebibyte, gibibyte, mebibyte and kibibyte sound quite familiar to their base-10 friends so that it should be no problem even for a dumb user to understand its meaning if he already knew what a gigabyte or megabyte is. This is especially the case with the short notation (e.g. KiB vs. KB). The more important case is when a user actually *cares* about the exact number. At the moment base 10 and base 2 numbers are often prefixed both with k for kilo, M for mega etc. This means that there will be confusion if something is labeled 100GB. Now consider introducing SI prefixes. There still will be confusion with 100GB, because apparently not everyone likes SI prefixes and continues using the old prefixes with base 2 numbers. However, when something is labeled 100GiB, there is no confusion (remember that we are talking about a user that cares about the exact number, the dumb user will guess that GiB must be something similar to GB). Okay, so we gained some confidence about what is meant. How can we get rid of the rest of uncertainty? Answer: Use the SI prefixes consistently! This will take a while of course, but eventually you can only benefit. Regards, Christof Krüger
Re: Two proposals for a better Lenny (testing related).
Le mardi 12 juin 2007 à 17:40 -0300, Gustavo Franco a écrit : I disagree, that's what we've with experimental today mainly due to the fact that there's just a few packages there. Consider everybody uploading every package for unstable instead. This has already been tried by Fedora and Mandriva, which ship development versions of their packages in the top-of-the-edge releases. The result is that developers are more focused on how to deal with utter breakage of their own installation than on improving software they maintain. Please, avoid that. And do never, ever forget that rule before uploading: UNSTABLE PACKAGES SHOULD BE RELEASE QUALITY Mistakes happen, but to detect them we need people using unstable, and people won't use a completely broken distribution. People knowingly uploading a package unsuitable for a stable release should be forced into working as d-i release manager for 3 months. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Using standardized SI prefixes
On Tue, Jun 12, 2007 at 05:33:12PM -0600, Wesley J. Landaker wrote: Even in the US all legitimate science and engineering is done in SI units. Suurre... That's why in 1999 the NASA Mars orbiter didn't crash because one (NASA) team worked in metric units and the other (private contractor) in imperial units. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Best practices for cron jobs?
* Duncan Findlay: I imagine it would be relatively simple to have the postinst generate a random time during the day for a cron script to run, but this doesn't work with anacron -- many users would never get updates. debsecan creates a cron entry which is run hourly, at a random minute, and the invoked script simply does nothing unless a day has passed since the last activity. This was the best thing I could come up with. People keep talking about ucf in this context, but I don't see how it contributes to a solution. (Just make sure that the generated cron entry does not contain any configuration data such as command line arguments.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Le mercredi 13 juin 2007 à 15:19 +0200, Bjørn Ingmar Berg a écrit : When computers and humans interact (on a technical level) humans must adapt to the computer, because computers can not. Anyone starting with such assumptions should never design any kind of user interface. Dealing with chunks of data, addresses, registers, etc. has to be done in base 2. Even if 1024 is close enough to 10^3 for a PHB or marketing humanoid, that will never make those two numbers equal. And it must never be allowed to. Computers, computer designers, computer technicians and most computer programmers will always deal with the _real_ base 2 numbers like 1024. Which is why they need appropriate units. Another example. Pi is an irrational number starting with 3.14 Sure, it would be easier to standardize it to 3.00. Done deal. It would be easier to remember and more marketable. It would also be totally useless AND completely wrong. AFAIK some very dumb people actually managed to decree by law that pi was to equal 3. They had to stop doing that. This is exactly what you are trying to do: state that 1024 = 1000. A well-known and very common trait of language is that one given word can often have more than one specific meaning. When this is the case you need a context to be sure. This is considered normal, and never a real problem. This should hold true regarding computers and counting as well. Yeah, sure. This is why mathematicians always use 3 instead of Pi in calculations. After all they are similar, and you can infer which one is actually being used depending on the context. I am very convinced the correct solution is always to educate the public. The world is not flat. The earth is not the center of the universe. Pi is not 3. A kilobyte is not 1000; it is 1024 because that is the way computers work. I am convinced the correct solution is to educate the group of blindfold hackers who think 1024 = 1000. It is much easier than educating millions of users. Wake up, Neo. There is a world out there. And in this world, kilo means 1000. One thousand. 10³. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 03:45 -0700, Steve Langasek escreveu: On Wed, Jun 13, 2007 at 11:28:52AM +0100, Luis Matos wrote: look ... i don't want guaranties ... you know what i mean ... want a place where it says testing HAS security support, we focus on having it stable. I don't want written contract ... i want a desktop user to discard stable and use testing. For that debian needs do publicly advice the use of testing in these cases ... and i mean for real. You are never going to get a statement from the Debian project telling users to use one suite or another (or at least, you shouldn't); the most we should be doing is giving users a list of pros and cons for each suite and letting them decide which fits their needs. I'm all in favor of reducing the number of decisions users have to make *in the software* :), but on something as high-level as which distro/suite to use, misestimating a user's needs is the kind of thing that will sour the user on Debian for a very long time. Yes, but debian *only* publicites the use of stable (that home users or desktop users tag as stale). If you publicity say that testing (or maybe this should be renamed :( ) is the way for an up-to-date, latest software distribution , then they will use it. for now it only states that testing is ... testing, right? There is a testing security team that addresses unembargoed security issues in testing. Fixes for embargoed security issues are generally not prepared in advance for testing. However, more people have access to work on the unembargoed security issues anyway (in the general case: anyone can upload to t-p-u), so it's not definite that stable is always more secure than testing. So, maybe, have more strict upload rules? Or, on the other way, maintainers can upload packages directly into testing (from t-p-u?). More strict upload rules for what? To have security updates in testing, easily and stable ... not to upgrade a new version into testing that can break stuff, or some mixed unstable and testing upload. - Testing simply moves too fast and the automatically passage process between unstble and testing *DOES* break testing. For one example, package foo requires package bar=0.3 but package bar 0.4 automatically passes to testing. Um, no. That does not happen automatically. In rare cases it happens because the release team has overridden the installability check for a package, because maintainers have not coordinated their transitions in unstable and as a result something needs to be broken to ever get any of the packages updated because you can't get 300 maintainers to get their packages in a releasable state *and* leave them alone long enough to transition to testing as a group. So please, don't do those oh, let them pass transitions ... they BREAK stuff ... for real. What? Some packages are allowed to pass into testing even if other depends on it, but has issues that will take some time to resolve. This will make that that package, that is now in testing, will not be installable in anyway. This happens sometimes. That's a problem of the packaging of those kernel modules, then, not a problem of testing per se; even if you track stable and therefore the problem only affects you once every two years, it's still a problem that should be addressed -- e.g., with metapackages like nvidia-kernel-2.6-686 (oh look, this one already exists). kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in time (they are not free, right?) ... kernel passes to testing ... That doesn't happen. well ... it happened to me before etch was released ... in such a way that i gave up using them. this is a simple upgrade ... because kernel packages are always NEW, the kernel will pass because it has no reverse dependency problems in testing. False. true. nvidia-kernel (meta packge) depends on linux-image-2.6.10. a new linux-image-2.6.20 passes to testing. The new nvidia-kernel did not pass because it is too young. nvidia-kernel is unusable. Or the user reboots with the new kernel, or edits by hand the xorg.conf . I used testing since about 3 months after sarge was released ... it was quite stable, but some transitions broke my system and it should not happen. -- 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 12:39 +0200, Gabor Gombas escreveu: On Wed, Jun 13, 2007 at 11:28:52AM +0100, Luis Matos wrote: kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in time (they are not free, right?) ... kernel passes to testing ... automatically, the nvidia-module-2.6.50 uses 2.6.50 and not *.51, so ... after a reboot, my xorg server will not run... when it used to. Then create an empty nvidia-module package that depends on the latest nvidia-module-X.Y.Z package and conflicts with linux-image-$ARCH X.Y.Z. Just because you're using non-free kernel modules does not mean that everyone else _not_ using those modules should be penalized. but why should I??? this goes against the testing is always *WORKING* phrase. TESTING IS NOT ALWAYS WORKING. you had the example with nvidia modules, what about wifi modules ... what about ... camera modules (i think they are all in the same source package now). They all BREAK in this case. How many of debian developers and contributors use these modules? Or alternatively, just reboot with the old kernel just like you'd do when you found out that any random driver you happen depend on stops working in the new kernel version. that is an *extreme* situation ... when there is BUG in the software ... not just because some package entered testing and broke your system. Gabor cheers, Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#428198: ITP: gabedit -- graphical interface to Ab Initio packages
Am Sonntag, den 10.06.2007, 08:41 +0200 schrieb Luca Brivio: Daniel Leidert wrote: Gabedit is a graphical user interface to computational chemistry packages, like: - GAMESS-US - Gaussian - Molcas - Molpro - MPQC - Q-Chem Maybe the fact that MPQC is the only one which is free and already in Debian (so that this package will go in the main section) could be worth some highlighting (e.g. Gabedit is a graphical user interface to MPQC and to following proprietary/commercial software: [...], This could be a choice. But I would probably add this information to the manpage, not to the package documentation. maybe also append like MPQC to the short description and make it Recommends: the latter). After all, Debian is about software freedom. :-) I don't think, the fact that mpqc is a DFSG-compliant software, warrants a recommends. There is no reason to recommend an Ab Initio package, just because it's free. Different users have different needs :) So they will choose one or more Ab Initio package based on their needs. BTW: The package (already/currently) suggests mpqc. This is IMHO enough. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Luis Matos [EMAIL PROTECTED] writes: but why should I??? this goes against the testing is always *WORKING* phrase. TESTING IS NOT ALWAYS WORKING. Having to use module-assistant != not working. -- 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: How to package software with binaries in tarball?
On Wed, Jun 13, 2007 at 10:06:20PM +0400, Sergei Golovan wrote: pristine source. It is rather nice to be able take debian's tar.gz and verify with md5sum or a detached gpg sig that upstream's tarball is The original tarball contains non-free RFCs, so it is recreated anyway. On a general note (I haven't checked if this applies to erlang or not): Please, if you repack, include the exact instructions for repacking in debian/copyright; ideally down to something you could cut-and-paste into a shell. Even though the resulting tarball might not be identical, it makes for much easier NMUing _and_ upstream intactness checking. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428750: ITP: drawxtl -- display crystal structures on ordinary computer hardware
Package: wnpp Severity: wishlist Owner: Daniel Leidert [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: drawxtl Version : 5.3 Upstream Author : Larry Finger, Martin Kroeker and Brian Toby * URL : http://home.att.net/~larry.finger/drawxtl/ * License : LGPL/Public Domain/GL2PS LICENSE (see http://svn.debian.org/wsvn/debichem/wnpp/drawxtl/debian/copyright?op=filerev=0sc=0) Programming Lang: C, C++ Description : display crystal structures on ordinary computer hardware DRAWxtl reads a basic description of the crystal structure, which includes unit-cell parameters, space group, atomic coordinates, thermal parameters or a Fourier map, and outputs a geometry object that contains polyhedra, planes, lone-pair cones, spheres or ellipsoids, bonds, iso-surface Fourier contours and the unit-cell boundary. Four forms of graphics are produced: (1) an openGL window for immediate viewing (2) the Persistence of Vision Ray Tracer (POV-RAY) scene language for publication-quality drawings (3) the Virtual Reality Modeling Language (VRML) for dissemination across the Internet (4) a Postscript rendering of the OpenGL window for those that want high-quality output but do not have POV-RAY installed. The package is actively maintained by the debichem project members at alioth.debian.org. - -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (850, 'unstable'), (700, 'testing'), (550, 'stable'), (110, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.20.3 (PREEMPT) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGcF2Xm0bx+wiPa4wRArCqAJwOgmCKIInaz843x48z57NYtPxC3gCfX9Py 3gelB2+7rRfOONLBBu8YqCc= =WNm9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 14:16 -0700, Russ Allbery escreveu: Luis Matos [EMAIL PROTECTED] writes: but why should I??? this goes against the testing is always *WORKING* phrase. TESTING IS NOT ALWAYS WORKING. Having to use module-assistant != not working. having a working system *with* only debian *oficial* packages and then after an upgrade that system stops working properly, i call it a regression ... if ... *if* i had used module-assistant to use nvidia graphics (or camera modules, or wifi, or what else), i would not mind to do that. -- 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: Using standardized SI prefixes
As I see it there are two ways of resolving the difference between KiB and KB. * Use Rosetta to update the text and fix the output so that it now reads KiB. This would be relatively simple to do, but not actually helpful longer term. * Fix the source code that calculates KB by doing a bit shift[0] and instead dividing the number of bytes by a power of 10. [0] I'm assuming that most applications will calculate how many Kilobytes/Megabytes are used by dividing by a power of two. -- Onno Benschop Connected via Optus B3 at S31°54'06 - E115°50'39 (Yokine, WA) -- ()/)/)()..ASCII for Onno.. |?..EBCDIC for Onno.. --- -. -. --- ..Morse for Onno.. Proudly supported by Skipper Trucks, Highway1, Concept AV, Sony Central, Dalcon ITmaze - ABN: 56 178 057 063 - ph: 04 1219 - [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wed, 13 Jun 2007, Alex Jones wrote: On Wed, 2007-06-13 at 14:29 +0100, Scott James Remnant wrote: Without the binary unit to consider, when we quote a drive as 1TB, we know that it has *at least* 1,000,000,000,000 bytes available. Depending on the drive, it may have anywhere between this and 1,099,511,627,776 bytes available. It's actually more likely to have something strange like 1,024,000,000,000 available. 10% error is no good for me. You can continue to play the at least card, but what about when it's more important if it is at most something? And seeing as this error only goes up exponentially, at which prefix do you draw the line and say no more? And no-one uses floppy disks any more. Let's just bury them all and forget about them. :D I see no problem with this 1TB quote being approximate. It's rounded anyway. If you really want to know how many bytes are available, you can use this great unit called the byte which is accurate and not subject to change[0]. 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no less. If they want to actually put 1.024 TB on the disk then they can say 1 TB (approx.) like any other industry (detergent, bacon, etc.). 1 TB has only one significant digit. It would be silly to think that it was an exact measurement, at least in fields I am familiar with. ;) No one I know would think 1km is as precisely measured as 1.0km. But, just because it is approximate, doesn't mean it isn't also ambigouous. :) 1 TB could mean between 5000 and 14999 bytes, between 549755813888 and 1649267441663 bytes, or even between 5000 and 14999.99... bels. :) So, if you want the exact number of bytes, don't round it off, and if you do round it off, don't be surprised if the rounding is ambiguous, because the units are not SI units, and the prefixes may or may not be. Just don't use prefixes when not rounding. I wonder, do people feel as storngly about exactly how many tablespoons 1 TT is? Ivan
Re: Two proposals for a better Lenny (testing related).
Luis Matos [EMAIL PROTECTED] writes: having a working system *with* only debian *oficial* packages and then after an upgrade that system stops working properly, i call it a regression ... If you're using non-free drivers, the first part of your sentence above doesn't apply. Usually, however, those non-free drivers that are built for each kernel get built before the new kernel migrates to testing, but given that those builds can't be handled by the general mechanism for building add-on modules, I don't think the currency of those builds can be guaranteed. My recommendation is to always use module-assistant for all non-free drivers that you want to use. That way, if there is a build in non-free, you can be pleasantly surprised, but your normal method will always work. Many non-free drivers (and some free drivers, for that matter) are never automatically built at the moment, although with the new mechanism for building modules in main, hopefully that number will drop over time for the free ones. -- 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: Two proposals for a better Lenny (testing related).
On Wed, Jun 13, 2007 at 03:00:15PM -0700, Russ Allbery wrote: Many non-free drivers (and some free drivers, for that matter) are never automatically built at the moment, although with the new mechanism for building modules in main, hopefully that number will drop over time for the free ones. Could you please elaborate on this mechanism, or point to an URL? (If it's been discussed here and I just missed it, I apologize -- I skip most of -devel these days :-) ) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Luis Matos wrote: Qua, 2007-06-13 às 14:16 -0700, Russ Allbery escreveu: Luis Matos [EMAIL PROTECTED] writes: but why should I??? this goes against the testing is always *WORKING* phrase. TESTING IS NOT ALWAYS WORKING. Having to use module-assistant != not working. having a working system *with* only debian *oficial* packages and then after an upgrade that system stops working properly, i call it a regression ... Installing a newer kernel is not an upgrade, in a sense. You are installing new software alongside the old one. Thus the usual expectations don't hold. PS: I do agree that it would be nice if there was a way to automatically bring in the modules you are using for the new version, or at least warn, but I can't seem to figure out a nice and elegant way of doing that. And no, more people using testing won't fix this issue either. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Steinar H Gunderson [EMAIL PROTECTED] writes: On Wed, Jun 13, 2007 at 03:00:15PM -0700, Russ Allbery wrote: Many non-free drivers (and some free drivers, for that matter) are never automatically built at the moment, although with the new mechanism for building modules in main, hopefully that number will drop over time for the free ones. Could you please elaborate on this mechanism, or point to an URL? (If it's been discussed here and I just missed it, I apologize -- I skip most of -devel these days :-) ) http://packages.qa.debian.org/l/linux-modules-contrib-2.6.html My understanding of the goal is that this package will build-depend on the source packages of all the free external drivers that can support this sort of automated build and then only the linux-modules-contrib maintainers have to deal with the ever-changing exact list of kernel versions for which modules should be built. I don't know how far along this is yet. -- 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: Two proposals for a better Lenny (testing related).
Russ Allbery [EMAIL PROTECTED] writes: Steinar H Gunderson [EMAIL PROTECTED] writes: On Wed, Jun 13, 2007 at 03:00:15PM -0700, Russ Allbery wrote: Many non-free drivers (and some free drivers, for that matter) are never automatically built at the moment, although with the new mechanism for building modules in main, hopefully that number will drop over time for the free ones. Could you please elaborate on this mechanism, or point to an URL? (If it's been discussed here and I just missed it, I apologize -- I skip most of -devel these days :-) ) http://packages.qa.debian.org/l/linux-modules-contrib-2.6.html Also, and more interestingly: http://packages.qa.debian.org/l/linux-modules-extra-2.6.html contrib is just the ones that go into contrib, of course. (D'oh.) -- 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: Using standardized SI prefixes
On Wednesday 13 June 2007 14:03:51 Lionel Elie Mamane wrote: On Tue, Jun 12, 2007 at 05:33:12PM -0600, Wesley J. Landaker wrote: Even in the US all legitimate science and engineering is done in SI units. Suurre... That's why in 1999 the NASA Mars orbiter didn't crash because one (NASA) team worked in metric units and the other (private contractor) in imperial units. I am happy to very brutally assert that the team who didn't use SI was not doing legitimate science or engineering. But whether it's from unskilled employees or bad management, it's quite unfortunate. =( -- Wesley J. Landaker [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 signature.asc Description: This is a digitally signed message part.
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 15:00 -0700, Russ Allbery escreveu: Luis Matos [EMAIL PROTECTED] writes: having a working system *with* only debian *oficial* packages and then after an upgrade that system stops working properly, i call it a regression ... If you're using non-free drivers, the first part of your sentence above doesn't apply. I agree ... so what about the linux-modules-contrib-2.6 source package? Usually, however, those non-free drivers that are built for each kernel get built before the new kernel migrates to testing, but given that those builds can't be handled by the general mechanism for building add-on modules, I don't think the currency of those builds can be guaranteed. agreed. My recommendation is to always use module-assistant for all non-free drivers that you want to use. That way, if there is a build in non-free, you can be pleasantly surprised, but your normal method will always work. i don't think that this is useful in a debian way. That is equal to tell the maintainer to stop his work. Many non-free drivers (and some free drivers, for that matter) are never automatically built at the moment, although with the new mechanism for building modules in main, hopefully that number will drop over time for the free ones. i hope so. i want to tell a couple of things: 1. My critic goes for the automatic passage of packages that make other packages (already available in testing) uninstallable or conflictive. In these 2 sets are packages that have reverse depends and, for example, the kernel. 2. You, like other, confirm this situation, but for some reason, you just don't explicit agree with it. 3. My main objective is to turn testing an *REAL* alternative for stable. I've used testing (now i am running stable). It's quite stable, but some upgrades break stuff. This breakage should not happen and packages that cause breakage should not pass into testing. 4. Making testing more visible as a bleeding edge (+/-) *stable* distribution would be a nice thing and people would appreciate. Making snapshots (full cd sets called previews, for one example) would make it visible and useful. Users with testing (commonly home or power users) can see it's system evolute, while it remains stable, usable and bleeding edge (stability would be preferred over bleeding edge). 5. CUT is *THE* option for testing that would permit this. just my thoughts. Luis Matos -- 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: Two proposals for a better Lenny (testing related).
* Joey Hess [EMAIL PROTECTED], [2007-06-11 19:56 -0400]: Testing also needs periodic snapshots and guaranteed upgradability to be useable by more users, amoung other points I discuss at http://kitenet.net/~joey/code/debian/cut/ Snapshots should be made available regularly, so that users who need a firm foundation for deployment have one. They'd be numbered, so we could call them cut 4, cut 5, etc. Each would be a snapshot of testing at a point when it was in especially good shape. Another option could be calling each snapshot cut -MM, or cut -MM-DD if we plan to release them more than once per month. I realize that 'freezing' testing when it is in good shape we adhere to the when it's ready philosophy, but can you think of a rough estimate about how often it could happen? ciao, ema -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 18:09 -0400, Felipe Sateler escreveu: Luis Matos wrote: Qua, 2007-06-13 às 14:16 -0700, Russ Allbery escreveu: Luis Matos [EMAIL PROTECTED] writes: but why should I??? this goes against the testing is always *WORKING* phrase. TESTING IS NOT ALWAYS WORKING. Having to use module-assistant != not working. having a working system *with* only debian *oficial* packages and then after an upgrade that system stops working properly, i call it a regression ... Installing a newer kernel is not an upgrade, in a sense. You are installing new software alongside the old one. Thus the usual expectations don't hold. the usual expectation that i have with a new kernel is to improve my operating system ... that includes no regressions on supporting my hardware - for example, wifi or graphic card. PS: I do agree that it would be nice if there was a way to automatically bring in the modules you are using for the new version, or at least warn, but I can't seem to figure out a nice and elegant way of doing that. And no, more people using testing won't fix this issue either. what about checking the *-modules-2.6.A packages available and compare them with the previous version? if the count of both are equal, then kernel *and* modules can go into testing. If, for some reason a module is not available or cannot migrate into testing, kernel would not migrate. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qui, 2007-06-14 às 01:04 +0200, Emanuele Rocca escreveu: * Joey Hess [EMAIL PROTECTED], [2007-06-11 19:56 -0400]: Testing also needs periodic snapshots and guaranteed upgradability to be useable by more users, amoung other points I discuss at http://kitenet.net/~joey/code/debian/cut/ Snapshots should be made available regularly, so that users who need a firm foundation for deployment have one. They'd be numbered, so we could call them cut 4, cut 5, etc. Each would be a snapshot of testing at a point when it was in especially good shape. Another option could be calling each snapshot cut -MM, or cut -MM-DD if we plan to release them more than once per month. this makes the snapshots just like the current ones (i think cd sets are built weekly r monthly, can anyone confirm this?) I realize that 'freezing' testing when it is in good shape we adhere to the when it's ready philosophy, but can you think of a rough estimate about how often it could happen? think about transitions .. let's get etch release cycle example. i think 2 or 3 snapshots would be good. (not time ordered) 1. transition to xorg 2. new gnome version 3. new kde version 4. new gcc version these are quite predictable, and i think the main objective is not FULL stability, but to have a work base. So, if we predict that in the next month a big transition will be made, then, a snapshot will be made with the transition objectives. When they are accomplished, debian would ship a snapshot. By scheduling the snapshot, other maintainers can upload their new packages that will be included in the snapshot. remind you that if packages only pass to testing *ready for stable* (more or less) any snapshot would be quite stable and usable (+/- like an ubuntu release - this was a bad joke). Having this *release* would make people to use more debian. Of course the system would be continuously updated. ciao, ema best regards, Luis Matos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Luis Matos [EMAIL PROTECTED] writes: Qua, 2007-06-13 às 15:00 -0700, Russ Allbery escreveu: My recommendation is to always use module-assistant for all non-free drivers that you want to use. That way, if there is a build in non-free, you can be pleasantly surprised, but your normal method will always work. i don't think that this is useful in a debian way. That is equal to tell the maintainer to stop his work. I think this is a ridiculous exaggeration. module-assistant is not difficult to use. Installing the correct kernel modules for your kernel is a one-line command. i want to tell a couple of things: 1. My critic goes for the automatic passage of packages that make other packages (already available in testing) uninstallable or conflictive. In these 2 sets are packages that have reverse depends and, for example, the kernel. 2. You, like other, confirm this situation, but for some reason, you just don't explicit agree with it. For non-free, this is inevitable without significant changes to the way that Debian works that I don't believe will happen. Debian has provided a different solution in the form of module-assistant that in my experience works great. I recommend that you learn how to use it rather than tilting at windmills. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Two proposals for a better Lenny (testing related).
On Wed, Jun 13, 2007 at 11:53:24AM +0200, Gabor Gombas wrote: On Wed, Jun 13, 2007 at 12:42:34AM +0100, Luis Matos wrote: - Smooth passages are not always smooth (who had a working xorg after the upgrade for 7, please raise their hands) AFAIR apart from having to edit a few config files it was quite painless (I've upgraded when Xorg was still in experimental). OTOH the current xserver-xorg-video-ati snapshot in experimental is not suitable for everyday use (the crash in DPMS is a blocker for me) so I'd be quite annoyed if it was uploaded to unstable; but being able to easily test new versions to see if the bugs are still there is very useful. By the time it hit testing it worked pretty well for most people. We broke a few things, but it was nice for just about everyone. Everyone except those people using proprietary drivers, but they know they've already dug their own grave there. If Luis wants to keep whining about it, I suggest he talk to nvidia. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
David Nusinow [EMAIL PROTECTED] writes: By the time it hit testing it worked pretty well for most people. We broke a few things, but it was nice for just about everyone. Everyone except those people using proprietary drivers, but they know they've already dug their own grave there. If Luis wants to keep whining about it, I suggest he talk to nvidia. I didn't have many problems even with proprietary drivers. I thought it went quite smoothly. -- 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: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 16:18 -0700, Russ Allbery escreveu: For non-free, this is inevitable without significant changes to the way that Debian works that I don't believe will happen. Debian has provided a different solution in the form of module-assistant that in my experience works great. I recommend that you learn how to use it rather than tilting at windmills. this is not a discussion on how to support non-free drivers ... module-assistant is not an answer to the modules-contrib and modules-extra (at least). (i have used module-assistant and i think is a great tool) the problem here (that happened to me with other packages) is that some packages with reverse dependencies passed into testing making other packages uninstalable. kernel and modules is just one problem. my point here is that i think the current structure is ok, but ... the passage to testing has to be done with more care (care it already has). i am not whining about the use of nvidia non-free drivers ... i am whining about have a good CUT and *THAT* requires the paragraph before. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
Qua, 2007-06-13 às 19:20 -0400, David Nusinow escreveu: By the time it hit testing it worked pretty well for most people. We broke a few things, but it was nice for just about everyone. Everyone except those people using proprietary drivers, but they know they've already dug their own grave there. If Luis wants to keep whining about it, I suggest he talk to nvidia. lol ... the passage from xorg 6 to 7 was a big passage ... i had some uninstalable packges (not nvidia related), i even opened a bug[0], that i closed some weeks ago when i reviewed the bugs i've submitted. this is one example about the problem i am trying to get attention to. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370370 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Ivan Jager [EMAIL PROTECTED] writes: On Wed, 13 Jun 2007, Alex Jones wrote: 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no less. If they want to actually put 1.024 TB on the disk then they can say 1 TB (approx.) like any other industry (detergent, bacon, etc.). 1 TB has only one significant digit. It would be silly to think that it was an exact measurement, at least in fields I am familiar with. ;) No one I know would think 1km is as precisely measured as 1.0km. The difference being that digital specifications for things like storage capacity and memory are not measured. They are calculated, and in those contexts they *are* precise. Rounding can be done after the calculated number is obtained, but it's not inherent in the process of obtaining the number the way that measuring 1 km or 1 tablespoon is. Since we *can* give a perfectly precise quantity of bytes and other digital phenomena, and often do, this is even more reason to use the precise meaning of the units for those quantities. -- \ I moved into an all-electric house. I forgot and left the | `\ porch light on all day. When I got home the front door wouldn't | _o__) open. -- Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Russ Allbery [EMAIL PROTECTED] writes: Christof Krüger [EMAIL PROTECTED] writes: I'd really like to hear some real arguments against SI prefixes, besides being ugly or funny to pronounce or just because it has always been like that. Advantages of using SI prefixes has been mentioned in this thread. Please tell me the disadvantages so there can actually be a constructive discussion. Trying to change every piece of software in existence is a waste of time and energy for a problem that isn't that serious. This proposal was never about trying to change every piece of software in existence. Just because perfection is unobtainable doesn't stop us from working to improve the state of what we have. IMO, that's the *real* objection; most of the arguments are justifications for that position or are about things that we'd get over if this issue were addressed (like the silly words -- there are sillier words in English that just don't sound that way because we're used to them). Agreed. Most of the arguments against this proposal to follow a useful standard that improves clarity have been essentially yuk or I'm alright Jack. Yes, the names sound silly. So does byte, but we follow that convention. A silly name is not an argument against following the standard. The names are close enough to the wrongly-applied base-10 names that familiarity is fairly easily obtainable, while still being different enough that they are distinct names. Yes, most of us who frequently work with computers have become accustomed to the ambiguity of these terms, in a field where precision of terminology is highly valued. This is no reason not to work toward fixing this for the majority of people who have yet to spend any significant time exposed to these terms. -- \ One of the most important things you learn from the internet | `\ is that there is no 'them' out there. It's just an awful lot of | _o__) 'us'. -- Douglas Adams | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428774: ITP: pixman -- pixel-manipulation library for X and cairo
Package: wnpp Severity: wishlist Owner: Debian X Strike Force [EMAIL PROTECTED] * Package name: pixman Version : 0.9.3 Upstream Author : Søren Sandmann [EMAIL PROTECTED] * URL : git://anongit.freedesktop.org/git/pixman * License : MIT/X Programming Lang: C Description : pixel-manipulation library for X and cairo A library for manipulating pixel regions -- a set of Y-X banded rectangles, image compositing using the Porter/Duff model and implicit mask generation for geometric primitives including trapezoids, triangles, and rectangles. Future releases of the X.Org X server and of cairo will link against pixman instead of duplicating this code, so packaging this is necessary before we can consider uploading recent git snapshots of the X server to experimental. Preliminary packaging at http://git.debian.org/?p=pkg-xorg/lib/pixman.git signature.asc Description: Digital signature
Re: Best practices for cron jobs?
Duncan == Duncan Findlay [EMAIL PROTECTED] writes: Duncan What can I do to satisfy those with and without anacron, Duncan and to avoid hammering the sa-update servers at a specific Duncan time? Look at the clamav-freshclam package. I suspect the maintainers have already encountered similar issues to yours. I can't remember the details of how clamav-freshclam works right now though. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428776: ITP: libpciaccess -- Generic PCI access library for X
Package: wnpp Severity: wishlist Owner: Debian X Strike Force [EMAIL PROTECTED] * Package name: libpciaccess Version : 0.8.0 Upstream Authors: Ian Romanick [EMAIL PROTECTED] Eric Anholt [EMAIL PROTECTED] edward shu [EMAIL PROTECTED] * URL : git://anongit.freedesktop.org/git/xorg/lib/libpciaccess * License : MIT/X Programming Lang: C Description : Generic PCI access library for X Provides functionality for X to access the PCI bus and devices in a platform-independant way. This is a dependency of the new avivo driver (for r500-based AMD cards), and will be used by future releases of the X.Org X server. Preliminary packaging at http://git.debian.org/?p=pkg-xorg/lib/libpciaccess.git signature.asc Description: Digital signature
Re: Two proposals for a better Lenny (testing related).
On Wed, Jun 13, 2007 at 05:32:01PM +0100, Luis Matos wrote: Um, no. That does not happen automatically. In rare cases it happens because the release team has overridden the installability check for a package, because maintainers have not coordinated their transitions in unstable and as a result something needs to be broken to ever get any of the packages updated because you can't get 300 maintainers to get their packages in a releasable state *and* leave them alone long enough to transition to testing as a group. So please, don't do those oh, let them pass transitions ... they BREAK stuff ... for real. What? Some packages are allowed to pass into testing even if other depends on it, but has issues that will take some time to resolve. This will make that that package, that is now in testing, will not be installable in anyway. This happens sometimes. Well, tough. Take it up with the maintainers who don't coordinate their uploads to unstable with the maintainers of related packages. The release team only breaks packages in testing when we *have* to do so to move the release forward (meaning, a net reduction in RC problems). That's a problem of the packaging of those kernel modules, then, not a problem of testing per se; even if you track stable and therefore the problem only affects you once every two years, it's still a problem that should be addressed -- e.g., with metapackages like nvidia-kernel-2.6-686 (oh look, this one already exists). kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in time (they are not free, right?) ... kernel passes to testing ... That doesn't happen. well ... it happened to me before etch was released ... in such a way that i gave up using them. No. The nvidia kernel packages are a particular case where the module packages were willfully broken in testing by the release team because of long-outstanding RC bugs in related nvidia packages. Again, this was a necessary trade-off which reduced the overall number of release-critical problems in testing. this is a simple upgrade ... because kernel packages are always NEW, the kernel will pass because it has no reverse dependency problems in testing. False. true. nvidia-kernel (meta packge) depends on linux-image-2.6.10. a new linux-image-2.6.20 passes to testing. The new nvidia-kernel did not pass because it is too young. You either don't know how testing works, or you don't know how the Debian kernel packages are structured. -- 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428777: ITP: xserver-xorg-video-avivo -- X.Org X server -- Avivo display driver
Package: wnpp Severity: wishlist Owner: Debian X Strike Force [EMAIL PROTECTED] * Package name: xserver-xorg-video-avivo Version : 0.0.1 Upstream Authors: Daniel Stone [EMAIL PROTECTED] Matthew Garrett [EMAIL PROTECTED] Jerome Glisse [EMAIL PROTECTED] * URL : git://anongit.freedesktop.org/git/avivo/xf86-video-avivo * License : GPL Programming Lang: C Description : X.Org X server -- Avivo display driver This driver for the X.Org X server (see xserver-xorg for a further description) provides support for ATI R500 cards. . Note that this driver is currently experimental and works in 2D only. Anybody interested in helping out with the avivo package is welcome to contact debian-x (I don't think any of the current XSF members have the hardware). Preliminary packaging at http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-avivo.git signature.asc Description: Digital signature
Re: Re: APT 0.7 for sid
I am definitely a GUI person (aptitude is the last non-GUI program with a GUI available that I still use), but I still prefer aptitude to any other. I was under the impression that most others did too, is it not the recommended Debian way?. Yes (but that's a reported bug, #418455) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
GSASL Maintainer Missing in Action?
Hello, libgsasl and libntlm are maintained by Yvan Bassuel and were uploaded by Anibal Salazar. I am CC'ing them. Two weeks ago I've sent an email no Yvan, asking if he was still interested in maintaining those packages. Both have newer upstream versions. There is a bug with a patch for libgsasl7 that was not answered by Yvan. It is dated as of last December. libgasl7 and libntlm0 were last uploaded in March 2006 and June 2006, respectively. I've sent another message to Yvan on Monday. Does anyone know the whereabouts of Yvan? May I consider him missing in action? I am interested in maintaining those packages. How should I proceed? NMU before taking maintainership and wait another two weeks? Take maintainership now? Or wait another two weeks and, then, uploading those new versions? (I will need sponsorship, but that I can arrange.) Best Regards, Thadeu Cascardo. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to package software with binaries in tarball?
On 6/14/07, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Wed, Jun 13, 2007 at 10:06:20PM +0400, Sergei Golovan wrote: pristine source. It is rather nice to be able take debian's tar.gz and verify with md5sum or a detached gpg sig that upstream's tarball is The original tarball contains non-free RFCs, so it is recreated anyway. On a general note (I haven't checked if this applies to erlang or not): Please, if you repack, include the exact instructions for repacking in debian/copyright; ideally down to something you could cut-and-paste into a shell. Even though the resulting tarball might not be identical, it makes for much easier NMUing _and_ upstream intactness checking. Is get-orig-source target in debian/rules, which fetches and repacks orig.tar.gz sufficient? I guess it should be. -- Sergei Golovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two proposals for a better Lenny (testing related).
On Mon, 11 Jun 2007 18:20:17 -0300, Gustavo Franco [EMAIL PROTECTED] said: 1) The 'remove experimental' proposal * Warn developers and contributors[0] * Remove experimental * Switch unstable (release) for not automatic updates This is one of the worst proposals I have seen. Removing experimental means that there is no place to pout in packages which are probably broken, but really interested persons should please test. There would be no way of distinguishing those from new packages, ought to be OK, please test stuff. Prevent auto up0dating, means that, along with the above change, unstable becomes too annoying to run. With people no longer running unstable, bugs do not get caught. Instead, bugs propogate to testing. So, effectively, you have removed testing (and relabled unstable as testing). With no real bug triage before testing, we are back to the old release dilemma: the distribution we release from has lots of bugg packages. Welcome back to 1/2 year long freezes. Why one earth would w3e want to regress to the days before testing? manoj -- Quick, sing me the BUDAPEST NATIONAL ANTHEM!! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 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: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Sat, 9 Jun 2007 11:24:08 -0500, Steve Greenland [EMAIL PROTECTED] said: On 09-Jun-07, 04:30 (CDT), Petter Reinholdtsen [EMAIL PROTECTED] wrote: My point is that it is useful to know what major release of Debian a machine is using, My point is the only reliable way to determine that is via /etc/apt/sources and /etc/apt/preferences, not to mention /var/lib/dpkg/status (because packages might be on hold). You are assuming that the contents of /etc/apt/sources and /etc/apt/preferences are fairly static. That is an asumptio0n that does not hold true at least for my laptop, where the sources and preferences change a log when I travel (which is fairly often). Parsing today's sources would lead you to assume I only do security up0dates, and would have no bearing on the versions of packages on my system (which come from local Sid partial mirror, not in my sources.list file today). manoj -- Don't get married. Find a woman you hate and buy her a house. anon Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 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: Using standardized SI prefixes
Eduard Bloch [EMAIL PROTECTED] writes: What is not really understandable is why this stupid naming has been kept in Windows XP. Because nobody actually cares except control-freak types, and they're certainly not who windows is targetting! -Miles -- `To alcohol! The cause of, and solution to, all of life's problems' --Homer J. Simpson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Wed, Jun 13, 2007 at 07:41:27PM +0100, Adam D. Barratt wrote: On Wed, 2007-06-13 at 14:08 -0400, Felipe Sateler wrote: Mike Hommey wrote: On Tue, Jun 12, 2007 at 09:25:13PM +, Evgeni Golov [EMAIL PROTECTED] wrote: On Tue, 12 Jun 2007 15:42:08 -0300 Paulo Marcondes wrote: billion = 10^6 * 10^6 (IIRC, as used in Portugal - no jokes here!) =10^12 :) and Germany, France, former UdSSR, insert your country here Anywhere where milliard is 10^9, basically... Which includes England, according to Merriam-Webster [1]. [...] [1] http://www.m-w.com/mw/table/number.htm The American usage has been becoming more common in England (and the rest of Britain :-) over the past few years, particularly in science and finance related usage. I could be wrong, but I suspect most British people have never even heard of a milliard. It's usually referred to either as a billion or an American billion. http://en.wikipedia.org/wiki/Long_and_short_scales It all depends on space and time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted spamassassin 3.2.1-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 11 Jun 2007 14:36:38 -0700 Source: spamassassin Binary: spamassassin spamc Architecture: source all i386 Version: 3.2.1-1 Distribution: unstable Urgency: low Maintainer: Duncan Findlay [EMAIL PROTECTED] Changed-By: Duncan Findlay [EMAIL PROTECTED] Description: spamassassin - Perl-based spam filter using text analysis spamc - Client for SpamAssassin spam filtering daemon Closes: 402241 425685 427725 427862 428316 Changes: spamassassin (3.2.1-1) unstable; urgency=low . * New upstream release - Fixes security vulnerability CVE-2007-2873 - Silences loud warning message (Closes: #425685) - Properly document message size limit (Closes: #402241) * Recommends: gcc, libc6-dev, make for sa-compile (Closes: #427725) * Fixed out of date section in README.Debian discussing sa-update (Closes: #428316) * Clarified how sa-compile works in README.Debian (Closes: #427862) * Check in cron.daily that /var/lib/spamassassin/compiled exists (i.e. only compile rules if sa-compile has previously been run) * Recompile rules in postinst if /var/lib/spamassassin/compiled exists (and sa-update and re2c exist) Files: d0be7be0de4a87317f38dbd30f6b5ef9 765 mail optional spamassassin_3.2.1-1.dsc a7d51294c565999da01f212e5ad2a031 1193561 mail optional spamassassin_3.2.1.orig.tar.gz 9c50ffa91e440e70f660fb3724e0e177 33739 mail optional spamassassin_3.2.1-1.diff.gz 5ec799c1221eca5b4311f256f2d4cb34 1062164 mail optional spamassassin_3.2.1-1_all.deb f6561f095e21ca010f753822efbe4c07 67252 mail optional spamc_3.2.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGb4mmqjUzNGvmnNARAq0aAJ99yf/GZREE4XGR1rrmr3bpVCFiVgCgiIZr R4JesHGBwotW8iyDIq6IGqM= =f7rO -END PGP SIGNATURE- Accepted: spamassassin_3.2.1-1.diff.gz to pool/main/s/spamassassin/spamassassin_3.2.1-1.diff.gz spamassassin_3.2.1-1.dsc to pool/main/s/spamassassin/spamassassin_3.2.1-1.dsc spamassassin_3.2.1-1_all.deb to pool/main/s/spamassassin/spamassassin_3.2.1-1_all.deb spamassassin_3.2.1.orig.tar.gz to pool/main/s/spamassassin/spamassassin_3.2.1.orig.tar.gz spamc_3.2.1-1_i386.deb to pool/main/s/spamassassin/spamc_3.2.1-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted telepathy-idle 0.1.1-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 13 Jun 2007 08:29:32 +0200 Source: telepathy-idle Binary: telepathy-idle Architecture: source i386 Version: 0.1.1-1 Distribution: unstable Urgency: low Maintainer: Debian Telepathy maintainers [EMAIL PROTECTED] Changed-By: Sjoerd Simons [EMAIL PROTECTED] Description: telepathy-idle - IRC connection manager for Telepathy Changes: telepathy-idle (0.1.1-1) unstable; urgency=low . * New upstream release Files: 27bfc45f4d3ad2fdbbd16e7588222025 924 - optional telepathy-idle_0.1.1-1.dsc 860829ad5c965c4e82519e732d17ab5f 383416 - optional telepathy-idle_0.1.1.orig.tar.gz 888ad66a3c541c49680f62f23ba532e1 1561 - optional telepathy-idle_0.1.1-1.diff.gz f2c429718697045b489d25fdc0938818 47654 net optional telepathy-idle_0.1.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGb5ExgTd+SodosdIRAsr2AKDV9VMSCBQkUX1JC7j7kNMxR0w8wACcCwft JLAaomC7TyVNWP7RBHH1Gmg= =hva4 -END PGP SIGNATURE- Accepted: telepathy-idle_0.1.1-1.diff.gz to pool/main/t/telepathy-idle/telepathy-idle_0.1.1-1.diff.gz telepathy-idle_0.1.1-1.dsc to pool/main/t/telepathy-idle/telepathy-idle_0.1.1-1.dsc telepathy-idle_0.1.1-1_i386.deb to pool/main/t/telepathy-idle/telepathy-idle_0.1.1-1_i386.deb telepathy-idle_0.1.1.orig.tar.gz to pool/main/t/telepathy-idle/telepathy-idle_0.1.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted insighttoolkit 3.2.0-2 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 13 Jun 2007 00:59:13 -0500 Source: insighttoolkit Binary: libinsighttoolkit3.0 insighttoolkit-examples libinsighttoolkit-dev Architecture: source i386 all Version: 3.2.0-2 Distribution: unstable Urgency: low Maintainer: Gavin Baker [EMAIL PROTECTED] Changed-By: Steve M. Robbins [EMAIL PROTECTED] Description: insighttoolkit-examples - Image processing toolkit for registration and segmentation - exam libinsighttoolkit-dev - Image processing toolkit for registration and segmentation - deve libinsighttoolkit3.0 - Image processing toolkit for registration and segmentation - runt Closes: 424132 424134 Changes: insighttoolkit (3.2.0-2) unstable; urgency=low . * debian/patches/04_ITKConfig.patch: Don't export ITK_SOURCE_DIR. Closes: #424132. . * debian/patches/05_itkIncludeDirectories.patch: Correct include path for gdcm. Closes: #424134. Files: 37660e47a511240d17f64a0c177ea258 809 science optional insighttoolkit_3.2.0-2.dsc e3bac7ed4e4467ca85a1bfa3841a7402 15925 science optional insighttoolkit_3.2.0-2.diff.gz 3180db21becc6820e59228101a9db37a 1566072 devel optional insighttoolkit-examples_3.2.0-2_all.deb 19e7c50137adc22d8d6cd256b8078fc8 4239892 libs optional libinsighttoolkit3.0_3.2.0-2_i386.deb 2c93aa6aca6f5832f7bc6946928881aa 3436178 devel optional libinsighttoolkit-dev_3.2.0-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGb5Q80i2bPSHbMcURAjVbAKCILYqknBQ9Rbbw7MlqO+wnW8o0WQCfbdby EKUHjXoLRsIEQejULSFesrE= =1hMO -END PGP SIGNATURE- Accepted: insighttoolkit-examples_3.2.0-2_all.deb to pool/main/i/insighttoolkit/insighttoolkit-examples_3.2.0-2_all.deb insighttoolkit_3.2.0-2.diff.gz to pool/main/i/insighttoolkit/insighttoolkit_3.2.0-2.diff.gz insighttoolkit_3.2.0-2.dsc to pool/main/i/insighttoolkit/insighttoolkit_3.2.0-2.dsc libinsighttoolkit-dev_3.2.0-2_i386.deb to pool/main/i/insighttoolkit/libinsighttoolkit-dev_3.2.0-2_i386.deb libinsighttoolkit3.0_3.2.0-2_i386.deb to pool/main/i/insighttoolkit/libinsighttoolkit3.0_3.2.0-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted deb822 0.3 (source all)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 12 Jun 2007 17:37:05 -0600
Source: deb822
Binary: python-deb822
Architecture: source all
Version: 0.3
Distribution: unstable
Urgency: low
Maintainer: dann frazier [EMAIL PROTECTED]
Changed-By: John Wright [EMAIL PROTECTED]
Description:
python-deb822 - Read and manipulate RFC822-like files (e.g. .dsc and .changes)
Closes: 428540
Changes:
deb822 (0.3) unstable; urgency=low
.
* deb822.py:
- Allow Deb822 objects to be initialized with a dict containing the initial
key-value pairs.
- _multivalued class:
+ Make all the multivalued dicts Deb822Dict objects, so the keys are
case-preserving, but case-insensitive
- Add a Release class, which knows about Release-file multivalued fields.
Thanks to Alexandre Fayolle. (Closes: 428540)
- Deb822Dict no longer directly subclasses dict. All of the important
methods were already implemented with userdict.DictMixin; the dict
subclass was so that Python would see a Deb822Dict instance as a dict
instance. Unfortunately, this causes confusion if you do something like
d = dict(Deb822Dict({'foo': 'bar'})
The Pythonic way to check for a dictionary interface is to check for
the 'items' attribute.
* test_deb822.py:
- Add a test case for deriving a Python dict from a Deb822Dict.
* debian/control:
- Add a XS-Vcs-Bzr field
Files:
9e21184763c44749a225cee47e709861 584 python optional deb822_0.3.dsc
529c90ed1313e8b548666cc7a5b4a0a2 11708 python optional deb822_0.3.tar.gz
4bc19811daab038b2e3f735b2d1aa96a 9706 python optional python-deb822_0.3_all.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD4DBQFGb5uQhuANDBmkLRkRAhGsAJ9zn07qAa/wrJmgX6HpwNyutjrvmgCY/7zx
QDgHxUPyxOthI8weoN3LjQ==
=PewR
-END PGP SIGNATURE-
Accepted:
deb822_0.3.dsc
to pool/main/d/deb822/deb822_0.3.dsc
deb822_0.3.tar.gz
to pool/main/d/deb822/deb822_0.3.tar.gz
python-deb822_0.3_all.deb
to pool/main/d/deb822/python-deb822_0.3_all.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted audit 1.5.3-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 12 Jun 2007 22:33:56 +0200 Source: audit Binary: libaudit-dev libaudit0 python-audit auditd Architecture: source i386 Version: 1.5.3-2 Distribution: unstable Urgency: low Maintainer: Philipp Matthias Hahn [EMAIL PROTECTED] Changed-By: Philipp Matthias Hahn [EMAIL PROTECTED] Description: auditd - User space tools for security auditing libaudit-dev - Header files and static library for security auditing libaudit0 - Dynamic library for security auditing python-audit - Python bindings for security auditing Closes: 428066 Changes: audit (1.5.3-2) unstable; urgency=low . * debian/auditd.init: Fix inverted AUDITD_CLEAN_STOP (Closes: #428066) Files: b2eac90d536a88c3a555778609cb7f86 794 libs extra audit_1.5.3-2.dsc c08f9b40c78913ef59e3a0af5015eda2 5995 libs extra audit_1.5.3-2.diff.gz d46ec8a0c53d782451a1998f5187524b 216656 admin extra auditd_1.5.3-2_i386.deb 9512e841e29bd1893d017d2866053117 49622 libs extra libaudit0_1.5.3-2_i386.deb 23003967476ec48f8662a442af248343 91698 libdevel extra libaudit-dev_1.5.3-2_i386.deb 4776896683d48c7313f05318fb89a9fb 51020 python extra python-audit_1.5.3-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGbw2yYPlgoZpUDjkRAsX0AJ9T/zHxkhIjMvfWDGBw04qAz1pb9wCfbxxo SLcn6eUAowQRB4NhrSc9HfU= =TNAx -END PGP SIGNATURE- Accepted: audit_1.5.3-2.diff.gz to pool/main/a/audit/audit_1.5.3-2.diff.gz audit_1.5.3-2.dsc to pool/main/a/audit/audit_1.5.3-2.dsc auditd_1.5.3-2_i386.deb to pool/main/a/audit/auditd_1.5.3-2_i386.deb libaudit-dev_1.5.3-2_i386.deb to pool/main/a/audit/libaudit-dev_1.5.3-2_i386.deb libaudit0_1.5.3-2_i386.deb to pool/main/a/audit/libaudit0_1.5.3-2_i386.deb python-audit_1.5.3-2_i386.deb to pool/main/a/audit/python-audit_1.5.3-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted reportbug-ng 0.2007.06.13 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 08 Jun 2007 10:48:46 +0200 Source: reportbug-ng Binary: reportbug-ng Architecture: source i386 Version: 0.2007.06.13 Distribution: unstable Urgency: low Maintainer: Bastian Venthur [EMAIL PROTECTED] Changed-By: Bastian Venthur [EMAIL PROTECTED] Description: reportbug-ng - An easy to use alternative to Debian's classic reportbug Closes: 427008 427884 428430 Changes: reportbug-ng (0.2007.06.13) unstable; urgency=low . * Changed priority from extra to optional . * Added Catalan translation (Closes: #427884), thanks David Planella! * Added Czech translataion (Closes: #428430), thanks Miroslav Kure! * Updated Japanese translation (Closes: #427008) * Fixed typo in German translation . * Fixed small bug where reporting a new bug for a sourcepacke foo would result in a bugreport for 'package: src:foo' * Fixed small bug where searching for a single bug via bugnumber would show unstipped HTML code in the severity column if the severity is grave, serious or important * Set default severity to normal Files: a4f9eb18d8af1012d316a2dd66886329 628 utils optional reportbug-ng_0.2007.06.13.dsc 0e1ad36724a3b96cebd0eff66a8778c7 45861 utils optional reportbug-ng_0.2007.06.13.tar.gz 6c4f59e6cd0df9d9b0f4760336cd7574 37082 utils optional reportbug-ng_0.2007.06.13_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGb6n8mj66P/Yfc/gRAlHvAJ9+MmrtvHwQ72oQcbYKcSv5jl/PDgCfccou O/tzAgwZx1iqtTp6Vm61hyk= =xie7 -END PGP SIGNATURE- Accepted: reportbug-ng_0.2007.06.13.dsc to pool/main/r/reportbug-ng/reportbug-ng_0.2007.06.13.dsc reportbug-ng_0.2007.06.13.tar.gz to pool/main/r/reportbug-ng/reportbug-ng_0.2007.06.13.tar.gz reportbug-ng_0.2007.06.13_i386.deb to pool/main/r/reportbug-ng/reportbug-ng_0.2007.06.13_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted taskjuggler 2.4.0~beta2-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 12 Jun 2007 14:33:41 +0200 Source: taskjuggler Binary: taskjuggler Architecture: source amd64 Version: 2.4.0~beta2-1 Distribution: unstable Urgency: low Maintainer: Debian KDE Extras Team [EMAIL PROTECTED] Changed-By: Fathi Boudra [EMAIL PROTECTED] Description: taskjuggler - Project management application Changes: taskjuggler (2.4.0~beta2-1) unstable; urgency=low . * New upstream release. Files: 4693a035a83fc0503e2c9df5e6f320cd 823 kde optional taskjuggler_2.4.0~beta2-1.dsc bbeb9eb45c308c2d99de5a8f0de3 1774092 kde optional taskjuggler_2.4.0~beta2.orig.tar.gz 8450fa6e02b24b1eab09542ff8d53322 93409 kde optional taskjuggler_2.4.0~beta2-1.diff.gz fb7b179c56527e99f4b85c879546c74f 1334238 kde optional taskjuggler_2.4.0~beta2-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGb63EvGr7W6HudhwRAgSrAKCi8ComAOoni7BdAklaPnIh0NmMWQCgibe8 ZyYSromItejDre9FwXd0TDM= =93sX -END PGP SIGNATURE- Accepted: taskjuggler_2.4.0~beta2-1.diff.gz to pool/main/t/taskjuggler/taskjuggler_2.4.0~beta2-1.diff.gz taskjuggler_2.4.0~beta2-1.dsc to pool/main/t/taskjuggler/taskjuggler_2.4.0~beta2-1.dsc taskjuggler_2.4.0~beta2-1_amd64.deb to pool/main/t/taskjuggler/taskjuggler_2.4.0~beta2-1_amd64.deb taskjuggler_2.4.0~beta2.orig.tar.gz to pool/main/t/taskjuggler/taskjuggler_2.4.0~beta2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted glibc 2.5-11 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 11 Jun 2007 15:06:21 +0200 Source: glibc Binary: libc0.1-prof libc6-dev-amd64 locales-all libc6-i686 libc6-dev-ppc64 libc0.3-pic glibc-doc libc0.3 libc6-dev-mipsn32 libc0.1-i686 libc0.1-i386 libc6-mips64 libc6.1-dev libc6-s390x libnss-files-udeb libc0.1-dev-i386 libc6-dev-sparc64 libc6-i386 libc0.3-dev libc6-udeb libc6-dbg libc6.1-pic libc6-dev libc0.3-prof libc6-sparcv9 libc0.1-udeb libc6-dev-i386 libc6.1-prof libc6-mipsn32 libc0.1-dev locales libc6-pic libc0.3-udeb libc6-dev-powerpc libc0.1-pic libc6-ppc64 libc0.3-dbg libc0.1-dbg libc6-amd64 libc0.1 libc6-prof libc6-xen libc6-dev-mips64 libc6-powerpc libc6 libc6-sparcv9b libc6.1-udeb libc6.1-dbg nscd libc6-sparc64 libnss-dns-udeb libc6.1 libc6-dev-s390x Architecture: source amd64 all Version: 2.5-11 Distribution: unstable Urgency: low Maintainer: Aurelien Jarno [EMAIL PROTECTED] Changed-By: Aurelien Jarno [EMAIL PROTECTED] Description: glibc-doc - GNU C Library: Documentation libc6 - GNU C Library: Shared libraries libc6-dbg - GNU C Library: Libraries with debugging symbols libc6-dev - GNU C Library: Development Libraries and Header Files libc6-dev-i386 - GNU C Library: 32bit development libraries for AMD64 libc6-i386 - GNU C Library: 32bit shared libraries for AMD64 libc6-pic - GNU C Library: PIC archive library libc6-prof - GNU C Library: Profiling Libraries libc6-udeb - GNU C Library: Shared libraries - udeb (udeb) libnss-dns-udeb - GNU C Library: NSS helper for DNS - udeb (udeb) libnss-files-udeb - GNU C Library: NSS helper for files - udeb (udeb) locales- GNU C Library: National Language (locale) data [support] locales-all - GNU C Library: Precompiled locale data nscd - GNU C Library: Name Service Cache Daemon Closes: 427416 427637 427990 Changes: glibc (2.5-11) unstable; urgency=low . [ Aurelien Jarno ] * patches/hppa/submitted-pie.diff: new patch to fix PIE on hppa. Patch by Sébastien Bernard and John David Anglin. Closes: #427990. * debian/debhelper.in/libc.preinst: use -e instead of -f to canonicalize links. Closes: #427416. . [ Pierre Habouzit ] * pass -X/usr/lib/debug to dh_makeshlibs so that libc6-dbg gets no useless shlibs. Closes: #427637. Files: 14483ab8687b0ad83efbad1877082ebd 2295 libs required glibc_2.5-11.dsc 9346da2a43c4c3f2ca65c18f88b6c1c8 1137586 libs required glibc_2.5-11.diff.gz cda691b55a54d7f187533d0d230d506e 1607424 doc optional glibc-doc_2.5-11_all.deb 3e3354cf7951fbc870e8fd33018ef773 4085452 libs standard locales_2.5-11_all.deb 488f1de236ace8388e9fbaf9d2b95f4f 4889460 libs required libc6_2.5-11_amd64.deb 75f4e5af497d0ddcd9949cce2eb74b91 2472970 libdevel optional libc6-dev_2.5-11_amd64.deb 4560c36e6b46f1f44f5c85ec0c2f4b60 1910510 libdevel extra libc6-prof_2.5-11_amd64.deb 5e0f33da79b835238272236d6c8d0c4b 1454018 libdevel optional libc6-pic_2.5-11_amd64.deb 6f302697cd57b6ef9c00a4d5e3934556 1912520 libs extra locales-all_2.5-11_amd64.deb 6f124f14c0b47b6ca49b024402342922 3692182 libs optional libc6-i386_2.5-11_amd64.deb 63cf1cfb27c0cfc434e7ee1c9bdc0df7 1859852 libdevel optional libc6-dev-i386_2.5-11_amd64.deb babad2df19fb3e5e33b8478754988114 157578 admin optional nscd_2.5-11_amd64.deb bb2e2231b0d83d843afa5329ef6cbc74 5081846 libdevel extra libc6-dbg_2.5-11_amd64.deb 778dd5224f7b463a12b5dddfa1ddbf8e 1101882 debian-installer extra libc6-udeb_2.5-11_amd64.udeb 2f06f4d8b7498a9e2e33d7023d263b60 9500 debian-installer extra libnss-dns-udeb_2.5-11_amd64.udeb 7bb6dc52bba3ebbdc4b31b31ca1efbf6 17770 debian-installer extra libnss-files-udeb_2.5-11_amd64.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGbVpIw3ao2vG823MRAkGDAJ4lAHJJ2OtAjx4fWkvs/Hz5EBZdogCeL386 Uwy8pLOg9ThcF0VwqVFztQ8= =7dB4 -END PGP SIGNATURE- Accepted: glibc-doc_2.5-11_all.deb to pool/main/g/glibc/glibc-doc_2.5-11_all.deb glibc_2.5-11.diff.gz to pool/main/g/glibc/glibc_2.5-11.diff.gz glibc_2.5-11.dsc to pool/main/g/glibc/glibc_2.5-11.dsc libc6-dbg_2.5-11_amd64.deb to pool/main/g/glibc/libc6-dbg_2.5-11_amd64.deb libc6-dev-i386_2.5-11_amd64.deb to pool/main/g/glibc/libc6-dev-i386_2.5-11_amd64.deb libc6-dev_2.5-11_amd64.deb to pool/main/g/glibc/libc6-dev_2.5-11_amd64.deb libc6-i386_2.5-11_amd64.deb to pool/main/g/glibc/libc6-i386_2.5-11_amd64.deb libc6-pic_2.5-11_amd64.deb to pool/main/g/glibc/libc6-pic_2.5-11_amd64.deb libc6-prof_2.5-11_amd64.deb to pool/main/g/glibc/libc6-prof_2.5-11_amd64.deb libc6-udeb_2.5-11_amd64.udeb to pool/main/g/glibc/libc6-udeb_2.5-11_amd64.udeb libc6_2.5-11_amd64.deb to pool/main/g/glibc/libc6_2.5-11_amd64.deb libnss-dns-udeb_2.5-11_amd64.udeb to pool/main/g/glibc/libnss-dns-udeb_2.5-11_amd64.udeb libnss-files-udeb_2.5-11_amd64.udeb to pool/main/g/glibc/libnss-files-udeb_2.5-11_amd64.udeb locales-all_2.5-11_amd64.deb to pool/main/g/glibc/locales-all_2.5-11_amd64.deb locales_2.5-11_all.deb
Accepted gtk+2.0 2.10.13-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 13 Jun 2007 10:06:49 +0200 Source: gtk+2.0 Binary: libgtk2.0-dev gtk2-engines-pixbuf libgtk-directfb-2.0-dev libgtk-directfb-2.0-0 libgtk-directfb-2.0-0-udeb libgtk2.0-0-dbg libgtk2.0-0 libgtk2.0-doc gtk2.0-examples libgtk2.0-common libgtk2.0-bin Architecture: source i386 all Version: 2.10.13-1 Distribution: unstable Urgency: low Maintainer: Sebastien Bacher [EMAIL PROTECTED] Changed-By: Loic Minier [EMAIL PROTECTED] Description: gtk2-engines-pixbuf - Pixbuf-based theme for GTK+ 2.x gtk2.0-examples - Examples files for the GTK+ 2.0 libgtk-directfb-2.0-0 - The GTK+ graphical user interface library - DirectFB runtime libgtk-directfb-2.0-0-udeb - The GTK+ graphical user interface library - minimal runtime (udeb) libgtk-directfb-2.0-dev - Development files for the GTK+ library - DirectFB version libgtk2.0-0 - The GTK+ graphical user interface library libgtk2.0-0-dbg - The GTK+ libraries and debugging symbols libgtk2.0-bin - The programs for the GTK+ graphical user interface library libgtk2.0-common - Common files for the GTK+ graphical user interface library libgtk2.0-dev - Development files for the GTK+ library libgtk2.0-doc - Documentation for the GTK+ graphical user interface library Changes: gtk+2.0 (2.10.13-1) unstable; urgency=low . * Bump Conflicts to iiimf-client-gtk 12.3.91-4. * Upload to unstable; drop check-dist include. * New upstream release; no API change. - Drop patches 011_directfb-build-fixes-from-head, 013_gdkproperty-directfb-strdup, 032_filechooser-sizing, 090_capslock-numlock-im-thai merged upstream. - Update relibtoolizing patch, 070_mandatory-relibtoolize. Files: 1f9ea34742785457509acecadc86b917 1489 libs optional gtk+2.0_2.10.13-1.dsc 729abacb8cba288595022be1f2d1fd40 22203789 libs optional gtk+2.0_2.10.13.orig.tar.gz 272e1c36f424e072610242f5ea598b09 92217 libs optional gtk+2.0_2.10.13-1.diff.gz e52859d20529747b3e1b17d7a704aa55 4953442 misc optional libgtk2.0-common_2.10.13-1_all.deb 0d0503fe264d3cee22c337148c8e5329 7182 misc optional libgtk2.0-bin_2.10.13-1_all.deb 76f58f366f9257a874457af68084033a 2888094 doc optional libgtk2.0-doc_2.10.13-1_all.deb 214040d7b7c728a403c8bb0e069c7c2b 1825134 libs optional libgtk2.0-0_2.10.13-1_i386.deb e5ef21a2292ea09125868cde66fb3fe0 1545278 libs optional libgtk-directfb-2.0-0_2.10.13-1_i386.deb 32b671ca18720eca56b0fa72d377abbe 1592848 debian-installer extra libgtk-directfb-2.0-0-udeb_2.10.13-1_i386.udeb 451dd0c26c1bacd2d36f667c72f83ed2 2511296 libdevel optional libgtk2.0-dev_2.10.13-1_i386.deb 9be0ad502bcf9b5a7c3073cefc419ac1 5486 libdevel optional libgtk-directfb-2.0-dev_2.10.13-1_i386.deb 2d2b25fb5c5a120a10a78eea15d39aa4 8516968 libdevel extra libgtk2.0-0-dbg_2.10.13-1_i386.deb 2ef930219ec5c1cb728ed87c4df39251 459534 x11 extra gtk2.0-examples_2.10.13-1_i386.deb ea4b86964cb307026fa6365c99eca62a 159472 graphics optional gtk2-engines-pixbuf_2.10.13-1_i386.deb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGb7C94VUX8isJIMARAjQBAJ4vR3FqHUpcH4flWnhc+EKyJgsWUQCgoVJ9 r6DEcQOuMIgnsqSUPfyd74I= =gOPj -END PGP SIGNATURE- Accepted: gtk+2.0_2.10.13-1.diff.gz to pool/main/g/gtk+2.0/gtk+2.0_2.10.13-1.diff.gz gtk+2.0_2.10.13-1.dsc to pool/main/g/gtk+2.0/gtk+2.0_2.10.13-1.dsc gtk+2.0_2.10.13.orig.tar.gz to pool/main/g/gtk+2.0/gtk+2.0_2.10.13.orig.tar.gz gtk2-engines-pixbuf_2.10.13-1_i386.deb to pool/main/g/gtk+2.0/gtk2-engines-pixbuf_2.10.13-1_i386.deb gtk2.0-examples_2.10.13-1_i386.deb to pool/main/g/gtk+2.0/gtk2.0-examples_2.10.13-1_i386.deb libgtk-directfb-2.0-0-udeb_2.10.13-1_i386.udeb to pool/main/g/gtk+2.0/libgtk-directfb-2.0-0-udeb_2.10.13-1_i386.udeb libgtk-directfb-2.0-0_2.10.13-1_i386.deb to pool/main/g/gtk+2.0/libgtk-directfb-2.0-0_2.10.13-1_i386.deb libgtk-directfb-2.0-dev_2.10.13-1_i386.deb to pool/main/g/gtk+2.0/libgtk-directfb-2.0-dev_2.10.13-1_i386.deb libgtk2.0-0-dbg_2.10.13-1_i386.deb to pool/main/g/gtk+2.0/libgtk2.0-0-dbg_2.10.13-1_i386.deb libgtk2.0-0_2.10.13-1_i386.deb to pool/main/g/gtk+2.0/libgtk2.0-0_2.10.13-1_i386.deb libgtk2.0-bin_2.10.13-1_all.deb to pool/main/g/gtk+2.0/libgtk2.0-bin_2.10.13-1_all.deb libgtk2.0-common_2.10.13-1_all.deb to pool/main/g/gtk+2.0/libgtk2.0-common_2.10.13-1_all.deb libgtk2.0-dev_2.10.13-1_i386.deb to pool/main/g/gtk+2.0/libgtk2.0-dev_2.10.13-1_i386.deb libgtk2.0-doc_2.10.13-1_all.deb to pool/main/g/gtk+2.0/libgtk2.0-doc_2.10.13-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted glib2.0 2.13.4-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 13 Jun 2007 10:52:27 +0200 Source: glib2.0 Binary: libglib2.0-0-dbg libglib2.0-udeb libglib2.0-data libglib2.0-dev libglib2.0-doc libglib2.0-0 Architecture: source i386 all Version: 2.13.4-1 Distribution: experimental Urgency: low Maintainer: Sebastien Bacher [EMAIL PROTECTED] Changed-By: Loic Minier [EMAIL PROTECTED] Description: libglib2.0-0 - The GLib library of C routines libglib2.0-0-dbg - The GLib libraries and debugging symbols libglib2.0-data - Common files for GLib library libglib2.0-dev - Development files for the GLib library libglib2.0-doc - Documentation files for the GLib library libglib2.0-udeb - The GLib library of C routines - minimal runtime (udeb) Changes: glib2.0 (2.13.4-1) experimental; urgency=low . * Also honor parallel=n in DEB_BUILD_OPTIONS. * New upstream release series; these are development releases, the new API may still change incompatibly. - Target at experimental; include check-dist. - Bump up shlibs to = 2.13.4. * New patch but disabled, 01_gettext-desktopfiles, permits overriding the gettext domain when desktop files have such a field; found in the Ubuntu package. Files: 7497794247ed1c401487d258e66feff8 877 libs optional glib2.0_2.13.4-1.dsc c6f5ba5dfd84329a5c974085321fdd57 4365205 libs optional glib2.0_2.13.4.orig.tar.gz 06b89fa696830c8bcad9f8fe8255be39 14196 libs optional glib2.0_2.13.4-1.diff.gz d8fc017866f5b78c34b39131fa038be4 307094 misc optional libglib2.0-data_2.13.4-1_all.deb 4219248c80d56b28bbae1386d60c3d12 821754 doc optional libglib2.0-doc_2.13.4-1_all.deb df3e28f8046ded2c54a7377f9ab102fd 589338 libs optional libglib2.0-0_2.13.4-1_i386.deb e31b6a81514cb5caef0ec2ebbaf74f9d 711774 debian-installer optional libglib2.0-udeb_2.13.4-1_i386.udeb 8dcd85acbff21edb63249bca79d6b64c 628256 libdevel optional libglib2.0-dev_2.13.4-1_i386.deb d9f563fea95396ff03d01b8a030daf39 680408 libdevel extra libglib2.0-0-dbg_2.13.4-1_i386.deb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGb7QZ4VUX8isJIMARAv2SAJsFGsXsT9Zr/8Au3z6uY1v/aZ1U5QCgk1Yz +Nn/CzwoUlpiN9oshkMA8vI= =D9WH -END PGP SIGNATURE- Accepted: glib2.0_2.13.4-1.diff.gz to pool/main/g/glib2.0/glib2.0_2.13.4-1.diff.gz glib2.0_2.13.4-1.dsc to pool/main/g/glib2.0/glib2.0_2.13.4-1.dsc glib2.0_2.13.4.orig.tar.gz to pool/main/g/glib2.0/glib2.0_2.13.4.orig.tar.gz libglib2.0-0-dbg_2.13.4-1_i386.deb to pool/main/g/glib2.0/libglib2.0-0-dbg_2.13.4-1_i386.deb libglib2.0-0_2.13.4-1_i386.deb to pool/main/g/glib2.0/libglib2.0-0_2.13.4-1_i386.deb libglib2.0-data_2.13.4-1_all.deb to pool/main/g/glib2.0/libglib2.0-data_2.13.4-1_all.deb libglib2.0-dev_2.13.4-1_i386.deb to pool/main/g/glib2.0/libglib2.0-dev_2.13.4-1_i386.deb libglib2.0-doc_2.13.4-1_all.deb to pool/main/g/glib2.0/libglib2.0-doc_2.13.4-1_all.deb libglib2.0-udeb_2.13.4-1_i386.udeb to pool/main/g/glib2.0/libglib2.0-udeb_2.13.4-1_i386.udeb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted postr 0.7-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 13 Jun 2007 11:31:17 +0100 Source: postr Binary: postr Architecture: source all Version: 0.7-1 Distribution: unstable Urgency: low Maintainer: Ross Burton [EMAIL PROTECTED] Changed-By: Ross Burton [EMAIL PROTECTED] Description: postr - upload photos to Flickr Closes: 428455 Changes: postr (0.7-1) unstable; urgency=low . * New upstream release - Uploading without a set works (Closes: #428455) Files: e6490062acae3eb2c4c0c7999499adef 556 graphics optional postr_0.7-1.dsc 1f2851b9cc3eb221b6d13a60b083c98f 63065 graphics optional postr_0.7.orig.tar.gz 5681536aa8fee210e9b7c188e5b73fd1 2070 graphics optional postr_0.7-1.diff.gz 9bfa2cb8c9fc289acea773667e135f58 57134 graphics optional postr_0.7-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGb8f6LQnkR9C0M98RAhroAJkBxse+08cJ8+UBE2ZJ35BiqCGSsACgyDr+ QcwNC1AXP1tCnALmV7OFCFo= =gVAg -END PGP SIGNATURE- Accepted: postr_0.7-1.diff.gz to pool/main/p/postr/postr_0.7-1.diff.gz postr_0.7-1.dsc to pool/main/p/postr/postr_0.7-1.dsc postr_0.7-1_all.deb to pool/main/p/postr/postr_0.7-1_all.deb postr_0.7.orig.tar.gz to pool/main/p/postr/postr_0.7.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted openoffice.org 2.2.1-1 (source all powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 8 Jun 2007 17:24:56 +0200 Source: openoffice.org Binary: openoffice.org-l10n-dz openoffice.org-gtk openoffice.org-l10n-ts openoffice.org-l10n-zu openoffice.org-help-zh-cn openoffice.org-help-ru openoffice.org-l10n-ru openoffice.org-l10n-be-by openoffice.org-l10n-ka openoffice.org-writer openoffice.org-l10n-lt openoffice.org-l10n-gu-in openoffice.org-help-en-gb openoffice.org-l10n-lo openoffice.org-l10n-da openoffice.org-kde openoffice.org-help-en-us openoffice.org-l10n-hu openoffice.org-l10n-pt openoffice.org-core openoffice.org-l10n-nb openoffice.org-l10n-ca openoffice.org-help-sl openoffice.org-l10n-ve ttf-opensymbol openoffice.org-l10n-ss openoffice.org-style-tango openoffice.org-evolution openoffice.org-filter-mobiledev openoffice.org-l10n-et openoffice.org-math openoffice.org-style-crystal openoffice.org-l10n-bn openoffice.org-l10n-tn openoffice.org-qa-api-tests openoffice.org-l10n-ns openoffice.org-l10n-ne openoffice.org-l10n-el openoffice.org-l10n-ja openoffice.org-l10n-pt-br openoffice.org-l10n-af openoffice.org-l10n-in openoffice.org-dev openoffice.org-help-nl openoffice.org-l10n-tr openoffice.org-help-cs openoffice.org-l10n-pl openoffice.org-help-de openoffice.org-help-pl openoffice.org-l10n-gl openoffice.org-qa-tools openoffice.org-dbg openoffice.org-l10n-eo openoffice.org-l10n-it openoffice.org-java-common broffice.org openoffice.org-help-it openoffice.org-l10n-sl openoffice.org-l10n-he openoffice.org-help-sv openoffice.org-dtd-officedocument1.0 openoffice.org-help-ja openoffice.org-l10n-or-in openoffice.org-common openoffice.org-help-pt openoffice.org-help-hi-in openoffice.org-l10n-tg openoffice.org-l10n-vi openoffice.org-l10n-cy openoffice.org-gnome openoffice.org-l10n-ta-in openoffice.org-l10n-nr openoffice.org-l10n-cs openoffice.org-l10n-sr-cs openoffice.org-help-es openoffice.org-l10n-hr openoffice.org-base openoffice.org-l10n-fr openoffice.org-l10n-zh-cn openoffice.org-l10n-es openoffice.org-l10n-zh-tw openoffice.org-l10n-de openoffice.org-dev-doc openoffice.org-style-industrial openoffice.org-help-dz openoffice.org-style-andromeda openoffice.org-help-et openoffice.org-l10n-sk openoffice.org-l10n-nn openoffice.org-l10n-bs openoffice.org-l10n-fa openoffice.org-l10n-ga openoffice.org-help-da openoffice.org-style-hicontrast openoffice.org-l10n-za openoffice.org-l10n-pa-in openoffice.org-l10n-lv openoffice.org-l10n-ko openoffice.org-help-zh-tw openoffice.org-l10n-en-za openoffice.org-l10n-st openoffice.org-l10n-en-gb openoffice.org-l10n-bg openoffice.org-calc python-uno openoffice.org-l10n-ml-in openoffice.org-l10n-mk openoffice.org-l10n-as-in openoffice.org openoffice.org-l10n-rw mozilla-openoffice.org openoffice.org-l10n-hi-in openoffice.org-l10n-te-in openoffice.org-help-pt-br openoffice.org-officebean openoffice.org-draw openoffice.org-l10n-uk openoffice.org-gcj openoffice.org-l10n-br openoffice.org-l10n-ku openoffice.org-help-fr openoffice.org-help-hu libuno-cil openoffice.org-l10n-fi openoffice.org-help-ko openoffice.org-filter-binfilter openoffice.org-l10n-nl openoffice.org-impress openoffice.org-l10n-sv openoffice.org-l10n-th libmythes-dev openoffice.org-l10n-xh openoffice.org-help-gl Architecture: all powerpc source Version: 2.2.1-1 Distribution: unstable Urgency: low Maintainer: Debian OpenOffice Team [EMAIL PROTECTED] Changed-By: Rene Engelhard [EMAIL PROTECTED] Description: broffice.org - BrOffice.org office suite libmythes-dev - simple thesaurus library (development files) libuno-cil - Mono binding for OpenOffice.org mozilla-openoffice.org - OpenOffice.org Mozilla plugin openoffice.org - OpenOffice.org Office suite openoffice.org-base - OpenOffice.org office suite - database openoffice.org-calc - OpenOffice.org office suite - spreadsheet openoffice.org-common - OpenOffice.org office suite architecture independent files openoffice.org-core - OpenOffice.org office suite architecture dependent files openoffice.org-dbg - OpenOffice.org debug symbols openoffice.org-dev - OpenOffice.org SDK -- development files openoffice.org-dev-doc - OpenOffice.org SDK -- documentation openoffice.org-draw - OpenOffice.org office suite - drawing openoffice.org-dtd-officedocument1.0 - OfficeDocument 1.0 DTD (OpenOffice.org 1.x) openoffice.org-evolution - Evolution Addressbook support for OpenOffice.org openoffice.org-filter-binfilter - Legacy filters (e.g. StarOffice 5.2) for OpenOffice.org openoffice.org-filter-mobiledev - Mobile Devices Filters for OpenOffice.org openoffice.org-gcj - OpenOffice.orgs Java libraries (native for use with GIJ) openoffice.org-gnome - GNOME Integration for OpenOffice.org (VFS, GConf) openoffice.org-gtk - GTK Integration for OpenOffice.org (Widgets, Dialogs, Quickstarte openoffice.org-help-cs - Czech help for OpenOffice.org openoffice.org-help-da - Danish help for OpenOffice.org openoffice.org-help-de - German help for
