Re: help
Hi, sounds like your hard disks are dying (I'm not sure about this, though). You should really backup your data regularly, anyhow, it is too late now, but you should do so in future. If you really need your data, it seems to be a good choice to pay someone with experience in this area to rescue your data. If you really want to try this yourself (doing things wrong further worsens the situation, you have been warned), here is a quick summary of a possible way of proceeding: 1. Check the self monitoring of the hard disks using 'smartctl -a /dev/whatever' and if there is anything suspicious, turn the server off immediately. If your server is already turned off, check the hard disk's self monitoring after step 5. 2. Buy an external hard drive that is larger than your current ones. 3. Go to http://grml.org/download/ and download the grml rescue/live CD. 4. Burn the image to a CD-ROM or create a bootable USB device containing the image. 5. Boot your server using this CD-ROM, using 'forensic' as boot parameter. This boot parameter is important to avoid writing to the possibly dying harddisks. 6. Try to create a image of the old harddisks on the new harddisk. http://www.forensicswiki.org/wiki/Ddrescue describes a tool that is able to do such things (should be installed on the grml CD by default). If you mix up device numbers, which could be different now, you could overwrite the data you want to rescue, so be careful. 7. Turn the server off, since you continue rescuing on a different computer. 8. Create an additional copy of the images you created. Everything you do from now on must happen on the copies to avoid changing the image you created. 9. Now you can do things like running fsck, mounting the image and so on. To access partitions on the image you can use kpartx (if you created images of the partitions instead of the hard disk you don't need kpartx, but creating an image of the hard disks is less error prone). Since you never did something like this before, you should experiment with the tools before doing what I described above, or even better: let someone with experience in this area do it ... Regards Carsten -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120207124727.ga...@furrball.stateful.de
Re: [DEP-5] [patch] Renaming the Format-Specification field to ‘Format’.
Hi,
thank you for addressing this old suggestions :)
* Charles Plessy [2010-08-14 11:29 +0900]:
Renaming the Format-Specification field:
...
Carsten Hey (and perhaps others) also questionned if the field should
be required and if it should contain an URL:
http://lists.debian.org/2009122529.ga5...@foghorn.stateful.de
I guess my wording might not have been that clear, sorry for that. The
format field should IMHO be required. The Optional ? part in
notes.mdwn in your commit thus should be removed. I wanted to question
if Files: should be required or if Files: * should be assumed instead
if the files field is missing.
Back then someone answered to my question whether using URLs or version
numbers would be preferable and had good arguments for using a URL. The
length of the URL was also addressed in another response, something like
It was never planned to use the URL of the svn revision after the first
version of DEP-5 is released has been said. Maybe we should move to
a stable URL like:
Format: http://dep5.debian.{net,org}/$version
$version could be ${year}.${number} or ${major_number}.${minor_number}.
It has been said, that the DEP-5 svn repository is not anymore the main
repository for DEP-5, this should be reflected on
http://dep.debian.net/, which still points to the svn repository.
Besides the correct URL to the bzr repository there should be a way to
read a recent revision using http. Instructions how to update the page
can be found on http://dep.debian.net/depdn-howto/ (I can't do this
myself since I don't know a URL of a recent bzr export).
If we would release stable DEP-5 revisions as debian package and would
add Vcs-* fields, people could use debcheckout to check out the current
revision.
I might not be up to date in this point, but it looks like the
Maintainer: field still points to the upstream maintainer, this
seems be be very confusing due the fact that Debian packagers often are
referenced as maintainers. A way to make this less ambiguous would be
using Upstream: for the upstream maintainer and still accepting but
deprecating Maintainer: (and not removing it from the spec before end
of this decade).
Regards
Carsten
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100814102832.ga12...@foghorn.stateful.de
Re: [DEP-5] [patch] License table: more links and licenses.
* Charles Plessy [2010-08-14 16:58 +0900]: After looking at http://spdx.org/licenses/, I realise that the very existence of a license list in DEP-5 is in question (not in this thread). However, since I had a version of the DEP with a more comprehensive use of web links for licenses, I propose the attached patch anyway. ... I already mentioned this points in an old mail or in a wiki: Once upon a time the following dialog happend: me... great, we need a licence. What do you think about the expat license? well_known_dd What? Which license? meMIT well_known_dd Why don't you call it MIT then? Anyway, I'm fine with that. Shouldn't it be mentioned in the licenses description that the expat license sometimes wrongly is referred to as MIT license? Since Berkley removed the advertising clause from their published code (but obviously could do this not for code they do not own the copyright) referring to the original BSD license just as BSD seems to be imprecise, I would prefer BSD-4. Especially the explanation should mention that BSD is the original 4-clause variant. On Debian /usr/share/common-licenses/BSD even is a 3-clause BSD license. Counting from one to four is more easy than remembering which licenses FreeBSD and TNF use nowadays, we should at least consider adding these numbers to the licenses description and maybe also make BSD-2 respectively BSD-3 aliases for FreeBSD and NetBSD. Regards Carsten -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100814112645.gb12...@foghorn.stateful.de
Re: MIT and Expat licenses; lice nses ‘similar to’ a BSD licens e (Re: [DEP-5] [patch] License table: more links and licenses.)
* Charles Plessy [2010-08-15 00:20 +0900]: Le Sat, Aug 14, 2010 at 01:26:45PM +0200, Carsten Hey a écrit : Shouldn't it be mentioned in the licenses description that the expat license sometimes wrongly is referred to as MIT license? I wonder if the tradition of using the “Expat” name to refer unambiguously to one of the variants of the “MIT” license is widespread or Debian-specific. If I would need to make a guess I would guess: the FSF was first in doing so. I think that the DEP should not fall in the trap of trying to make some extensive license classification. We actually removed most of what made the short name parseable during the off-line preparative work, and I will prehaps go further and propose the removal of the description of the version semantics, that is for instance: GPL-2 and GPL-3 would be two separate short names, not two version of the GPL short name. Ontologies and license metadata are probably better in the scope of another document. GPL, GPL-1, GPL-1+, GPL-2, GPL-2+, GPL-3, GPL-3+ ... that would be a lot of short names, even if GPL-1 and GPL-1+ could be merged and GPL could be removed. Besides GPL there are other licenses with different versions like LGPL and there is code that is licensed CDDL-1 although there is only one CDDL version currently. If it provides ‘MIT’ as a keyword, and the full text of the MIT license in annex, then it will be clear what ‘MIT’ means in the context of the DEP. Interstinly, SPDX has not yet made up their minds about the MIT license: Your approach is interesting, but on the other hand I don't think we should encourage calling the Expat license MIT license by using MIT as keyword. If we just change the description everything should be clear without the need to use a search engine to find out what the Expat License is. FSF says: | Expat License | | This is a simple, permissive non-copyleft free software license, | compatible with the GNU GPL. It is sometimes ambiguously referred to | as the MIT License. Our description is just (or rather was 240 days ago): | Expat - The Expat License. Now, for the BSD: ... If consensus converges on using a ‘similar to’ keyword, I will submit a patch. I see the problem you want so solve and I'm unsure if a such a keyword addition would finally make DEP-5 easier to use or more complicated. Anyone else? The FSF has also good (and non-free) descriptions of the various BSD Licenses: | FreeBSD license | | This is the original BSD license with the advertising clause and | another clause removed. (It is also sometimes called the “2-clause BSD | license”.) ... | Modified BSD license | | ... | | This is the original BSD license, modified by removal of the | advertising clause. ... | | | This license is sometimes referred to as the 3-clause BSD license. Have a nice sunday, Thanks, you too. You are always a bit ahead of the times ;) Carsten -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100814163926.ga15...@foghorn.stateful.de
Re: Problems with NM Front Desk
* Manuel A. Fernandez Montecelo [2010-07-02 19:01 +0200]: [4] Including not acknowledging NMUs (many of them FTBFS), not replying to most (any?) bug reports, not replying when people asked to update the software or orphan it if he was not interested anymore, not replying to my (private) offering to co-maintain them as I am doing unofficially with OpenSceneGraph that I sent more than 2 months ago, and a previous warning about the intention to NMU the packages... all this while he did attend other packages in the past weeks, so he's not Missing in Action. Sounds like these packages are in fact orphaned, at least it should be ok if you add yourself as uploader with your next upload. Next step is to become DM and then if you want to DD ... Carsten -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100706122457.ga28...@foghorn.stateful.de
Re: Estadistical proyect.
Hi, sorry for my late answer, I read this list only rarely. * angel [2010-04-21 10:58 +0200]: In case Debian is interested in having someone work on a statistical project of any nature (the project would be supervised by professors of the Statistics and Operations Research department of the University of Granada and and Debian would not be charged with any costs whatsoever), please feel free to contact me. Since your request has been misunderstood partly, I subsume it at first: You want to do a small to medium-sized statistical project and you don't want to program in a non-statistical language during this project. Debian needs to provide you access to the data required to complete your project and most importantly needs to tell you what information it is interested in. Access to the data is easy: Stefano already mentioned Ultimate Debian Database (UDD) as possible data source. It should contain everything you would need in such a project. If you don't want to create a local copy of the database using the provided dump you almost certainly should get a guest-account on alioth.debian.org to access the database without any problems. As you might know, Debian divides bugs by severities, the most important ones are critical, serious and grave, these are release critical. Additionally there are important, normal, minor and wishlist. Besides severities there are things like fixed and found and so on, all this is documented on http://bugs.debian.org/ below the heading Bug tracking system documentation. We want to release the next Debian release Squeeze soon and to do this we need to get the number of release critical bugs in testing, currently named Squeeze, to 0 (except some ignored bugs). To be able to improve this process and thus improve Debian in general it would be nice if we would have some statistical data about how bugs have been fixed in the past. Understanding where we still have problems is the first step to resolve them. :) Some questions to be answered could be: * How long does it take on average until a bug with a particular severity gets fixed and how is the variance? Does this change if Debian is frozen (frozen describes the time before the actual release with a more restricted package migration to testing)? * Is there a correlation between the number of installations according to popcon and the time until a bug gets fixed? * Is there a correlation between the size of a package or the packages priority [1] and the average bug fixing time? * How does the number of people maintaining a package relate to bug fixing time and how does it relate to the number of unfixed bugs per package? Rationale for this is that we encourage single maintainers of important packages (with priority important and priority required) to switch to maintaining these packages in a team but we lack data to support our guess that team maintenance is really more efficient. * How does the number of bugs reported per time unit change after a new upstream release is packaged in comparison to releasing a new Debian revision? Does which part of the upstream version number has been incremented have any influence on it? I expect for example a 2.0 release to contain more bugs on average than a 2.2 release. * We currently migrate packages that don't introduce new release critical bugs to testing after being in unstable for 10 days (unless the maintainer or the release team overwrite this or other packages prevent it). Is this a good choice according to the time after an upload when most release critical bugs are reported? * Is there a relation between bug fixing and the time the last maintainer upload happend? Similar question is if there is a relation between bug fixing and the number of non maintainer uploads (NMUs) in the last n years? * How does the probability of a release critical bug being fixed in a NMU instead of a regular maintainer upload raise over time? * Is there a significant difference between bug fixing in officially maintained packages and in packages maintained by the QA team respectively orphaned packages? * Are certain programming languages or packages in certain sections more prone to FTBFS (fails to build from source) bugs, security related bugs or bugs in general? * A combination of probability of an release critical bugs being filed over time in conjunction with the two former questions and the number of installations according to popcon could possibly be used to help people to decide if a package should be removed from Debian or orphaned if the former maintainer lost interest. Currently I neither have an idea how this could be done in a sane way nor if it can be done in a sane way at all. I think you got the idea. If you deal with data and these question some time you should get a feeling which one might be relevant and interesting and which one can be ignored. If
Re: DEP5: Machine-readable debian/copyright (the paperwork)
Hi, a few remarks about DEP #5: The Expat License is rather unknown under this name, thus I propose adding a comment like this to its description: Expat The Expat License (often referred as MIT license, see comment in *Problematic Licenses*) It's might not be obvious for all which BSD licenses are meant by BSD and FreeBSD, thus I propose appending (3-clause BSD) and respectively (2-clause BSD) to their descriptions. Format-Specification: is needlessly long, Format: would be sufficient. Forking this spec would render all (to be written) tools to parse changelog entries useless and it would complicate exchanging Debian source packages between deb based distributions. Except being able to fork this spec easily I see no reason to add its URI instead of a version number to changelog files. I would prefer Format: $major.$minor[.$revision] (for example Format: 0.0.r135 or Format: 1.0) over Format-Specification: $uri, even when the URI will be much shortened in future. Carsten -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Differentiating BSD-style licenses (was: DEP5: Machine-readable debian/copyright (the paperwork))
On Wed, Dec 23, 2009 at 09:57:05AM +1100, Ben Finney wrote: Carsten Hey cars...@debian.org writes: It's might not be obvious for all which BSD licenses are meant by BSD and FreeBSD, thus I propose appending (3-clause BSD) and respectively (2-clause BSD) to their descriptions. That's even more ambiguous, though. It doesn't say *which* clauses; any three-clause license similar to a BSD license could be “3-clause BSD”. To clarify, just in case I was not specific enough, I proposed an addition. For example, the following line: BSD Berkeley software distribution license would become: BSD Berkeley software distribution license (3-clause BSD) I don't think adding additional information can make this more ambiguous. I also don't know any project using the “attribution” clause but not the “no endorsement” clause, so at least for people being familiar with licenses like DDs this should be rather clear. Anyhow, I don't care whether we call it 3-clause BSD, new BSD, revised BSD or original BSD with the “attribution” clause removed. “BSD” without any further explanation could refer to the original BSD license, the new one or even the simplified one and this is too unspecific for a specification. I've advocated making mnemonic descriptors for the particular clauses, e.g. “attribution”, “no endorsement”, etc. Those have the disadvantage of not being well-known, but the advantage (compared to simply counting the clauses) that at least a guess as to which clauses are being referenced will likely be right. These descriptors would be a very elegant way to differentiate between the different BSD licenses, but I guess such seldom used licenses like 1-clause BSD or 3-clause BSD with “attribution” but without “no endorsement” should better be handled as “other” instead of extending the format to catch every corner case. Carsten -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Differentiating BSD-style licenses (was: DEP5: Machine-readable debian/copyright (the paperwork))
On Wed, Dec 23, 2009 at 01:22:47PM +0900, Charles Plessy wrote: Here are reasons why I do not think that licenses inspired by the BSD license can be efficiently classified by counting the number of clauses. First, the license of the Berkeley Software Distribution (BSD) source code copyrighted by the Regents of the University of California has a non-endorsement clause that is frequently edited each time this license is used as a template by another project. Therefore, it is not possible to use the same short name for them, since “3-clause BSD” would not refer to the same license when sources from two different projects are aggregated in the same package. Using the following description would it make less ambiguous even without the need to check the annex: BSD Revised Berkeley software distribution license To remove any ambiguity, we can add an annex to the DEP with a copy of all the licences for which it specifies a short name. I think adding an annex is a good idea. For the licenses inspired by the Regents of the University of California’s BSD license, I would rather try to work on extending the DEP to include a concept of being ‘similar to’ other licenes. This would be useful for other cases than the BSD. I like the idea of adding a similarity concept too, but to comply with: | Redistributions in binary form must reproduce the above copyright | notice, this list of conditions and the following disclaimer in the | documentation and/or other materials provided with the distribution. ... there needs to be an exact copy of the licence in the binary itself, the copyright file or in e.g. /usr/share/common-licenses/BSD. So adding such a concept could help to make copyright files more machine readable but not to shorten them for packages using “similar licenses”. Regards Carsten -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
Steve Langasek wrote: Does that mean you don't think Ubuntu developers contribute fixes back to Debian today? As security, contributing fixes back to Debian is not a product nor a state, it's a process. We should all be interested in optimizing this process further. http://patches.ubuntu.com/ indeed makes the packages easier to merge but it is not as powerful as our patch tracking system [1]. One possible step to improve the situation could be a similar service provided by Ubuntu based on the work which already has been done by Sean Finney. The source code is available in a public repository and it is GPL2 licensed. After such a service would have been implemented one could think about things like adding a special tag to patch headers to recommend these patches to be merged by Debian. It could also be useful to be able to specify how strong such a recommendation is. Is there already a (wiki) page which describes how a Debian maintainer can track his packages in Ubuntu or how to handle Ubuntu originated bugs? If this is the case it should be promoted better, e.g. in Misc Developer News. Carsten [1] http://patch-tracking.debian.net/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
Why not freeze in June 2010 instead of December 2009 and then freeze again in December 2011*? Mark Shuttleworth seems (at least seemed) to be fine with delaying Ubuntu LTS by half a year to get Ubuntu and Debian in sync [1]: | The LTS will be either 10.04 or 10.10 - based on the conversation that | is going on right now between Debian and Ubuntu. Besides having more time to make Squeeze a great Debian release, one could also revisit the need to support skip-upgrades if the freeze would be postponed. In his blog Lucas highlights the similarity between the next Ubuntu LTS and the next Debian release, but he also points out the need to differentiate us from Ubuntu. This sounds contrary. He also asks how we are relevant but does not give an answer [2]: | after the releases (both Ubuntu’s and Debian’s), users will get to | choose between two very similar distributions. We need to think about | how Debian will differenciate itself from Ubuntu: what should we | emphasize? How are we relevant? I hope he does not want to imply that we should let Ubuntu release for us anytime in the future. Some pros and cons of such a step have already been discussed in our wiki years ago [3]. Carsten * Or freeze again in December 2012 if one and a half year is not enough time between two Ubuntu LTS releases. [1] http://derstandard.at/fs/1246541995003/Interview-Shuttleworth-about-GNOME-30---Whats-good-whats-missing-what-needs-work [2] http://www.lucas-nussbaum.net/blog/?p=375 [3] http://wiki.debian.org/LetUbuntuReleaseForUs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian Project sponsoring
Hi, On Tue, Apr 28, 2009 at 12:14:48PM +0200, Kevin Schmitt wrote: Does the Debian Project sponsor other projects for a return? no, Debian is not interested in such things, sorry. Regards Carsten -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: How to be authorized distributor
On Fri, Mar 13, 2009 at 09:06:11PM -0300, Vonlist wrote: I written to them so that I want to know that I need to be an authorized distributor of Debian. My project is to facilitate the operative system to those who cannot download it from Internet and to need those who it with urgency. Actually everyone is allowed to distribute Debian CDs or DVDs. Information how to get listed on http://www.debian.org/CD/vendors/ can be found at: http://www.debian.org/CD/vendors/info.html I do not try to win with this, is more, I am faithful follower of GNU philosophy and is why it would by all means donate part of the money to foundation GNU and Debian. Information how to donate money to Debian can be found at: http://www.debian.org/donations.html and http://www.spi-inc.org/donations Waiting for an answer that can clarify my doubts I hope it did. Regards Carsten -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian website redesign proposal
Hi Nathan! I would like to offer a redesign of Debian's website. I will use WordPress to power the new site. Thanks for the offer! I discussed your proposal with some Debian developers. We came to the conclusion, that Wordpress is not the right tool for this task. This has many reasons, one is, that Wordpress had some security related bugs in the past and that www.debian.org is too critical to be exposed to these potential security holes. Also www.debian.org is a high traffic website with limited hardware resources and through dynamically generating static content the whole situation gets even worse, especially when one uses a language that is not known to be very fast. Another reason is, that Debian developers want to manage www.debian.org in a version control system like git or subversion and without the need to use a webbrowser (some of those sick guys and girls even prefer using decade old tools like vi and a shell). I appreciate the open source community and I thought that this would be a good way to give back. http://www.us.debian.org/intro/help is a good starting point if you want to contribute to Debian. Depending on your knowledge the translation project or writing documentation may be a good way to begin contributing. Maybe even helping other users or packaging software if you a really experienced in Debian. Your help would be much appreciated. Thanks, Carsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
