A localisation success: French po-debconf translations briefly reached a full "virtual" 100%
During a whole day, between dinstall runs of Sunday Oct. 24th and Monday Oct. 25th, all Debian packages which use debconf with gettext support (often referred as "po-debconf") for their configuration step had either a complete French translation or a complete translation waiting in the Bug Tracking System. So, as a consequence, if all the relevant bug reports would have been magically fixed...the French team would have reached the nice 100% translation ratio for po-debconf translations: http://www.debian.org/intl/l10n/po-debconf/fr The "real" translation ratio was at that time 95,2% which is the highest number reached by the team since the last "switch to po-debconf" campaign by Martin Quinson. The difference is made of complete translations waiting (for some, I should maybe rather write "sleeping") bug reports. In the same time, several translation teams continue working hard for raising their translation ratio and remove the amount of English seen by their users...and the installer now officially supports 40 languages. The same teams and individuals also work hard for improving the translation ratio of manual pages, native Debian packages (the next dpkg will have 19 complete translations of its 1002 strings!), and Debian web site. All translation statistics and many more i18n information may be found at the following URL: http://www.debian.org/intl/l10n/ Internationalisation and localisation are a key point for targeting a wider audience than the current audience for free software. Debian considerably improved its i18n/l10n infrastructure and compliance in the recent years. Days of flames between maintainers and translators are far away now and I'd like to take this opportunity for publicly thank all package maintainers, translation teams and individuals for their work regarding that matter. PS: This "perfect" state lasted only for one day as 3 new packages using po-debconf were uploaded. :-) Again, please make your best for requesting translation updates on debian-i18n@lists.debian.org when introducing new templates to your packages or when you change some other internationalised material. --
Re: A localisation success: French po-debconf translations briefly reached a full "virtual" 100%
> > Again, please make your best for requesting translation updates on > > debian-i18n@lists.debian.org when introducing new templates to your > > packages or when you change some other internationalised material. > > Yo! > > Jujst wondering: hor much of this is automated, and how much do I need to do > manually as package maintainer? The answer is easy : nothing..:-) > Obviously, translation of the package itself will always be a manual task. > But does anything warn me (linda/lintian?) when I update debconf templates > and/or package descriptions and forget to post to debian-i18n? (which would > be: it should always warn, unless you build the AI to detect when I have > posted to the mailing list :-) But how will this magic too detect that you indeed modified something in your templates? I'm afraid this still pertains to the maintainer non artificial intelligence..:-)
mozilla-*-locale-* packages?
>From a thread in -devel, dated September, after an ITP for Swedish locale files for Mozilla stuff... Quoting Alexander Sack ([EMAIL PROTECTED]): > Javier Fernández-Sanguino Peña wrote: > > >I agree too. Actually, it makes more sense if we do a single package and > >integrate there mechanisms to extract the needed files from xpis to > >generate mozilla-locale-* packages instead of having each maintainer > >devise its own (as well as redoing the registration of the packages in > >mozilla as documented at [1]) > > > >Moreover, somebody (a packaging group) could just package the locale > >definitions available for Mozilla [2], Firefox [3] and Thunderbird [3], > >update them from time to time and update them whenever a new release is > >produced. That would avoid all the bugs related to -locale-YYY > >packages not allowing transitions of new Mozilla|Firefox|Thunderbird > >versions because they have not been updated and having the binary package > >proceed into testing would break them. > > > >I believe that's actually how Mozilla is integrated in other OS, for > >example, in Solaris IIRC. > > > > > I think, that this would not be too hard to implement. On the other > hand, there would still be problems that some translations might not be > ready if mozilla* packages become ready to go in. IMHO, doing so looks like > a trick to declare translations not to be release critical and in fact > inferior to normal packages. Has there been any progress on that topic ? The Arabeyes team (Arabic translators) want to get their ar translations in Debian and they asked me for help. Of course, I can post ITPs for mozilla-*-locale-ar packages and handle such packages myself (by using another one as a model, that woulkdn't be too hard), but it would be better integrating this in a more general project.
Debconf Templates Style Guide now part 6.5.2 of Developers Reference
The document formerly known as the "Debconf Templates Style Guide", or DTSG, which I already publicised from time to time, is now part of the Developer's Reference in the Best Packaging Practice section. This document I wrote several months ago, has been rewiewed by Joey Hess and Denis Barbier and I already received several suggestions from many users or package maintainers. It is aimed at giving advices about debconf templates writing with the following two goals: -more consistency among Debian packages in the way they interact with users and administrators -better prepare localisation of that part of Debian -improve the use of the English language in that part of Debian (that is, get better English than the one I've put in DTSG itself, for instance) http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html Section currently numbered as 6.5.2 (please do not put links with the section number as this is likely to change in future versions of the Developers Reference document) Suggestions may be sent as bug reports against the developers-reference pseudo package Matt, I think you can now remove the direct link you put in the developer's corner to my version of DTSG. I'll replace the file in ~bubulle/dtsg an point readers back to the developer's reference document. --
Re: mozilla-firefox-locale package with all language translations
Quoting Cesar Martinez Izquierdo ([EMAIL PROTECTED]): > I've just uploaded a new version (1.0-3) that generates separate binary > packages for each language. This is great news. Thus you mean that in the future, as soon as a language is added upstream, we will get a new Debian binary package for Firefox localization? If so, this is a major improvement I have to mention to the Arabeyes team who were concerned by getting an Arabic localisation for Firefox in Debian. I now just need telling them that it may automagically appear as soon as they get their ar localisation upstream. I think this could be a good addition to tasksel language taskshowever, this would need firefox to be added to the desktop task in tasksel...post-sarge, definitely.. As a man daily working as "desktop architecture designer", I would say that Firefox is about to become the obvious browser choice for a Linux-based workstation (it as been chosen by the french Ministry of Equipment Roads and Transportation as default browser for their 13000 Linux based workstations). So installing it by default in our "desktop" task would be an important enhancement. > > The remaining issues are: > - some of the binary packages will need specific "Conflicts:", "Provides:" or > "Replaces:" lines that the script can't figure out automatically. > Solution: We can add them by hand. > > - the description of the package should contain the name of the language it > provides, not only the name of the locale (eg: es-AR). Any ideas? > (I guess I will need a list of locales+language names; /etc/locale.alias > seems > to be good but not complete). I have seen these different es localisation packages and was a bit puzzled by them. I have understood that Spanish and more specifically technical Spanish is spoken differently on both sides of the Atlantic Ocean but I really think that two separate packages/localisations is really a waste of time. Moreover, a es_AR package will handle Spanish/Argentina well, but what about other South American spanish-speaking countries ? I suppose that this is also an upstream problem : if upstream ships different Spanish localisation packages, of course we in Debian have no choice but shipping them, but imho, this is not a really good idea. Anyway, if what I suggest above is added to tasksel, we will anyway install the "es" package for all "es" localesOr we will need to change tasksel so that it has a concept of locale tasks rather than language tasks. The addtionnal work and maintenance complication is maybe not worth it just because people do not agree whether one should say "computador" or "ordenador" or whatever else.. Bringing back my Arabic localization example : the ar localization guys never ever imagined creating special ar_* packages for the different flavours of Arabic and you all know that spoken Arabic is way different in the various Arabic-speaking countries. Far more different than Castillan and Argentinan Spanish are. /me crosses fingers for never seeing fr_CA (tabarnak) or fr_BE (une fois) or fr_FR(mon Dieu) packages.
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
Quoting Fernanda Giroleti Weiden ([EMAIL PROTECTED]): > Hi all, > I read all the thread and I noted you are forgeting a main problem about > this package. In my point of view: > > First of all, it's a sexist package, sure. Putting a program on Debian > in which you have pictures of nude women is VERY agressive to the most > women. Yes, it's agressive to me. As already written in -women, this is the point which saddens me the most in this thread. I'm really disappointed by seeing most contributors just not realize why this package, as proposed, is likely to hurt the feelings of several women (probably not all, I don't know) as well as, indirectly or not, some men. I have indeed no intention for objection this package in any matter. I'd just hope that the maintainer proposing it realizes that, though he personnally doesn't think so, his work may hurt some people. Legal nitpicking is another issue, which I personnally do not consider the most important one, indeed. The package is currently sexist, in my opinion. I just hope that saying this loud enough will make the maintainers change their mind. If it does not, well the result will be another sexist thing in free software. I someday wish I had an opportunity to talk of this with Bruno Bellamy, by the way (the artist whose drawings are used in this package). His artwork (and good work) is widely used in the free software community in France and (personal opinion, still) may sometime ring this bell of sexism.
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
Quoting Manoj Srivastava ([EMAIL PROTECTED]): > Packages can hurt feelings, yes. vi hurts mine. The bible > hurts other peoples. purity-off also hurt a lot of peoples > feelings. Can't please everyone. There are over 15k packages in > debian. Some of them surely hurt the sensibilities of a lot of > people. > > Get over it. I have had to. Sure. I won't even have to go over it. This does not prevent me saying what I personnally think is not a good idea. And sometimes imagine that doing so may change some people's way of seeing things...a small brick in a giant wall, maybe.
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
Quoting Joerg Wendland ([EMAIL PROTECTED]): > Go, install bible-kjv. Read it until you find the first offensive > passage that hurts the feelings of several women. Won't take you long... If this is meant at proving me that the bible is sexist, you do not need to convince anyone...at least not myself. This is probably not the reason for which I indeed didn't install bible-kjvthe main reason is that I usually read book made of paper and, anyway, I already read that book. Should I prevent myself of telling that a thing is sexist because something else is also sexist? The vast majority of the world is still sexist, should this be an excuse? Again, such a package will not make Debian a sexist organisation. It is mostly a friendly community (even this thread...:-)) and has for sure far less defaults than many other communities...:). But it won't help making it a *less* sexist community.
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
Quoting Allan Sandfeld Jensen ([EMAIL PROTECTED]): > LOL, the package is no more sexist than it is racist for only showing a > person Well, I gave you my opinion. You're free of not agreeing with it. Playing the Monty Python argument course won't help us, though. ITP's are, in my interpretation, meant for people wanting to package something to have some input about the opportunity of doing so. This thread will probably give the maintainer some ideas about improvements...or maybe convince him to drop the package...or maybe convince him more to upload it. I have indeed no idea and I'm not in position to decide for him. I'm however allowed to give him my feelings and my interpretation of the feelings of other people.
Re: debconf temlate encoding
(CC'ing -i18n) > > Are we moving to UTF-8 for sarge? > > > AFAIK most parts (especially deconf) are UTF-8 ready, so lets do this > also for debconf templates. Yes. > > > Is there any guideline for which encoding to use for po files for > > debconf. > > > I have read on a Debian web-site (or posting?) about using UTF-8 on every > new (or updated) template, but sorry, I have no URL or "official statement" > for you. > Generally it's a good idea to do i18n with UTF-8. Do not make confusion between templates and the PO files which generate them. There is no requirement at all for PO files to be UTF-8. It's up to each translation team to decide the encoding they think is most suited for their needs. There is *no* requirement for all PO files in a given package to use the same encoding. Indeed, using UTF-8 everywhere may make the life of translation team more complicate as this nearly forces all team member to use a UTF-8 environment. More generally speaking, the package maintainers should *not* mess up with PO files encoding unless they deeply know what they're doing.
Re: Is Debian a common carrier? Was: package rejection
Quoting Ron Johnson ([EMAIL PROTECTED]): > very strict regarding anything regarding Nazism. s/Nazism/Crimes against Mankind (or whatever it should be properly called in English...original version is "apologie de crimes contre l'humanité")
A few Debian packages use "cz" for lang code name for Czech
Hello, I just discovered that 4 Debian packages incorrectly use "cz" for the language code for Czech: http://www.debian.org/intl/l10n/po-debconf/cz (of course, the correct code is "cs") I reported a bug against each of those, but wanted to let you be aware of that. I think you need to check what package maintainers are doing as, unfortunately, some people are wrong about the correct code for your language. --
Some advices about debconf i18n (was: Re: Help needed with debconf)
A bit out of topic and not helpful for your main problem, but please find a little advice about the templates themselves... First of all, please make them translatable. man po-debconf will give you the needed information, but it's basically a matter of prepending Choices and Description with "_" Install the po-debconf package and then run "debconf-gettextize". This will create the needed files in debian/po as well as slightly modify your templates file. Then, before uploading your package, please give translators a chance to get the translations in by posting a request for translations in debian-i18n@lists.debian.org with the debian/po/templates.pot file attached. Then, just leave translators and translation teams a few days (about one week) for working on it (some teams have a quality process which involves reviewing the translations and takes some time). You will probably receive some PO files such as fr.po (that one you will receive..:-))), nl.po, ja.po and so on Just put them in debian/po and let dh_installdebconf do the job of building the translated templates. > Template: ttf-arphic-uming/variant > Type: select > Choices: Unicode, MBE, both _Choices: Unicode, MBE, Both (the capital letter will give a better consistency to the presentation) > Default: Unicode No initial "_" here as this is not translatable. debconf-gettextize will add one : just remove it. > Description: Which font variant do you want to install? The Debconf Templates Style Guide, which is now part of the developers reference suggest avoiding questions for select and string templates: _Description: Font variant to install: (note the colon.) Following this would give Debian debconf templates more general consistency. > This font contains bopomofo extended glyphs, which are used to > annotate chinese glyphs to show how the characters should be > pronounced. These bopomofo extended glyphs are used for some > minority languages, like Taiwanese and Hakka. They are mainly ^ Remove the trailing space here otherwise the template will have two spaces > used in Taiwan. > . > There are two variants of these bopomofo > extended glyphs in use, one which conformes to the Unicode standard, > and one, called Modern Bopomofo Extensions (MBE), which aims to be > easier to read and write. > . > The Unicode variant also contains the MBE variants encoded as TTF > stylistic alternatives (SALT). As only few programs can support > this feature, users who prefer to use the MBE glyphs should install > the MBE variant instead of the Unicode one. > . > If you don't know what I'm talking about or don't intend to use > those glyphs at all, choose Unicode. Do no use first person in templates. As this is discouraged in init scripts, this is discouraged as well in debconf templates. I would rephrase the last sentence to something like 'If in doubt, please select "Unicode".' --
Re: Problems to upload
Quoting Andreas Tille ([EMAIL PROTECTED]):
> But what me *really* concerns is why dput and dupload failed in the
> first place. Especially the hint to "PASSIV MODE" smells like something
> has changed to the situation before. I do not know something about
> passive mode but I'm afraid somebody has changed something at our firewall
> which resulted in problems with FTP protocol.
THis is highly likely to be this problem. 0-sized files are usually
the result of uploads failing because only passive FTP transfers work
in some situations.
This is why I indeed use Tollef's delayed queue in any situations
including those I want to do an immediate upload (I just use the 0-day
queue)...
In case you're not aware of it, here's the dupload.conf entry:
$delay = ($ENV{DELAY});
$cfg{'delayed'} = {
fqdn => "gluck.debian.org",
login => "bubulle",
incoming => "~tfheen/DELAYED/$delay-day/",
dinstall_runs => 1,
method => "scpb"
};
Re: Happy new year 2003
Quoting Jean-Luc Picard ([EMAIL PROTECTED]): > yes, debian is still 2 years late to any other distro. Flame answer sent in private mail, in French, which makes me easier to share my feelings about the consideration the above mail shows towards a volunteer work.
Re: New stable version after Sarge
> A 6-month period honestly doesn't allow us much time for new development > anyway. If all we wanted was a point release of sarge, that'd be fine; but > I think most people would like to see etch be an improvement over sarge in > more respects than just hardware driver count, and we have to be realistic > that this means a period of heavy changes followed by a period to stabilize > everything again. I mostly agree with this analysis. We could however give us a better chance to reach this goal by putting a delay for the end of the "heavy changes" period, immediately, instead of just open the gates again and wait until someone feels it is time to think about the release..:-) So, if we imagine we release sarge at February 1st (ahah), just immediately announce that etch will enter the first freeze stages (base packages frozen, testing-security checked, d-i frozen) on August 1st. This will give all developers a good idea of the way they can organise their work. So, even if respecting this schedule may be difficult, we would probably give us better chances...
Bug#289416: general: Typo's in dutch messages for dpkg and cat(libc?)
reassign 289416 coreutils tags 289416 l10n thanks Quoting Rene van Valkenburg ([EMAIL PROTECTED]): > Package: general > Severity: minor > > > Running: su -c "apt-get --purge remove hello" > Pakketlijsten worden ingelezen... Klaar > Boom van vereisten wordt opgebouwd... Klaar > De volgende pakketten zullen VERWIJDERD worden: > hello* > 0 pakketten opgewaardeerd, 0 nieuwe paketten geïnstalleerd, 1 > verwijderen en 0 niet opgewaardeerd. > Er moeten 0B aan archieven opgehaald worden. > Na het uitpakken zal er 483kB schijfruimte vrijkomen. > Wilt u doorgaan? [J/n] > (Database inlezen ... 92866 bestanden en mappen geïnstalleerd.) > hello wordt verwijderdt... The fix for this is pending for dpkg... I remember the translator mentioning this is a very common error in Dutch. > > > 'wordt verwijderdt' should be 'wordt verwijderd'. > > $ for n in $(seq 0 9); do ln -s $n $(( n + 1 )); done > $ cat 6 > cat: 6: Te veel niveaus van symbolische verwijzingen > > Should be: 'Teveel niveaus...' I can't check this immediately but probably some people in the -10n-dutch team will and, if needed, will fix the bug by sending a new translation file to the coreutils package maintainer (cat belongs to coreutils and the translation error is obviously in cat). Then, the package maintainer will forward this upstream as the error is certainly in upstream's translation. I suggest you don't report such bugs as "general" but try to find the relevant package and report the translation bug against it. If you need help for this you should get in touch with the debian-l10n-dutch mailing list.Even better, you can integrate the team and bring all these nice people very valuable help:-)
Re: non-ftp way to upload packages
Quoting Andreas Barth ([EMAIL PROTECTED]): > > Yes, scp to gluck (or other debian machine) and use dupload/dput from > > there. > > Or just upload into glucks delayed queue into day 0. Which is the method I personnaly use since the Nov. 2003 compromise... IMHO, by far the easiest and simplest to use. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Who could be able to help SW vendors to support Debian?
During the Solutions Linux expo in Paris, the DD's present at the Debian booth have been approached by a representative from Trend Micro Corp. who develops and sells security software (the most well known being probably a virus scanning software and such similar software suites). We ended with a very interesting and long discussion with their Product Manager for Client/Server messaging products about the proper way for them to support Debian. It seems that such support is a growing request from their customers (some of them being important Ministries in France and probably others worldwide) who use big farms of Debian-based servers. As far as I have understood, supporting Debian for this vendor is a real concern, but they fail to be sure in who to get in touch with for technical issues regarding the compatibility of their products and our distribution in general (which includes direct interaction with the Linux kernel, as far as I have understood from him). Their concernes was also deciding about *which* release of Debian they should support. Though question as one may imagine because just answering "thou shalt use stable" is obviously not enough. From discussions I previously had with other visitors at the booth, he concluded by himself that focusing their developers on sarge would probably be a better investment than trying to support woody (this is still a matter of months of development, so hopefully sarge will have been released then). Would any people around have pointers which could be given to such people ? Do we already have an entry point for such technical issues as proprietary SW vendors needing technical information about the way to support Debian ? -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who could be able to help SW vendors to support Debian?
> > Would any people around have pointers which could be given to such > > people ? Do we already have an entry point for such technical issues > > as proprietary SW vendors needing technical information about the way > > to support Debian ? > > It isn't clear to me what sort of compatibility issues you would be > talking about. Is this an x86 thing? Or a release thing? > > I've been under the impression that the only machine-level > incompatibilities are really kernel and driver issues and not issues > with Debian per se. Well, I'm not the software vendor here..:-) As far as I've inderstood, this product induces some interaction at kernel-level and the vendor developers may have concerns about the kernel on the distribution they want to support their product on. They probably also have concerns about the library compatibility and such stuff. Again, I can't really speak for them, but I'd like to point them the right direction. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who could be able to help SW vendors to support Debian?
> I don't like to pass the buck, yet I can't see a way that Debian, as > it is can support them directly. Perhaps they ought to look to the I think they don't need support from Debian. They just need to know where to discuss the issues they are concerned with. In understand this is not really a very well formulated request. I indeed needed a few hints to give them as first start. Then I suppose these people are grown up enough for handling this alone..:-) I'll probably point them to the kernel maintenance list as several issues seem related to the kernel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Babelbox documentation is available
(reply to -devel unless answering on a topic more appropriate to one of the other lists) Several people have heard of my "Babelbox" demo machine which was featured for the first time at Solutions Linux expo in Paris. This demo machine is a Debian Installer demo which runs over and over, changing the installation language at each run. This is a quite nice demo of the installer automation capabilities and a good eyecatcher for a Debian booth. At Solutions Linux, the demo ran 54 successive installs (being limited by power outage during nights), but I already ran up to 300 successive installs while testing it. The demo installs a complete desktop system with the default "desktop" task from tasksel (the one with Gnome AND KDE), then opens a Gnome session which include a "welcome" sound in the current language. Most of these sounds have been contributed by Debian-women contributors as well as D-I translators. Some people have requested me to make the demo material available so that they can build their own Babelbox demo and possibly make it better. So, I have put on http://people.debian.org/~bubulle/babelbox.tar.bz2 the whole material needed for Babelbox (including sounds...which make the file quite big) as well as the needed documentation. I hope you'll enjoy it and certainly will make it even better. I'd like to publicly thank here my employer, the French Aeronautics and Space Reseach Center, as well as François Mescam, my boss, for allowing me so build and test this demo on our equipments as well as invest some on my work time on automated Debian installs in the demo setup. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Verify debianhttp://www.perrier.eu.org/debian/voices/-devel@lists.debian.org for Francois.Mescam@onera.fr
> Why do people think it's acceptable for their stupid anti-spam measures > to inconvenience others? I am indirectly responsible for M. Mescam message. He was BCC'ed to my original mail annoucing Babelbox documentation (I had my own reasons for the BCC). However, as I did setup the Reply-To field to the mailing list AND as he never received mails from my Debian address first, his automated greylisting system automatically answered and did so using the Reply-To field. So, finally, the request which was supposed to go to me finally went to the list..:-) I was aware of his greylisting system and I should have imagined this when sending my mail. Apologies to list subscribers for that. About the "stupid" antispam system, I guess he knows this is not a perfect system, but please imagine the amount of unsollicited mail (not really spam...mostly "targeted" emails) received by a big organisation IT director on a email address he wants to keep very clean. I'll try help him improving this system for avoiding cases like this one, probably by making it NOT respect Reply-To fields at first. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Verify debianhttp://www.perrier.eu.org/debian/voices/-devel@lists.debian.org for Francois.Mescam@onera.fr
Quoting Tollef Fog Heen ([EMAIL PROTECTED]): > This isn't greylisting -- greylisting doesn't ask for verification, it > just temporarily refuses to accept the mail. Oversimplification on my side. The point was not nitpicking the system but give a general explanation... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Verify debianhttp://www.perrier.eu.org/debian/voices/-devel@lists.debian.org for Francois.Mescam@onera.fr
> Then it is broken. Automatic mails should be sent to the envelope > sender, unless explicitly asked otherwise. Yes, it was (broken)...:-) And, now it is not broken anymore. People learn by mistakes..:) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
(forw) Packages not using po-debconf - more active actions to come
This was intended for being crossposted to -devel and -i18n but I finally forgot to add -devel. Please followup to -i18n if you don't mind. - Forwarded message from Christian Perrier <[EMAIL PROTECTED]> - Date: Mon, 14 Feb 2005 18:54:42 +0100 From: Christian Perrier <[EMAIL PROTECTED]> To: debian-i18n@lists.debian.org Subject: Packages not using po-debconf - more active actions to come X-Mailing-List: archive/latest/3487 Bringin the power of gettext to debconf (namely "po-debconf") has been by far one of the major improvements in Debian's i18n infrastructure over last years (it appeared a few weeks after woody's release and entered unstable on Oct 1st 2002). Nearly all, if not all, translators agree that maintaining translations for packages which do NOT use po-debconf is a real pain and nearly impossible. This is why a huge effort was put to have packages which use debconf switch their templates files to the "new" po-debconf style, which allows translators to handle their work with the familiar GNU gettext tools. We are now left with 102 packages which do not use po-debconf. Most often these packages have no translation for their templates, or translations which are highly outdated, making them useless. Most often they are not very actively maintained, or even orphaned. Sometimes, their maintainers simply do not care. Martin Quinson, Michel Grentzinger, myself, André Luis Lopes and a few other translators have reported bugs against these packages, suggesting they switch to the "new" system, most often providing them with a patch. This is now time for action...:-). Similarly to what was done with longstanding pending translations, I will start a "NMU campaign" targeting these packages. This campaign will be made with the same care for respecting maintainers work and gently interact with them (this has proven efficient for old pending translations). We will of course use this opportunity for adding some translations to these packages..:-) Of course, help on that matter is very welcomed (Luk, Martin, others...). Please find below the alphabetical list of the relevant packages (main, then contrib, then non-free). I have not yet looked over the BTS for giving the bug numbers for "Please switch to po-debconf" bug reports. This is still work to do. The real work will probably not start before early or mid-March...and, of course, not interfering with the release process will be in the priorities. Package list: am-utils anthy asterisk-chan-misdn blootbot boa bottlerocket chdrv cricket cxref ddclient ddt debian-edu-config delo diald dict-gcide diffmon discover dvipdfmx efingerd ez-ipupdate fcron filterproxy freenet6 freetds ftape ftape-tools ftpwatch fvwm-shell gcl gclcvs gdm gidentd haskell-mode hearse hunglish hybserv ifplugd ispell-fi jove joystick kerberos-configs laptop-netconf libapache-sessionx-perl libdbd-sqlite-perl libmail-bulkmail-perl libroxen-imho libsafe lids-2.4 links-ssl localeconf lowmem lsh lukemftpd mailgraph mason masqmail mdctl miscfiles mlmmj mod-mono moobot moviemate mped nagat ndtpd netkit-base nn ntop php4-pecl-ps php4-ps prelude-nids printbill python-popy radioclk razzle schoolbell suck tripwire usb-discover waproamd webcalendar x-symbol xsp zephyr zope-docfindereverywhere zope-loginmanager zope-zshell Contrib packages: acl-installer ccc cfal cfalrtl cpml cxml cxx daemontools-installer libots lw-per-installer lw-pro-installer lw-pro-installer-43 quake2-data Non-free packages: nttcp qmail -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] - End forwarded message - -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for Help: apt 0.6
Quoting Martin Schulze ([EMAIL PROTECTED]): > Moin, > > We need help by competent developers who work on apt 0.6 with the goal > to get it supported properly and eventually enter sid and sarge. > > There is a good chance the release will happen before the issues with > apt 0.6 are resolved, so this may be a task that cannot address sarge > in time but only etch and following distributions. Contributors > should be aware of this. The effort on getting it as translated as 0.5 is (27 complete languages) is on its way, so PLEASE do not change messages which are outputted to users without saying so in the APT development list. I also have a patch for bringing some consistency in the way APT uses capitalization in its output. It Seems That Too Many German Developers Wären Involved In It...:-) (kidding you, people, no offense intended to people who indeed made great job). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: (forw) Packages not using po-debconf - more active actions to come
Quoting Tollef Fog Heen ([EMAIL PROTECTED]): > * Christian Perrier > > | Please find below the alphabetical list of the relevant packages > | (main, then contrib, then non-free). > > .. as usual, please include maintainer names with package lists like > this. (And thanks for assembling the list. :) Lucas Wall is setting up a status page for this po-debconf transition work. I've just suggested him to add the package maintainer's name. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MTA in base system installation
Quoting Don Armstrong ([EMAIL PROTECTED]): > On Thu, 17 Feb 2005, Philipp Hug wrote: > > Is it really necessary to have a full blown MTA in the base installation? > > What the hell is a "base installation"? ...what you get when installing from scratch and choose no task in tasksel. You then end up with exim4 installed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
> And yes, it does belong there. It could easily add the something like: Sure. Changing an important screen with 36 complete translations just now is an easy thing to do. People who argue for this "easy change" are just volunteering to handle translation updates and bring them back to the state they are now if this thread happens to force Marc and Andreas to change the template. It is here since months if not years and now someone wakes up and request for changes. Are we really trying to release a distribution? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
> I don't know how these translation things are handled technically. But > since the intended meaning didn't change at all, I don't see why it is > better to have a "bad" english version and 40 equally "bad" translated > versions, over having a better english version, 10 better translated > versions, and 30 working translated versions with formally one > fuzzyness? One fuzzyness means the whole screen is shown in English. So the choice is between a supposedly "perfect" English screen shown to all users, no matter which language they prefer to use.and 40 quite good screens which users may read in their own language. The choice is also between translators happy to have achieved a full process and have a complete translation in their languageand angry teams because the templates have been broken again. Purely psychological issue, surebut that counts more than you may imagine. And, besides all this, a huge time wasting ot i18n coordinators trying to get updates in by warning translators, then warn them again...then make a status report to the package maintainersusually two weeks delay if we want to have the same translation ratio we had before the change decision. I handled the last change with exim4 maintainers and, believe me, that had a cost in matter of time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
Quoting Frank Küster ([EMAIL PROTECTED]): > No, it's not a good idea. Let's keep the change in mind for etch. That, I fully agree with...:) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
The installer is not a release blocker...but interest in the installer is decreasing
(from a thread in -devel) Quoting Henrique de Moraes Holschuh ([EMAIL PROTECTED]): > On Sun, 20 Feb 2005, Brian Nelson wrote: > > > There isn't any evidence I've seen that these arch's actually slow > > > down the release. > > > > Getting debian-installer working across all architectures was certainly > > an issue at one time, though that time passed a few months ago. > > Well, if the installer ever holds etch, we can think about it. Right now, > the installer is not even semi-close to being the worst problem. Sure. The only problem with the installer is that we froze in early October for RC2, didn't move that much since then (no new featuresthe few ones added are waiting in the trunk branch)and it seems that the interest in it is decreasing among developers with a "core team" slowly shrinking to a few individuals. Not a problem per se, but only a small worry at this moment. We shouldn't have a frozen installer for a too long timeor we take the risk of losing valuable contributors interest. More specifically, I'm thinking about the work on a graphical interface, a rescue package, partman enhancements, new languages support -several are waiting since September because we decided then to not add more languages We also have an increasing number of unprocessed install reports (of half-processed) : a usual good sign of lack of resources. Don't misunderstand me : I agree completely with the current installer "semi-freeze". Joey handles this the best way, for sure (I am and I have always been 100% supportive fo the way D-I development is handled) I just want to enhance the concerns I had during last weeks/months. The installer team needs to move on. For this, we need to first release RC3 (which is on its way), then be sure that that release is enough for a sarge release (here, the blocker is obviously the final choice about the kernel). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: announcing first release of common database infrastructure package
> anyway, i've uploaded my first "public" release of dbconfig-common > to experimental. minus a couple bells and whistles (and probably > plus a bunch of undiscovered bugs), it's pretty much feature complete for > what's mentioned on my webpage[3], so at this point i'd like to call for > some brave volunteers. You might want to post a call for translations for the common templates in the package, as I understand this package includes a set of common templates. This can be made by just posting to debian-i18n with a pointer to the templates.pot file. You just need to give a bit of context so that potential translators know what this is all about (having a common set of templates for DB-related packages in order to avoid them translating the same thing over and over). I promise you'll soon get tons of translations in various languages and I'll personnally give some push so that translators know this is a really important thing to translate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
> Any reason not to post it on-list? I was hoping to improve the > security/usability of my own setup based on the best practices offered up in > reply to this thread. Yep. Seconded. This is exactly what I was thinking while seeing this thread : let's watch it and learn how my fellow DD and Debian contributors handle this and improve the (certainly very bad) way I have to handle this myself. A few months ago, I got my hands on a few USB encryption keys (or whatever these things are callediKey stuff for instance) and imagined I could store sensitive data there. I look vaguely at things which are supposed to handle these in Linux (PC/SC stuff and such things)...but, well, this was quite obscure and I finally gave up. But I still have a few of these keys...:-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: announcing first release of common database infrastructure package
Quoting sean finney ([EMAIL PROTECTED]): > okay, i'll do that some time in the near future. i'd like to give a > final look over my templates to make sure that i like my own english > before i ask anyone to translate it though :) Well, be sure that we will be critic towards your English too...even if mine isanything but perfect (by far). More specifically, having the templates compliant with the Debconf Templates Style Guide (cf devel reference) is a must have, of course -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: announcing first release of common database infrastructure package
Quoting sean finney ([EMAIL PROTECTED]):
> to reply to my own post...
>
> i was under the impression that because dbconfig-common was previously
> in experimental that i wouldn't have problems related to the stalled
> NEW queue, but i was wrong.
>
> so you can get them here:
>
> deb http://people.debian.org/~seanius/policy/examples/ ./
> deb-src http://people.debian.org/~seanius/policy/examples/ ./
>
> you want version 1.4.
Well, IN finally had a look at the debconf templates...
Comments about the templates:
--
If no longer have need of the data being stored by ${pkg}, you
should answer "yes". If you want to hold this data for another
time, or if you would rather handle this process manually,
anwer "no".
--
(typo detected, btw)
You should avoid making reference to specific user actions such as
"answer yes" for boolean templates. Depending on the interface and
interface translation, the user may be presented with something else
than yes/no choices for boolean templates, such as a check box.
The recommended wording in such case is "If you choose this option,
blah blah" or (for "if you answer no") "If you refuse this option,
blah blah".
--
_Description: Passwords do not match!
Sorry, the passwords you supplied do not match. Please try again!
--
I usually recommend avoiding exclamation marks as well: "Passwords do
not match!" should be replaced by "Password mismatch". I also tend to
discourage the use of "Sorry" for more factual wording. In general,
anything suggesting that the computer behaves like a person should be
discouraged (the infamous use of first person which some maintainers
enjoy). Neutral and factual wording is the key point.
A few initial capitals are also missing here and there
Another one:
--
Template: dbconfig-common/mysql/host
Type: select
Choices: ${hosts}
_Description: What host is running the mysql server for ${pkg}?
Please select the remote hostname to use, or select "new host" to
enter a new host.
--
I usually recommend "opened" prompts for "select" and "string"
templates and leave interrogative form to boolean templates.
_Description: Host name of the MySQL database server:
(MySQL should be spelled that way, IIRC)
_Description: What should be the mysql database name for ${pkg}?
becomes:
_Description: MySQL database name for ${pkg}:
Template: dbconfig-common/mysql/app-pass2
Type: password
_Description: Please re-enter the password
Please re-enter the password.
-->The long description here is useless. You can safely remove
itor provide something more explicit. Indeed I would write that
one like this:
Template: dbconfig-common/mysql/app-pass2
Type: password
_Description: Password confirmation:
Last (but not least), a few lines in the templates file end with extra
spaces...these should be removed as they create double spacing inside
sentences.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
The Right Way to turn a native package in a non native package with a NMU
Dear fellow package maintainers, I need you help. I'm currently trying to NMU gnome-find so that this package is no more a Debian native package, which is pointless. A kind of QA work on a package with low activity (and a probably MIA maintainer). So, I grabbed it 1.0.2-1 current version and recompiled it as a non native package, using a gnome-find_1.0.2.orig.tar.gz file I got from the upstream repository. This built fine and I now have the following in my build directory: drwxr-xr-x 8 bubulle bubulle 1024 2005-03-08 11:26 gnome-find-1.0.2 -rw-r--r-- 1 bubulle bubulle 3400 2005-03-08 11:25 gnome-find_1.0.2-1.1.diff.gz -rw-rw-r-- 1 bubulle bubulle659 2005-03-08 12:08 gnome-find_1.0.2-1.1.dsc -rw-r--r-- 1 bubulle bubulle 39627 2005-03-08 11:26 gnome-find_1.0.2-1.1_i386.build -rw-rw-r-- 1 bubulle bubulle 1214 2005-03-08 12:08 gnome-find_1.0.2-1.1_i386.changes -rw-r--r-- 1 bubulle bubulle 161412 2005-03-08 11:26 gnome-find_1.0.2-1.1_i386.deb -rw-r--r-- 1 bubulle bubulle 451517 2005-02-20 11:22 gnome-find_1.0.2.orig.tar.gz The .dsc file contains: .../... Files: fb6549efbab887efea88a8fcc4b4319f 451517 gnome-find_1.0.2.orig.tar.gz 7ea07e4e9226648422fb7a83d066ffe8 3400 gnome-find_1.0.2-1.1.diff.gz And the .changes: .../... Files: 733af0b63b2a63ac5ec3df7e46a9633a 659 utils optional gnome-find_1.0.2-1.1.dsc 7ea07e4e9226648422fb7a83d066ffe8 3400 utils optional gnome-find_1.0.2-1.1.diff.gz afea158735d04857e728d50312e17f7c 161412 utils optional gnome-find_1.0.2-1.1_i386.deb I upload the .orig.tar.gz, diff.gz, .dsc and .changes files to the upload queue, but I keep getting the following message when the package is processed, saying me that gnome-find_1.0.2.orig.tar.gz is not in the queue or in the pool...while I indeed upload it. So, there's obviously something I misunderstand or something I'm doing the Wrong Way. Could someone give me a hint? I somewhat suspect that I should add the mention of the .orig.tar.gz file in the .changes file. Should I add it manually before signing this file? Soprry for my ignorance : it looks like it still have tons of things to learn..:-) - Forwarded message from Debian Installer <[EMAIL PROTECTED]> - From: Debian Installer <[EMAIL PROTECTED]> To: Christian Perrier <[EMAIL PROTECTED]>, Yooseong Yang <[EMAIL PROTECTED]> Subject: gnome-find_1.0.2-1.1_i386.changes REJECTED Date: Tue, 08 Mar 2005 06:47:15 -0500 Rejected: gnome-find_1.0.2-1.1.dsc refers to gnome-find_1.0.2.orig.tar.gz, but I can't find it in the queue or in the pool. === If you don't understand why your files were rejected, or if the override file requires editing, reply to this email. - End forwarded message - -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The Right Way to turn a native package in a non native package with a NMU
> So use -sa. I forgot to ACK this : the suggestion was of course correct. Thanks for the "tip" (which indeed could have been a RTFM.:-)) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#299023: ITP: zope-common -- common settings and scripts for zope installations
Quoting Fabio Tranchitella ([EMAIL PROTECTED]): > Package: wnpp > Severity: wishlist > Owner: Fabio Tranchitella <[EMAIL PROTECTED]> > > * Package name: zope-common > Version : 0.5 > Upstream Author : Matthias Klose <[EMAIL PROTECTED]> > * URL : http://people.ubuntu.com/~doko/zope/ > * License : GPL > Description : common settings and scripts for zope installations > > The package contains common settings and scripts for zope installations. I guess that all translators who suffered on the zillion zope-* packages will bless you for this package..:-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Offer to take over the shadow package (passwd and login binary packages)
Hello folks, The shadow package is officially maintained by Karl Ramm, with assistance by Sam Hartman. It is the source package for "login" and "passwd", two important pieces of Debian base system. I have helped Karl in collecting the package translations (both debconf and programs translations) for more than one year now. Since July 2004, I've got no news from Karl and any further attempt to get in touch with him has been unsuccessful. Even before this, it became quite obvious that the package is not very actively maintained. Karl is listed in the MIA lists and it becomes quite obvious that he is really MIA. I had exchanges with the MIA lists maintainers about this. I have announced in many places my intent to take over the package development, which I'm in fact doing since mid 2004 (with NMUs). As I feel that I don't have the whole required skills for doing so, I have made my best to gather a mini team of contributors. The team is quite small at this momennt but I expect more motivated people to join in. For instance, Tomasz KÅoczko, the upstream maintainer has joined the package development list. Tomasz has given a very strong push to the upstream development and I expect a very good collaboration with him to make shadow utilities better...and the Debian implementation better as well. Sam Hartman also mentioned he may bring some help and is of course very welcomed. All other Debian developers (or contributors) who want to contribute are welcomed to contact me. We will probably specifically need people with well established skills about system security. This is is the official announcement of my intent to take over the package development. I hesitated a lot before doing so as the alternative would have been to keep a NMU version as the last version released with sarge. For more clarity on this topic, I finally decided it would be better to officially act as the package maintainer. I intent to soon upload a version with the [EMAIL PROTECTED] mailing list as "Maintainer:", so that the lists gets the bug reports and all other stuff related to the package development and myself and Sam Hartman as "Uploader:". This will be the 4.0.3-31 release of the package. It will be exactly similar to the current 4.0.3-30.10 release of the package except the maintainer and uploader changes. The plans for the future are: -Before sarge release: -continue to improve the l10n in shadow, if still possible, with no other update, except of course RC issues. This will be the 4.0.3-31sarge series Even the request for making login non setuid is delayed post-sarge after advice received from the release managers. -maybe launch some work in experimental to integrate upstream 4.0.7 (see below) -In Etch (ie after sarge release) -examine all Debian-specific patches to upstream sources one by one and discuss them with upstream. My intent is to minimize them as much as possible and have them integrated upstream if possible For this, the 4.0.3-32 release will use dpatch to isolate all these patches. This is already made in the CVS on Alioth, indeed, thus the devel list members may already begin to review these patches -integrate all this to upstream's 4.0.7 release, looking one by one to Debian specific changes and decide whether: -they're already here in 4.0.7 -they are not and should be dropped -they are not, should be kept and integrated upstream -they are not, should be kept but should be kept as Debian specific The goal here is to have a Debian version which is as close as possible from the upstream version. These last plans may of course be changed, depending on the discussions we will have on the package development list. Please, feel free to comment about all this. Any input is welcomed. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Offer to take over the shadow package (passwd and login binary packages)
> > I have announced in many places my intent to take over the package > > development, which I'm in fact doing since mid 2004 (with NMUs). > > Would you also take over xscreensaver and maybe let me co-maintain it? I'm afraid I have to decline. More packages would be, for me, a bit too much and I have no strong motivation for xscreensaver. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
> Based on the last few hours only, I think you'll have lots of comments > to meditate on :-) Only if considering that a few dozen of people making a lot of noise and thus making the thread absolutely impossible to read for people with a normal life and health, represents the feeling of near 1000 developers... /me, quite happy with the work of the people involved in this announcement and confident in their ability to hear about the received commentsthe hardest part probably being the need to remove useless noise and rants ...but quite sad (or happy?) to see that nearly only the proposal to handle architectures differently got criticism...while this proposal contains several other key point. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Sarge release (Re: Bits (Nybbles?) from the Vancouver release team meeting)
Quoting Steve Langasek ([EMAIL PROTECTED]): > Hello all, > > As promised earlier on -project[0], after the release team/ftpmaster > team meeting-of-minds last weekend, we have some news to share with the > rest of the project. > > First, the news for sarge. As mentioned in the last release team It looks like the giant noise generated by this mail (I sometimes wonder whether some people are in Debian just to make noise and criticize every action as long as it doesn't fit exactly with their point of view.) has hidden the first topic : we nearly have a realease schedule and sarge release is becoming more and more reality. May I ask to people who have jumped on the "architecture handling" topic to please consider also the great work made during this work session about *other* topics and maybe just say something about it also:) Anyway, I take this opportunity to thank the involved people for their time and work as well as their commitment to the project. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release sarge now, or discuss etch issues? (was: Bits (Nybbles?) from the Vancouver release team meeting)
> I do not understand why the Nybbles team mixed their good news about > sarge with their foreseeably controversial plans or proposal for etch. This may have been a strategical error, yes. For me, the Vancouver meeting goal was obviously the sarge release and IMHO, they achieved their goal very well. My interpretation is that doing so, interesting ideas cam to float around and were formalized enough for the "post-sarge" plans to be announced. We should be realistic : this meeting was a good opportunity of getting together what we can call "key people" (no offense intended at all...far from this) and thus a good opportunity for these key people to make proposals. OK, experience shows that they should probably have separated the things about sarge release and the things about post-sarge ideas/plans/whatever, as everyone knows that *any* proposal made in Debian triggers a counterproductive flamew^W endless discussion. I suppose there were reasons for this and I grant the Vancouver meeting people enough respect for having good reasons...even if this ends up in being a strategical error. My personal concern now is avoiding to "throw out the baby with the bath's water" as we say in French. OK, the architecture handling is controversial. Fine...this will probably delay etch more than we would like. But could we please focus on releasing sarge first? By focus, I also mean avoidn wasting valuable DD time to endless discussions (no real human can read this thread already), flamewars and personal attacks (I'm quite saddened by Julien's hard attacks and proposal to do the Revolution). This thread obviously shows that some more real life discussions are needed about post-sarge plans and I don't doubt that involved people will welcome more contributions and start thinking again. This is very likely to be my last contribution to this thread except in sub-threads dealing with sarge release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian makes titles
> Are you happy with that? People talking about Debian ? Sure. "Press" misunderstanding issues, no, but this is not the first time. Sure, we will have (we already have) a nice Internet rumour saying "Debian drops most architectures". But, well, we have rumours about nearly anything alors une de plus ou une de moins...:) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Another load of typos
Quoting Florian Zumbiehl ([EMAIL PROTECTED]): > Hi, > > now that the problems with my last bunch of bug reports on mostly "its" > vs. "it's" mistakes some months ago seem to be solved, I've found another > load of typos of the "a" vs. "an" flavor, about 110 in total. please please please...for anything which can be localized (especially debconf templates) add something about translations in the bug reports. At least pointing the developers to podebconf-report-po for warning translators that their translation needs an update because the original English was changed for instance. All they have to do is installing po-debconf and run this utility from the top of their package's source tree after making the change and run debconf-updatepo. Indeed, typo and spell corrections should not need translation updates and affected translations can certainly be unfuzzied.WHEN ONE KNOWS HOW TO DO THIS CLEANLY...:-) For package descriptions, this is less harmful as indeed there is no real way to handle translations properly (the DDTP does not really implement stuff for that and I'm even not sure it is still working properly). So, I really suggest that you separate things between package descriptions and debconf templates. For the latter, plese get in touch with debian-i18n. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Another load of typos
(what to do when correcting typos in debconf templatesand want to avoid extra work to translators) Quoting Adeodato Simó ([EMAIL PROTECTED]): > * Christian Perrier [Tue, 15 Mar 2005 09:24:57 +0100]: > > > Indeed, typo and spell corrections should not need translation updates > > and affected translations can certainly be unfuzzied.WHEN ONE > > KNOWS HOW TO DO THIS CLEANLY...:-) > > I've never had to to such thing, but I've wondered from time to time. > So, if I do a spell correction in a debconf template, what should I > take care of doing/not doing? (RTFM welcome if accompanied by a point > to the relevant M :). Nothing already written comes to my mind. The following is some of the practice I recommend when discussing with maintainers about such issues. This has to be followed point by point. 0) run debconf-updatepo (to be sure that ALL PO files are up-to-date with regards to your current templates, not yet modified for typos) 1) Put all incomplete PO files out of the way You can check the completeness by using: for i in debian/po/*po ; do msgfmt -o /dev/null --statistics $i ; done move all files which report either fuzzy strings to a temporary place. Files which report no fuzzy strings (only translated and untranslated) will be kept in place 2) NOW AND NOW ONLY, modify the template for the typos AND BE SURE THIS DOES NOT AFFECT THE TRANSLATIONS (typos, spelling errors, sometimes typographical corrections should not affect translations) 3) run debconf-updatepo This will fuzzy all strings you modified in translations. You can see this by running the above again 4) Run: for i in debian/po/*po ; do msgattrib --output-file=$i --clear-fuzzy $i ; done 5) move back files you moved in 1) to debian/po 6) run debconf-updatepo again Doing so, you unfuzzy in 4 all strings fuzzied by the changes in 2+3. Moving incomplete files elsewhere prevents you to clear the fuzzy marker they could have for *legitimate* reasons. Again and again, only do this when you have carefully checked that translations have no reason to be impacted by the change(s) you plan to make. And, do this exactly as I described, in the same order. Messing up with translations is *not* recommended. Doing so with the gettext tools prevents to mess up encodings (emacs can be very good at this as well as several text editors)but you have to be sure of what you're doing, indeed:) There are other ways, more elaborated, to do preventive modification of PO files (for instance by using sed)which allow the "unfuzzyfication" process to be done even on incomplete filesbut this is gory enough for being left to people who *really* are sure of what they do...:-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: post-sarge transitions: slang
> slang should, I hope, be a fairly small change; OTOH, we seem to still have > conflicting slang1 and slang1a-utf8 packages in the archive (conflicting > -dev packages at least), so it would certainly be nice to wrap this up and > only have to carry one version of this core library for etch. > IIRC, a slang transition directly or indirectly affects D-I, am I right? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Another load of typos
> Is this already in the Developer's Reference? If not, I think it should be > added there. Thanks for the info! Sigh, I *knew* someone would say this..:-) Well, I may be unlucky enough for the tutorial about "i18n/l10n handling for maintainers and translators" I proposed at debconf to be accepted. If it is, I *will* have to write something anyway, so I guess that *this* (or an excerpt) could end up in the DR, yes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Another load of typos
Quoting Torsten Landschoff ([EMAIL PROTECTED]): > May I suggest reporting your HOWTO mail as a bug in the developers > reference? That way it is at least recorded somewhere. I'd do it but I > don't want without permission. Feel free to do so...this will probably be a good motivation for me to write down some other stuff. This should probably go somewhere in the DR after the part of the debconf templates style guide. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bangladesh Key-Signing completed - Debian Maintiner base can now be extended there.
Quoting salahuddin pasha ([EMAIL PROTECTED]): > hello all > > i am > salahuddin pasha (also known as salahuddin66) > 19 male > from Bangladesh, Dhaka > > interested both in > --- > 1. Bengali localisation > 2. maintain apps (deb) for Debian. > --- > > one of my dream was join in Debian group (officially) I think you really should join the debian-in-workers mailing list (http://lists.alioth.debian.org/mailman/listinfo/debian-in-workers) Here are gathered most of the people working on Indic languages support in Debian, including of course localization (Localization of Debian Installer in Bengali has started) Unless you already joined, of course..:-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
My IP address seems listed as a spammer address by bugs.debian.org
(this mail was CC'ed to debian-admin but I messed up in the To field) Since yesterday, I'm afraid that my IP address 81.56.227.253 is listed on bugs.debian.org among addresses which get a "Go away" answer when requesting a specific bug report (http://bugs.debian.org/xx) >From discussions I had on IRC with Anthony Towns, this seems to be caused by numerous requests made by my system to the BTS at regular intervals. There's a reason for this: I work on several packages, some of them having numerous bugs (mostly the samba package). I'm doing this work offline most of the time and, for this reason, I need a copy of the bug log for these packages on my laptop. Thus, I used the "bts cache" command in a daily cron job for the package I am the maintainer (samba, shadow, geneweb, a few d-i packages...). After the first discussion I had with Anthony who kindly alerted me on this problem, I drastically reduced the number of cron jobs, some of them becoming weekly. However, I did not remove the cron jobs for samba...and samba has lot of bugs reported It seems that this became enough for my address being listed...and now I can't work anymore on any bug from my home system. I will probably use a workaround by using my ISP proxy server but this just moves the problem elsewhere... Is there something I can do for getting my address unlisted (apart from again reducing the load I put on b.d.o...which I did again down to the lowest acceptable refresh rate on my side)? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian Installer team monthly meeting minutes (20051119 meeting)
(reply-to: debian-boot) The minutes of the November D-I (Debian Installer) team IRC meeting are now available from the Debian Installer Meetings wiki page: http://wiki.debian.org/DebianInstallerMeetings Minutes: http://people.debian.org/~bubulle/d-i/irc-meeting-20051119/minutes Log: http://people.debian.org/~bubulle/d-i/irc-meeting-20051119/log The next D-I meeting will be held on Wednesday December 14th 21:00 UTC on the #debian-boot channel on freenode. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPG keysigning in Bangalore, India, next month
Quoting John Walther ([EMAIL PROTECTED]): > If any Debian developers or prospective developers would like to have > their GPG keys signed, I will probably be in Bangalore next month. > > The keysigning will probably be at the Bangalore LUG meeting, but other > arrangements can be made. Email me. > >http://linux-bangalore.org/blug/meetings/ Something seems to be already running. From the debian-in-workers mailing list, wirtten by "Praveen A <[EMAIL PROTECTED]>" == 2005/11/3, Jaldhar H. Vyas <[EMAIL PROTECTED]>: > > On Wed, 2 Nov 2005, Mahesh T. Pai wrote: > > > > > How about a key signing party at b'lore? > > Add your Keys here http://www.biglumber.com/x/web?keyring=2473 == -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intel notebooks for needy developers in developing countries
> Yeah that would be a real pain to exlude countries because of stupid > political 'correctness'. All in all in Free Software movement we don't know > what the borders are, do we? We (Debian developers and contributors) certainly all agree on this (or, at least, the vast majority of us). However, the donator here is a US company which may be restricted by the laws of the United States of America. Whether we like them or not is not really relevant. If Intel cannot donate a computer to a Cuban citizen, there's not much we can do about it, except by asking the same donation to a company that wouldn't be restricted to these exportation laws (such as a Japanese company, maybe...which I'm not even sure of). This certainly does not prevent Andreas to record the name of a Cuban citizen in his list and propose it to Intel which is what I would recommend doing if a Cuban citizen really qualifies for the donation. But we should wait until we know there is *really* someone qualifying for the donation in Cuba, before turning this into a rhetorical case, no? (removing CC to Andreas who certainly reads this list) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian and the desktop
Quoting Linas Zvirblis ([EMAIL PROTECTED]): > >Yeah, and let's draw from the work by the Ubuntu guys, rather than > >doing it a different way! > > But doesn't Ubuntu use Debian installer? Yes, but they don't use tasksel...which is the one installing a "desktop" task. >From the D-I team point of view: there are certainly tons of things to improve in our default installs, especially when we exit the real domain of D-I and enter the domain of general setup of a default system. Here, let's face it: we have no team working on this in Debian. The result of a default desktop install for Debian is the result of what we get when installing X, then Gnome+KDE and some other stuff. This is something that comes outside the scope of the D-I team, at least as we currently work. We (D-I team) maintain tasksel, yes (mostly Joey) but we don't do that much more. We don't really do choices because we aren't in a position of doing choices (hey, this is why "desktop" installs the whole bloat of KDE *AND* Gnome ). As a result, the default Debian desktop worksbut it lacks a few polishing features which our custom^W users find in other distros Examples? -default sound setup -default wireless setup -design of the default login screen -probably tons of details which, alone, aren't a big deal...but will make the difference at the end. "Are we devoted to our users?", asked Marga at Debconfwe should think about this sometimes...:) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[D-I] [MEETINGS] Next Debian Installer meeting TOMORROW: Wednesday Dec. 14th 21:00 UTC
(crossposted to -devel and -i18n to trigger attention by people who maybe loosely follow debian-boot) This mail is a reminder for the next D-I team monthly meeting which is scheduled for tomorrow Wednesday Dec. 14th 21:00UTC. This IRC meeting will be held on the #debian-boot channel on freenode (aka irc.debian.org). As usual, the Wiki page for meeting topics should be used to propose discussion topics: http://wiki.debian.org/DebianInstallerMeetings I will add a timing table for discussion topics before the meeting. The beta2 release schedule will probably be the main topic. No subtopic is opened yet (I may propose some soon). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian and the desktop
Quoting Joey Hess ([EMAIL PROTECTED]): > Christian Perrier wrote: > > (hey, this is why "desktop" installs the whole bloat of KDE *AND* Gnome ). > > It's possible that this statement is false, and that some change might > have been made in this area under less than clear circumstances as a > kind of experiment just to see how long it takes for someone to notice > and what traspires if they do. Or not. I currently don't see what's exactly meant in you above statement, Joey. KDE and Gnome tasks have been created but they don't appear in tasksel and are more (as far as I've understoof) intended for making the life of derived distributions easier. And, anyway, the KDE/Gnome thing is only one of the points I meant about the "usability" of our default desktop system, when we target our dear Bob User. For sure, one of the problems we have is more or less mentioned in my initial mail: we (d-i team) maintain what currently installs the default Debian desktop...however we do not test it enough...because we focus on the many other issues we're all working on. And, indeed, when I say that "we" maintain tasksel, the reality is that *you*, Joey, maintain tasksel...:). And, except your testing lab and a few installation reports we get, we don't have that much feedback and testing made on stuff installed by default on a Debian desktop system. We usually know that it either "works" or "is broken"but when it works (it usually does), we don't really know whether the result is something that can be used by Bob without reading the entire set of books about Debian. I hope that this discussion will trigger enough interest among fellow developers and lead much more testing and activity around this. (hoping it won't turn in a nice thread tree like the ones you described once in a famous post in your blog) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian Installer team monthly meeting minutes (20051214 meeting)
(reply-to: debian-boot)
The eigth Debian Installer team meeting was held from 21:00UTC to 22:24UTC
on Wednesday December 14th 2005.
There were about 80 people connected to the channel during the meeting
and 17 of them spoke during the meeting at least once.
The full log of the meeting is available at
http://people.debian.org/~bubulle/d-i/irc-meeting-20051214/log
Beta2 plans
---
Most of the meeting discussions were directed at plans for a D-I Etch
beta2 release.
Graphical installer (G-I)
-
Most activities regarding G-I have recently been focused on fonts handling.
Most needed fonts for non Latin languages are in the process of being
identified. Davide Viti coordinates this work on a Wiki page
(http://wiki.debian.org/DebianInstallerGUIFonts).
Two work directions are being explored simultaneously:
-font "reduction" to remove glyphs which could conflict with glyphs
provided by other more specialized (and nicer) fonts
-font "prioritization" so that, depending on the language, specialized fonts
have some priority over others
It is agreed that releasing the g-i daily images with "the current
font status" is a good way to expose this work to discussion.
Finding the Good Fonts is still work in progress:
-Arabic done
-Hebrew OK
-Korean probably OK
-Japanese and Chinese on their way and converging to an acceptable solution
-Cyrillic would be OK with DejaVuSans but probably a newer version which
requires a newer fontforge
-Indic still needs work, we need more input from debian-in people
In general, we still need to sollicitate input especially for non
Latin languages. Releasing G-I daily images with the current font
status will be a good way to do so.
Include G-I in the D-I beta2 release?
-
The main blocker which actually prevents an official release of G-I is
the udeb dependency issue which currently prevents g-i images to be
rebuildable without having udebs in localudebs/
So, a decision to include G-I as a full component of beta2 is very
likely to delay beta2 too much in case issues currently blocking beta2
are quickly solved (see below).
The current decision is to release G-I as an Alpha version aside from
beta2, maybe this time with (netinst) CD images.
G-I meeting in Estremadura
--
The G-I contributors will try to hold a work meeting inside the
"Estremadura meetings" proposed recently
(http://lists.debian.org/debian-devel-announce/2005/12/msg3.html).
A date in a very near future would be most appropriate.
Davide Viti volunteered to try arranging this: find who would come and
get in touch with both Andreas Schuldei and the local organisers. The
January 18-22 timeslot seems the best, but is very short notice.
Beta2 release plans
---
Several subtopics were discussed about beta2 release:
Kernel issues
-
First of all, if we want beta2 to have an updated kernel (and we do),
we need at least 2.6.14 in testing.
Then issues with initrd generators have to be solved. 2.6.14 still has
a few RC bugs and yaird and initramfs-tools have problems with quite a
few configurations.
2.6.14 has been decided to default with yaird by the kernel team so we
should focus on this (unless we want to skip it... which will certainly
delay beta2). 2.6.15 will default to initramfs-tools.
D-I's base-installer already has support for initramfs-tools and is
prefered slightly because it has less dependencies.
These issues MUST be the main focus of D-I contributors starting from
now. Stopping any other risky change has been decided.
The general discussion showed ... that more discussion is needed. The
first decision seems to be: 2.6.14 or 2.6.15? 2.6.15 is to be released
in the next two weeks, according to Maximilian Attems.
This decision is primarily for the kernel team to take; d-i can but
follow.
Network interfaces - Discover/udev
--
These two topics were unrelated in the agenda but have proven to be related.
It is currently very likely that systems with two network interfaces
will end up with both switched on the installed system after the
reboot. This is of course a blocker.
The discussion showed that sticking with discover while udev is used may be
the main reason for this.
An agreement to try abandoning discover has been reached (we can
revert this is it breaks too much stuff). This is very likely to break
some parts of D-I on some architectures, but the general feeling is
that keeping discover will add hacks over hacks.
The D-I team will certainly need some external help (Colin Watson
suggested brining Scott James Remnant on the topic as he maintains
Ubuntu's udev) as well as closer work with Marco d'Itri who
maintains udev in Debian.
A lot of more detailed issues about this topic can be seen in the meeting log.
New busybox
---
An update of busybox for a few issues is needed ("umount -a" fix,
"readlink -f" patch). Syncing wit
Re: New make is breaking several packages
Quoting Daniel Schepler ([EMAIL PROTECTED]): > > It breaks a widely used feature. Why should this change not be > > considered a make bug? > > In make's NEWS.Debian.gz it says this change was for POSIX compliance. And > since there's the simple way to rewrite these things that I outlined, I think > it's better to make our debian/rules and Makefiles compliant than to revert > this change. Well, my first reaction is that this should have been coordinated or at the very minimum announced to -devel, which is not *only* a flaming mailing list..:) I even think that -devel-announce would have been appropriate. No offense intended for the maintainer, whoever it might be -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
> > Bureaucracy is often designed to do lots of things "better" and it often > > doesn't achieve them. It creates needless hassle, more 'paperwork', and > > has very few benefits besides making people feel like they've done > > something useful when they haven't. > > > You are saying that requiring people to find co-maintainers is > "bureaucracy"? Someone I know well recently got co-maintainers for > three of his packages by posting a single message to debian-devel. I think that what Erinn wants to say is more that *forcing* (or putting pressure on) maintainers to find co-maintainers would be "bureaucracy". I think that she will however agree that *encouraging* co-maintenance for "key" or "important" packages (which is a very vague definition) is one of the ways to go. But she will probably be able to say it by herself: I'm just interpreting The word "bureaucracy" here has of course a negative meaning for "constraints that are felt unneeded"which I mostly agree with. I sometimes defend the idea that bureaucracy may be needed but I'm not sure it's needed here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
> The fact that a package is important (note: not referring to Priority > here) is not indicative of the amount of work necessary, nor is it > indicative of the amount of time and expertise a given maintainer has > for it. Sure. However, an "important" package will more badly suffer from lack of maintenance during several months or even years. This is the main weakness of packages maintained by single individuals. By experience, it takes time before it becomes obvious that the person who was very well maintaining this or that package is no more able to do soor lacks time and is slowly neglecting it. At the very minimum, a team maintenance will increase our chances to have a faster reaction in such cases I perfectly hear your objection to an increased pressure to use team maintenance and maybe avoid putting too much "social pressure" for team maintaining everything. I think this discussion had the advantage of making the issues clearer and give more clues to people who will have to make the choice of team-maintaining something. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
D-I team meeting on Saturday January 21st 17:00UTC
The monthly Debian Installer team meeting which was initially scheduled for January 14th is reported to January 21st, as several D-I developers will attend the "Extremadura session" about the graphical installer development (http://wiki.debian.org/WorkSessionsExtremadura). Topics for the meeting are still to be completed (http://wiki.debian.org/DebianInstallerMeetings) but it's very likely that the main topic will be the preparation for the Etch beta2 release of the installer. (this mail is CC'ed to -devel in an attempt to draw a few more attention for these monthly meetings, especially from people who used to be active in the D-I development in the past..:-))) -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Advices, comments? Bug#345651: passwd package should be essential?
I tend to agree with Kurt opinions below and thus, I'm tempted to make passwd "Essential: yes". The opinions in the shadow package maintenance team slightly vary. However, given that this is an important decision, I think it is a good idea to get the advice of fellow developers. So, please comment (asking the -ctte is probably not worth it unless the discussion shows that nothing really clear shows up). - Forwarded message from Kurt Roeckx <[EMAIL PROTECTED]> - Date: Mon, 2 Jan 2006 16:09:04 +0100 From: Kurt Roeckx <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [Pkg-shadow-devel] Bug#345651: passwd package should be essential? Reply-To: Kurt Roeckx <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Package: passwd Version: 1:4.0.13-7 Severity: important Hi, I'm wondering if the passwd package should be essential or not. And I want to start with quoting some relevant portions of the policy: 3.5. Dependencies [...] Packages are not required to declare any dependencies they have on other packages which are marked `Essential' (see below), and should not do so unless they depend on a particular version of that package. [...] 3.9.1. Prompting in maintainer scripts [...] Packages which use the Debian Configuration management specification may contain an additional `config' script and a `templates' file in their control archive[2]. The `config' script might be run before the `preinst' script, and before the package is unpacked or any of its dependencies or pre-dependencies are satisfied. Therefore it must work using only the tools present in _essential_ packages.[3] [...] 7.2. Binary Dependencies [...] `Depends' [...] The `Depends' field should also be used if the `postinst', `prerm' or `postrm' scripts require the package to be present in order to run. Note, however, that the `postrm' cannot rely on any non-essential packages to be present during the `purge' phase. = Currently, you can perfectly remove passwd since it's not essential, and nothing essential has a dependency on it. Bash used to have a dependency on passwd, but this was removed in 3.1-1, and was replaced by one on debianutils because of #208514. And debianutils is essential. I believe a better packages for that would have been base-passwd. So, passwd was virtually essential because bash had a dependency on it, but now it doesn't anymore. So why do I think passwd needs to be essential? There are several things in the package that one might want to run from one of the maintainer scripts from debconf, like useradd, groupadd, userdel, ... Kurt ___ Pkg-shadow-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/pkg-shadow-devel - End forwarded message - -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Quoting Loïc Minier ([EMAIL PROTECTED]): > (I don't think the "non-free" argument is here of importance > considering it's a web service, in the same way as Google or > buildd.net. I shall get flamed for these remarks.) As long as Debian doesn't want to build its own launchpad, sure. But the non freeness prevents us building such infrastructure on our ownn machines. This is especially true for Rosetta, the i18n infrastructure even though many translators would really love having a Rosetta-style infrastructure for Debian work. This topic will be discussed and probably worked on during the i18n Extremadura meeting we will have in September: http://wiki.debian.org/WorkSessionExtremadura2006i18n -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
First summary: passwd package should be essential? It probably shouldn't.
So far, we only got two advices but, imho, enough motivated to make me change my initial feeling. It seems that nothing has yet motivated that passwd should indeed be Essential: yes. Steve bringed the very interesting rationale: "I think we really should not be using it *except* for packages that we require to be functional when in an unconfigured state. The passwd package certainly doesn't qualify in this". He's right: passwd is perfectly functional in unconfigured state. He also counters the argument of paswd utilities being needed in config scripts by explaining that packages requiring useradd/userdel/etc in *config* scripts are probably wrong. Lars added mostly the following: "Is there a problem with packages that need stuff from passwd simply depending on passwd". He also seems right. There doesn't seem to be any problem to this as long as the requirement is not in config scripts. Moreover, most package who would depend on some passwd stuff probably would because they need to add/remove users or groups. However, a recent survey has proven that indeed nearly all packages doing this actually (Pre-)Depend on adduser and use the high-level utilities in adduser rather than low-level utilities from passwd. For the above reason, some of these package may be indeed broken if they require either adduser or useradd in their config script. But that's these packages problem not passwd problem. In summary, it will need a lot more advices following Kurt Roeckx suggestion in #345651 to change my mind back and make passwd Essential. Kurt, would you mind commenting? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-torrent (WAS: Re: apt PARALLELISM)
> I've just noticed it, and the fun part of this discovery, is that I also > found why my ISP has closed sianka.free.fr: Too much hits since the > latest Debian Weekly News, and the new apt-torrent 0.3.1-1 package ! The solution is simple: get it in the Debian archive..:) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
> Unless such a service is a Debian controlled resource, or is > fully GPL'd, and has open data, I do not think we should tocuh it ^^ I'm sure you mean DFSG-free here, right? :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dissection of an Ubuntu PR message
Quoting Matt Zimmerman ([EMAIL PROTECTED]): > I don't intend to participate in this type of email argument with you; I've > yet to see it pay off for anyone involved. However, I will be in London > later this month and would be willing to use that opportunity to civilly > discuss your concerns face-to-face. Which is probably what is missing a lot in such controversial issues: email has always proven to be the worst communication media ever for controversial discussions. ...which mostly explains why I refrained my self to participate in these threads while my feeling is quite widely shared with Frans Pop's feeling. /me...who expects tons of Ubuntu/Debian discussions at Solutions Linux in Paris (Jan 31-Feb 2) with both fellow French developers, users...and Ubuntu users as well. No chance that people from Canonical show up over there? I can even host (Perrier's bed and breakfast, including cheese)...:) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: French cheese
Quoting Matt Zimmerman ([EMAIL PROTECTED]): > Unfortunately, this conflicts with a development sprint we're having in > London, so that won't be possible at that time. > > My heart breaks at the prospect of a missed opportunity to gorge myself on > cheese... Well, it's just a matter of jumping in the first Eurostar in the morning, be at Gare du Nord around 8 or 9, go to Solutions Linux, drink, talk and eat cheese all day long with fellow Debian and Ubuntu people, then jump in another Eurostar back to London (with some cheese in your luggage) and be back for hacking with your fellow Ubuntu people late in the night. And, for next year, just plan your development sprint in Paris..:-) (I'm half-serious and even really serious here) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
> While I'm sure there'll be some people who'll complain no matter what, > I don't see what the problem with mailing patches directly to the BTS > is. As far as tracking is concerned, making use of "[EMAIL PROTECTED]" > usertags or similar would seem sensible. Silly question, probably, but wouldn't this flood the BTS? If not, this sounds like an interesting suggestion and the shadow package maintenance team is opened to serve as a test case for this -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
> But not *our* problem. *They* should do the work to get it better. If > they dont do it - then it is their problem, not ours. I imagine that Raphaël was thinking about debian-edu for instance. We recently tried to push some involvment among French DD's to get in closer touch with people packaging educational software and building Debian-based specialized distros (Abuledu, Ofset software...). Most often, here, Debian developers can bring them the expertise they may need to work on improving their work (often packages) and get it enter Debian. A few of use are currently trying to build this link...and for building links you usually need to have both sides involved..:-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348382: ITP: collatinus -- lemmatisation of latin text
Package: wnpp Severity: wishlist Owner: Christian Perrier <[EMAIL PROTECTED]> * Package name: collatinus Version : 7.13 Upstream Author : Yves Ouvrard <[EMAIL PROTECTED]> * URL : http://www.collatinus.org * License : GPL Description : lemmatisation of latin text Collatinus can be used to lemmatise latin texts, i.e. extract words and make a lexicon which indicates for each word its canonic form, and how the form actually found in the text was derived from it, for instance by declining it. Example : rosam gives : rosa-rosae -- acc. sing. Collatinus provides a nice graphic front-end to each operation. This software has a long life in the French Educational software community. The Debian packaging has been done and maintained by Georges Khaznadar who will be the maintainer of the package in long term. This ITP is a first attempt to add one of the numerous interesting developments made in the educational community in France to integrate the official Debian archive and thus be more easily available to Debian and Debian derivates (debian-edu/Skolelinux, Edubuntu) users. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
D-I team January meeting MOVES AGAIN: Saturday January 28th 17:00UTC
> The monthly Debian Installer team meeting which was initially > scheduled for January 14th is reported to January 21st, as several D-I > developers will attend the "Extremadura session" about the graphical > installer development > (http://wiki.debian.org/WorkSessionsExtremadura). And, sorry, the above was completely wrong and the "Extremadura session" is being held from today up to next Sunday. My mistake. So, The Debien Installer team meeting is AGAIN reported to Saturday January 28th, 17:00UTC. Please accept my apologies as the original date of Jan 14th would have perfectly fit, but for some strange reasons I was figuring out that the Extremadura meeting was happening at that moment. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
> Is there anyone from Debian who thinks that changing the Maintainer > field is a bad idea in these cases (remember that this isn't about > credit, because we would certainly request that the Debian maintainer > still be mentioned as such in a suitable fashion)? So deep in a thread that certainly can be called a flamewar, you probably need to quietly ask this elsewhere if you want answers from a real majority of ppl..:-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
> It is the great danger of this thread that Matt et al. will feel > sufficiently put upon that they *don't* take to heart the legitimate > suggestions that could improve cooperation between Debian and Ubuntu (and > "distinguishing version numbers for binaries" being by far the least of > these). "If you're not cooperating with me the way I want, I'll make you > regret it" doesn't benefit *anyone* involved. Indeed, it just makes it > easier to conclude that Debian is no longer worth the effort of trying to > give back to. Seconded. I am amazed by the involvment made by Matt and a few other Ubuntu people in this thread. And I actually fear they could give up and lose what I personnally consider as good will. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian Installer team monthly meeting minutes (20060128 meeting)
(reply-to: debian-boot) The ninth Debian Installer team meeting was held from 17:00UTC to 18:09UTC on Saturday January 28th 2006. There were about 73 people connected to the channel during the meeting and 13 of them spoke during the meeting at least once. The full log of the meeting is available at http://people.debian.org/~bubulle/d-i/irc-meeting-20060128/log Beta2 release - Most of the meeting discussions were targeted at the D-I etch beta2 release process. Please refer to http://lists.debian.org/debian-boot/2006/01/msg00559.html for the current timeline. Kernel status - The transition of 2.6.15 kernel packages to testing is what determines the whole schedule, so the discussion was initially focussed on this. An upload of 2.6.15-4 packages to unstable is planned around this week-end. (2/2 note: did not happen yet) A dependency loop exists with udev but is not release critical, from the RM point of view, so this should not prevent 2.6.15-4 to enter testing. Frans confirmed later with Steve Langasek this is a RC issue but couldn't find the bug anymore. Maximilian Attems mention a leak with md (drivers?) which supposedly has been fixed in lkml. Whether this is RC or not needs to be determined. In short, the transition of 2.6.15-4 has to be fasttracked and we have to remind all our fellow developers that this is a blocker for D-I beta2 release. Initrd generators - No blocker issue remains. There is work on klibc and stuff that needs choices and decisions (see the meeting log for the details) but this is anyway not a blocker for us as there are working options for all arches with some recent work on base-installer. Status of udebs transition -- Almost all general AND arch-specific udebs have been rebuilt and uploaded. Some work remains for m68k and hppa. Frans will post a reminder to the porters. hppa needs to switch from 2.6.14 to 2.6.15 and upload its arch-specific udebs (post-meeting update: Dann Frazier did the uploads, except kernel that will be handled by Bdale Garbee). m68k needs kernel udeb updates and its arch-specific udebs as well. base-installer will be rebuilt and uploaded to fix the last discovered untranslatable strings and add the needed translations. An iso-codes upload could trigger some interest in rebuilding localechooser and then add some more translations for country names. choose-mirror could benefit from this as well. Christian will first check whether he can do the NMU for iso-codes (usually well accepted by its maintainer). A request to hint locales (and therefore) should be sent as its 2.3.5-10 version is needed by localechooser. There is no blocker except the presence of a udeb requiring a request from us. (post-meeting update: this has been done by Frans) Release blockers The main blocker is obviously the kernel transition. See above. Other issues exist: Some work should still be done on localization-config to integrate the stage1. Konstantinos Margaritis will be unavailable for months, thanks to the Greek Army. He's currently seeking for someone to act as l-c co-maintainer during that time. Anyway, even without l-c, the localized installs work pretty well as X now successfully detects the needed keymap. So, this issue is not a blocker. A few UTF-8 issues currently exist. The weirdest one seems to be corrupted display (Mojibake) with languages *not* using UTF-8 (such as Korean) when debconf screens are shown during pkgsel runs. The workaround is to switch all languages to UTF-8 (which is pretty much the case now). These UTF-8 issues have to be coordinated. Miroslav Kure volunteered to follow all such issues and summarize them on the wiki, for instance in http://wiki.debian.org/UTF8BrokenApps. There seems to be some brokeness with aptitude on hppa. The issue has to be made clearer right now. Julien Louis will do an install report of the issue he encountered. Both hppa and m68k are currently uninstallable because they are being ignored for testing migrations and bugs are preventing some packages in base from being updated which causes debootstrap to fail... All these are actually not really blockers except the issue of the netinst image (and, of course, the kernel transition). Finalize the schedule - Nothing really worth mentioning. The blocker is the kernel transition. Frans schedule is still pertinent. Heavy testing can already begin, by using the daily builds (the dailies point to sid_d-i, which is currently appropriate). Official testing and filling the release-checklist file in installer/doc/devel will begin when all udebs have been migrated to testing and the daily links have been switched for etch_d-i. This ends discussions directly related to beta2. partman-crypto status - Most issues are summarized on http://wiki.debian.org/DebianInstallerCrypto. Max Vozeler explains that the main blocker to build and upload a ud
Re: Bug#352303: ITP: gsynaptics -- configuration tool for Synaptics touchpad driver of X
> Description: configuration tool for Synaptics touchpad driver of X server
> GSynaptics is a configuration tool for Synaptics touchpad driver
> of X server. This enables you to modify driver parameters on the fly
> through GUI interface using "synclient" program as its backend.
> .
> SECURITY NOTE! This program requires you to enable the "SHMConfig"
> option in the X configuration file. This is *not* *secure* if you
> are in an untrusted multiuser environment. For typical laptop PC
> environment with only one user account where this package is most
> likely to be used, risks involved can be acceptable level.
> .
> Please read /usr/share/doc/gsynaptics/README.
I usually don't criticize the package descriptions but I'm not sure
that such information actually pertains to the package description. It
should rather go in README.Debian
I would also advise against the use of exclamation marks and
*pseudo-bold text*. Package descriptions os a place where neutral
language should be used: facts, only facts and not opinions.
Addressing the users ("you") in package descriptions is also something
I would discourage.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#352303: ITP: gsynaptics -- configuration tool for Synaptics touchpad driver of X
> Now, my control contains following only: > - > GSynaptics is a configuration tool for Synaptics touchpad driver > of X server. This enables you to modify driver parameters on the fly > through GUI interface using "synclient" program as its backend. > -- Let's nitpick a little: GSynaptics is a configuration tool for the Synaptics touchpad driver of the X server. This allow for modifications of the driver parameters on the fly through a GUI interface by using the "synclient" program as backend. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
TrueType fonts packages maintenance team proposal
Preamble The maintenance of fonts, at least TTF fonts, is currently splitted out among many maintainers in the project, while the problems faced by TTF font package maintainers are nearly always the same. From my own recent experience of helping/sponsoring/taking over a few font packages, I have concluded that some coordination between font packages maintainers could be an interesting improvement for the project. So, I hereby propose to think about a possible TTF fonts packaging team. Project goals - The first goal for this team would be setting up a font packaging policy. Font packages are usually very simple packages, but having a common packaging style would greatly help incorporating new fonts in Debian. Usually, people who request the packaging of fonts are not often very experienced people and that would help smoothing this learning curve. Having a common maintenance team would also optimize the usage of "resources", namely font experts, who are not that common. My personal vision of this is having the font maintenance team slowly becoming the maintainer of more and more ttf-* font packages, with the agreement of the original maintainers, of course. Those would then remain as "main maintainer" by being listed in the font "Uploaders" field. The team could also seek for more fonts to be included in Debian, possibly after setting up some prerequisites to avoid too crappy fonts. The project could also include the maintenance of font-related tools, such as fontforge or defoma (which seems mostly abandoned, but probably requires solid knowledge or Perl and cryptic programming...:-)). Project resources - For this, I imagine setting up a maintenance team, with common resources: - a dedicated project on Alioth, with a common SVN repository - a mailing list hosted on lists.debian.org Then, I propose contacting the ttf-* font packages maintainers and propose them to join the team, explaining that this is a volunteer action anyway and they will remain as the "main" maintainer of their packages. Next steps -- The first step is trying to see whether this proposal receives interest, by my fellow Debian developers, as well as font packages maintainers (several of them not being yet a DD). So, please follow up in -devel to show interest, criticism, laughs and the like. I do not intend to keep the "lead" of this very long, mostly because I'm not really a font expert. But, at least until a strong team emerges, I can give some time in coordinating the whole stuff and slowly gather the current font packages maintainers. I have voluntarily limited the scope of the project to TTF fonts, which become more an more popular. This is mostly by ignorance and because of my loose knowledge of other font systems. Feel free to propose a wider project (but not too much wide, also: having a first limited focus is probably more realistic). Please feel free to point me at existing projects I wouldn't be aware of (debian-desktop?) which cover similar goals... List of current ttf-* packages -- (just looking at the packages descriptions give a good idea of the non-coordination of font packaging..:-))) ttf-arhangai - A TrueType font with Mongolian Cyrillic letters ttf-arphic-bsmi00lp - "AR PL Mingti2L Big5" Chinese TrueType font by Arphic Technology ttf-arphic-gbsn00lp - "AR PL SungtiL GB" Chinese TrueType font by Arphic Technology ttf-arphic-gkai00mp - "AR PL KaitiM GB" Chinese TrueType font by Arphic Technology ttf-baekmuk - Baekmuk series TrueType fonts ttf-dustin - Various TrueType fonts from dustismo.com ttf-f500 - Wipeout 3 Font ttf-isabella - The Isabella free TrueType font ttf-kochi-gothic - Kochi Subst Gothic Japanese TrueType font without naga10 ttf-kochi-mincho - Kochi Subst Mincho Japanese TrueType font without naga10 ttf-sazanami-gothic - Sazanami Gothic Japanese TrueType font ttf-sazanami-mincho - Sazanami Mincho Japanese TrueType font ttf-staypuft - The Stay-Puft free TrueType font ttf-summersby - Free TrueType typeface font ttf-thryomanes - A Unicode font covering Latin, Greek, Cyrillic and IPA ttf-tmuni - font for Tibetan, Dzongkha and Ladakhi (OpenType Unicode) ttf-uralic - Truetype fonts for Cyrillic-based Uralic languages ttf-kochi-gothic-naga10 - Kochi Subst Gothic Japanese TrueType font with naga10 (non-free) ttf-kochi-mincho-naga10 - Kochi Subst Mincho Japanese TrueType font with naga10 (non-free) ttf-mikachan - handwritten Japanese Truetype font libfont-ttf-perl - Perl module for TrueType font hacking libttf-dev - FreeType 1 development files (static library and headers) ttf-alee - A Lee's EunJin family Hangul truetype fonts ttf-arabeyes - Arabeyes GPL TrueType Arabic fonts ttf-arphic-bkai00mp - "AR PL KaitiM Big5" Chinese TrueType font by Arphic Technology ttf-arphic-ukai - "AR PL ZenKai Uni" Chinese Unicode TrueType font Kaiti style ttf-arphic-uming - "AR PL ShanHeiSun Uni" Chinese Unicode TrueType font Mingti sty
Re: TrueType fonts packages maintenance team proposal
> I'd be glad if you'd keep the Debian TeX Task Force (currently at > [EMAIL PROTECTED], soon at [EMAIL PROTECTED]) informed about > drafts of this policy. Although we don't currently package any TTF Of courseActually, I see some difference between TTF fonts which most common use are desktop environments and Type1 fonts, which use is more specialized (correct me if I say stupid things, I'm far from having good knowledge of all this...which is actually one of the motivations for a team...:-)) So, unless some good arguments come up, this team and "loose policy" would then be limited to TTF fontsbut of course, the TSF will be kept posted (will try to remember crosspositing for a next announcement). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: TrueType fonts packages maintenance team proposal
Quoting Jaldhar H. Vyas ([EMAIL PROTECTED]): > >Let's write a fontpackages sub-policy instead, and let it up to the > >people to decide how they want to maintain their packages. > > > > Christian, I have to agree with Daniel here. We don't really need joint > maintenance but coordination on font policy would be a good idea. (Also if > someone could explain just how the heck defoma is supposed to work...) I actually have no intent to enforce this to people who prefer maintaining the package they maintain alone. My current view is more having a common place for package maintenance (for maintainers who want to join), possibly with "sub-places" for packages which have joined this "loose team". There, each package maintainer would have to choice to either be the only responsible person for the package (aka be "Maintainer" and "Uploader" alone)or give precedence to the team...or whatever combination. Again, no enforcement for anyone to join the team and the packaging policy would then be more a set of guidelines rather than an enforced policy such as other packaging policies. As you mention, Jaldhar, there are a few things related to font packaging which are not obvious to people who package fonts. "defoma" is among theseand fontforge os probably another one. So the team could also be a good place for font maintainers to share their experience and maybe also benefit from a wider experience by epople who have a good knowledge of such deep technical stuff. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[MEETINGS] Next D-I team meeting on Saturday March 4th 17:00 UTC - Prepare next release
The next Debian Installer team opened meeting is scheduled for Saturday Mar 4th 17:00 UTC. This meeting will be focused on post-beta2 release goals. The D-I beta2 release is currently scheduled for the same day, so March 4th will be a pretty much important date for D-I. The Wiki page is opened for the meeting agenda. http://wiki.debian.org/DebianInstaller/Meetings I will add timings to the agenda at the last minute, as usual, so probably on Saturday morning UTC. Expect a meeting duration of about 1h30 or maybe even 2h. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is there some guideline saying that native packages should be avoided?
> I would like to ask whether there really is such a guideline, and if so, > which are the technical / political reasons that lead to it. I have Wearing my i18n hat, I can add one reason, certainly not THE reason but yet another argument to avoid native packages except for Debian-specific stuff (apt, dpkg and the like...). When packages are internationalized, we (Debian i18n team) recommend translators to first focus on them if there is translation work to do. The rationale for this is that translations for Debian-specific stuff is better coming "from the Debian world" while other packages are likely to be translated by some other way. So, making a package Debian native gives it some priority for being translated first. There are already a few i18n'ed packages in the archive that are native packages and are actually NOT Debian-sepcific (xmorph, lpe, pdbv, rpncalc, wxwidgets2.6)I'd really like not seeing more..:) I think I have reported a bug against all of them and, IIRC, the maintainer's arguments have not been very convincing..:). moreover, several of these are currently obviously not maintained. Some have pending French translations since more than 1 year. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355088: ITP: ttf-lao -- TrueType font for Lao language
Package: wnpp Severity: wishlist Owner: Christian Perrier <[EMAIL PROTECTED]> * Package name: ttf-lao Version : 0.0.20060226 Upstream Author : Anousak Souphavanh <[EMAIL PROTECTED]> * URL : http://prdownloads.sourceforge.net/laofoss/ * License : LGPL Description : TrueType font for Lao language This package includes fonts that are suitable for the display of the Lao language. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
REMINDER: Next D-I team meeting on Saturday March 4th 17:00 UTC - Prepare next release
This is a reminder: The next Debian Installer team opened meeting is scheduled for Saturday Mar 4th 17:00 UTC. That is TOMORROW. This meeting will be focused on post-beta2 release goals. The D-I beta2 release will probably be delayed a little bit but the meeting will more focus on post-beta2 anyway. The Wiki page is still opened for the meeting agenda. http://wiki.debian.org/DebianInstaller/Meetings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
D-I team meeting of 20060304: log available
The wiki page of D-I team meetings (http://wiki.debian.org/DebianInstaller/Meetings) now links the full log of the March 2006 meeting that took place yesterday from 17:00UTC to 18:30 UTC. http://people.debian.org/~bubulle/d-i/irc-meeting-20060304/log The meeting minutes will be published as soon as possible. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Fonts packages maintenance team (second) proposal
(this mail is BCC'ed to many font packages maintainers, please respect the Reply-To field) After the initial proposal which I submitted a few days ago (http://lists.debian.org/debian-devel/2006/02/msg00694.html), a small thread occurred on debian-devel which raised a few topics from my initial mail. This mail tries to summarize them and then make a new proposal, rewritten in an attempt to take all advices in consideration. 1) a few font maintainers mentioned that TTF fonts packaging is pretty easy and low-resourse demanding activity. So, the need for team maintenance is judged pretty low for these packages. 2) not only considering TTF fonts but all other font formats, especially Postscript fonts could be good 3) a quite widely shared feeling is that sharing experiences might be good 4) involving the TeX Strike Force (at least keeping them posted) is wished Here is how I think we can take this into consideration: 1) the proposal will make it clear that joining the team is a volunteer action. No active or passive enforcement of team maintenance but rather common experience sharing. The team would have a repository but only for maintainers volunteering to move their work there. 2) the team opens itself ot all font packages maintainers. This will certainly require more Postscript font specialists to join and bring their own knowledge 3) well, that point was already in the initial proposal..:) 4) The TSF will be kept posted Now for the new proposal: = Preamble The maintenance of fonts, True/OpenType, Postscript fonts and the like, is currently splitted out among many maintainers in the project, while the problems faced by font package maintainers are nearly always the same ones. Recent experience of helping/sponsoring/taking over a few TTF font packages leads the conclusion that some coordination between volunteer font packages maintainers could be an interesting improvement for the project. So, I hereby propose building a Debian fonts team. Project goals - Improve communication - This team will, by the use of a mailing list, allow good communication among font package maintainers. This can help all of us to benefit from the experience of font experts, who are not that common. Share resources --- A common SVN repository, hosted on Alioth, will allow font package maintainers to host their package development, if they wish to do so. Increase Debian font base - The team can become the natural entry point for new proposals of font packaging, for instance packaging of fonts targeted to new supported languages (a quite common case now as active lobbying is constantly done to bring new translators and new languages in). The team could also seek for more fonts to be included in Debian, possibly after setting up some prerequisites to avoid too crappy fonts. Write a font packaging policy - One of the goals for this team would be setting up a font packaging policy. Font packages are usually very simple packages, but having a common packaging style would greatly help incorporating new fonts in Debian. Enforcing this policy to existing font packages is not in the top priority of the team. Bring improved maintenance of font-related tools The project could also include the maintenance of font-related tools, such as fontforge or defoma (only with agreement of their respective maintainers who are highly welcomed in the team). Project resources - The common resources for the team will be: - a dedicated project on Alioth, with a common SVN repository, named "pkg-fonts" - a mailing list hosted on lists.debian.org Next steps -- This mail is CC'ed to all ttf-* font packages maintainers. Getting their reaction to this proposal is important, especially for those who didn't see the first initial mail. So, please follow up in -devel to show interest, criticism, laughs and the like (if needed, temporarily subscribe to -devel...you'll see it's not *only* made of trolls and flamewars). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fonts packages maintenance team (second) proposal
> Also if such a team is created I don't have a lot of time to help a lot, > so I won't refuse to give some help, but I probably will not be the most > active person in the team! > > What I really like in the proposal is having a font policy, and maybe a > sort of package skeleton for new fonts. But that does not necessarily > implies the creation of a team. Nothing against though. > > All that said, I am not really for or against maintaining such packages > in a team, so if such a team is created, I will put my package in team > maintainance, if not I won't try to push everybody to create a team. Aurélien, your remarks fit some of the remarks made by other font package maintainers. This is something I tried to cope with in the proposal. The proposal insists on the team being more a place to federate energies and knowledge, more than enforce work methods. In short, existing font package maintainers are encouraged to join the team, even as lurkers, to just know what happens in that field. This is what I call the "loose" part of the team. For instance, for your own case, I would encourage you to subscribe to the team's mailing list, read it when you have time and just follow what happens. And, for people who don't even wish to join at all, well the team will not point fingers at them, or whatever. We accept that various Debian package maintainers have different work methods and we won't try enforcing ours to others. Hope this answers the possible concerns you (or others) might have here. signature.asc Description: Digital signature
Re: Fonts packages maintenance team (second) proposal
> besides the fact that I agree with the people saying that this team is a > unnecessary institution for *package maintenance*, and that ttf-opensymbol > is built from the openoffice.org source package anyway ... I think I need to try making the point clearer as many people seem to hve concerns (or could misunderstand) what is the intent here. Sure, I believe that a team can bring more to package maintenance than some of you seem to believe. Of course, for package such as yours, René, where the maintenance is obviously active and efficient, for sure the team won't bring you much and simply ignoring the team (or lurking on its mailing list as I just wrote in answer to Aurélien message) will certainly be OK. However, what I feel is that several font packages are mostly "one shot" packages, ie packages built once because a new free font popped up, and no more actively maintained. This may even become more and more true while we are extending our language coverage (wearing my i18n hat, here) and see the need for new fonts supporting new ranges of Unicode. Here, the team can bring a basic framework for people who want to bring new fonts in Debian...or even provide the maintenance for people who *need* a new font in Debian but feel they don't have the skills for a Debian package maintenance. I have live example in my mind such as the "ttf-lao" font I just uploaded and the "ttf-dzongkha" font I will soon upload. The team can also act as a gateway between some upstream maintainers of "general" fonts which intend to cover as many parts of Unicode as possible (here, I think about ttf-dejavu and ttf-freefont mostly)so that they can *integrate* the work done on some more specialized fonts (for instance, the fonts I mentioend above). > Christian Perrier wrote: > > Improve communication > > - > > This team will, by the use of a mailing list, allow good communication > > among font package maintainers. This can help all of us to benefit > > >from the experience of font experts, who are not that common. > > ... this ... > > > Write a font packaging policy > > - > > One of the goals for this team would be setting up a font packaging > > policy. Font packages are usually very simple packages, but having a > > common packaging style would greatly help incorporating new fonts in > > Debian. > > ... and this ... > > makes sense. > > > Enforcing this policy to existing font packages is not in the top > > priority of the team. > > What is a policy useful for when most packages are not following it? I > think if there's a sane policy people should have to migrate to it; > otherwise you don't need to write a policy for that... The spirit in this proposal is essentially: do not break existing package practices when they have been proven working. This is what I want to say above: if we succeed in writing a font packaging policy, then there will be a long period of time where this policy will remain as a recommendation. Maybe, some day, after it has been proven that a consensus is reached among font package maintainers, it will become an enforceable sub-policy. But, here, the team will need to work with the maintainers who did choose to stay outside the team, for various (and most often good) reasons. signature.asc Description: Digital signature
Re: Bits from the kernel team
Quoting Bastian Blank ([EMAIL PROTECTED]): > Hi, > > Half-way between the sarge release and the etch freeze the Debian kernel Aren't we closer from etch freeze than sarge release? :-) This is at least my feeling when I consider the packages and the proejcts I'm part of: we, developers, should begin to put ourselves in release mode.now. signature.asc Description: Digital signature
Re: Fonts packages maintenance team (second) proposal
> > - a mailing list hosted on lists.debian.org > > where? I didn't see any... or is it in alioth? I didn't begin setting stuff up, except an Alioth project. I prefer seeing what directions the discussion about the proposal goes to, before setting things that could be misnamed/useless/whatever...
Re: For those who care about stable updates
> If I were a crazier man I would say something like:
>
>"The end is neigh!"
>
> It is a dark, dark day for Debian, indeed.
Death of Debian predicted. Film at 11.
Believe it or not, but Joey's resign could actually be more a Good
Thing than a bad thing.
Seeing renewal and new blood come in is not necessarily bad. Not
because Joey did his job badly, "au contraire". But mostly because
accumulated frustration would have slowly affected the quality of his
work, especially in his other tasks (such as the DWN or package
maintenance, or whichever task I'm not even aware he's in charge of).
Joey stepping down as Stable RM is also a strong sign and I tend to
believe this is also what he wants it to be. Let's take it as a sign
that we must handle some things "better" (don't like this word: things
are not black or white, usually).
In real life, when a (mini-)crisis like this one occurs in normal
organizations, a good management action is to analyse the causes of
the crisis and try to correct the organization to avoid further such
crisis.
This is the challenge for Debian. We face a few crisis, which we need
to take as opportunities to improve the way we work. Our challenge is
doing so without a manager (that's probably what Martin Michlmayr is
calling for in his now quite famous "DPL as a strong leader" blog).
I don't read -project (and I don't intend tounless ${DEITY} slows
down earth rotation to make 28 hours days) but from Amaya's posts, it
seems to me that discussions are happening on -project about such
issues...which is Good.
signature.asc
Description: Digital signature
Debian Installer team monthly meeting minutes (20060304 meeting)
support by the udev package maintainer. Colin mentions a plan by Marco to make some bit of udev write out rules itself to remember the name of each device it sees. Then, D-I would only have to copy those to the installed system. Frans Pop proposes a dedicated meeting with the interested people and he will organize it. Flexible way to reorder menu items -- Several features require to either reorder menu items, or drop some of them: - network-console after loading extra components (#288053) - language-chooser after network-console - Apply last patch proposed to close bug #339855 or don't offer 'start a shell' in G-I (as it won't work) - using Etch d-i to install Sarge Dropping menu items can be done with the "isinstallable" feature. It is ack'ed that this can be the solution for the "use Etch d-i to install Sarge" item. Frans will work on sarge installs support as soon as possible (post-meeting comment: the work began immediately after the meeting!). Work done by Colin Watson for "kickseed" in Ubuntu may help in solving some of these issues. This work is recognized by Colin himself as "hacks" but could at least help working on cleaner solutions later. 2.6 floppies Given that abandoning 2.4 is wished by the kernel team, getting 2.6 floppies for x86 is a requisite. However, even 2.4 floppy builds currently fail in sid for x86 because of extra disk space required by the new glibc udeb. No immediate solution to recover space is currently popping up, so integrating 2.6 probably require we first solve this space issue and not only by allowing 2.4 floppies. Powerpc already uses 2.6 floppies by dropping out root from the boot floppy. Sylvain Ferriol had some success in 2.6 floppies builds, but with load_ramdisk and prompt_ramdisk with root floppy using cramfs. Sylvain will continue some work on that issue. Committing ideas and proposed changes in people/ in SVN is suggested. Changes in lowmem - Lowering the memory requirement of d-i has been the subject of many investigations by Sylvain Ferriol who had some successes in 16MB installs by hacking lowmem. Sylvain proposed changes some weeks ago, but these were judged a bit too invasive and reverted. Colin Watson suggests working to bring swap as early as possible, for instance before partman, in case the disk already has a swap partition that could be temporarily used. Frans mentions that lowmem is currently mostly a collection of hacks. Having a more structural solution to load some udebs only after partman would be better than only hacking lowmem. Suggestion here is summarizing ideas and propose them to the mailing list for discussion. g-i integration --- Since the last meeting, several blockers have been raised and, actually, the integration of Graphical Installer builds in the main build system is theoretically possible. Frans will resume work on the udeb lib dependency immediately after the release. As expected, there won't be any g-i release with beta2. The goal is having one with beta3. Another blocker is the line spacing issue in ttf-freefont (#254113). There is currently no sign that it can be solved as it seems to be puzzling even for the freefont upstream maintainer. The fonts in ttf-dejavu could be a good replacement for ttf-freefont in case the line spacing issue is a blocker. Thus, Davide Viti will try to check whether these DejaVu fonts cover enough glyph ranges. About freefont, the deal is either have a less complete font without line spacing problem (20051102-2) or a more complete one with the problem (20060126-1). This is only a matter of requesting ttf-freefont to enter testing. The ttf-freefont maintainer (Christian Perrier) still keeps an eye on that issue very closely. Graphical partitioner - The goal is having some tool that better fits in a graphical installer than partman. gparted could be OK for this but, being written in C++, it requires a C++ udeb, which is not supported by the glibc maintainers. As a consequence, Xavier Oswald began working on a C rewrite of gparted named gdisktool (http://oskar-box.hd.free.fr/debian/screenshots/gdisktool.jpg). Given the still early stage of this development, having it in the etch graphical installer is not very likely to happen (as the graphical installer is itself just stabilizing right now). However, Xavier is encouraged to build a tentative udeb so that unofficial images can be easily built and give gdisktool more exposure. The source code will soon be committed in gparted SVN. This graphical partitioner tool should also include a partimage utility which can be used to backup/restore partitions to disk or network. Netinst images needing network -- As a consequence of apt-setup integration to 1st stage, the current netinst image insist on configuring the network before furthe
Re: Debian Installer team monthly meeting minutes (20060304 meeting)
> g-i integration > --- > > Since the last meeting, several blockers have been raised and, > actually, the integration of Graphical Installer builds in the main > build system is theoretically possible. It seems that at least one person (hello, Lars) survived down to this part...which is pretty cryptic because of my famous Frenglish. Here please read "several blockers have disappeared"or, in short, there are no more blockers for building g-i in the regulard daily builds. signature.asc Description: Digital signature
Re: Debian Installer team monthly meeting minutes (20060304 meeting)
Quoting Marco d'Itri ([EMAIL PROTECTED]): > On Mar 11, Christian Perrier <[EMAIL PROTECTED]> wrote: > > > The idea of non-free installation images pops up but, later, there > > were comments that it would make the maintenance of D-I builds more > > complicated, and it is enough complicated already. Another argument > > is: as soon as non free images will be available, people will always > > use them. > And this would be bad because people who own hardware which uses > uploadable firmware must suffer, don't they? IIRC, the remark was from Joey and you may be missing context. Joey's intent was certainly not saying that people with such hardawre must suffer. I actually fail to see moments where Joey ever told such things. He was just pointing that such images would be seen by outsiders as "more complete" images to install Debian. Thus, one can expect that everyones would use themeven when not needing them. And so, these images would quickly become the only Debian installation media...while we do not completely support them. This has actually nothing to do with our own feelings about what is free and what isn't...or even our feelings about the exact place to draw the line (my own feelings are pretty liberal in that matter...read that I'm not a hardcore zealot for "more Free than Free"...while the feelings of other d-i team member are more strict). Hope this clears everything out and especially the "D-I team thinks that our users must suffer" thingie..:) signature.asc Description: Digital signature
Fonts packages maintenance team begins work
On the basis of the last proposal I made, I hereby declare the font packaging team opened to all volunteers. Up to now, I have added to the project, the following people who explicitely requested to do so (and provided me with an Alioth login): Mohammed Adnène Trojette Paul Wise Arne Götje Norbert Preining Mailing lists requests are pending (currently, one for discussion and one for future commits to the common repository). A SVN repository exists, but we will have to discuss together about the way we'll use it. People interested in joining can mail me their Alioth login. signature.asc Description: Digital signature
News from the pkg-fonts project
The Font packaging project is slowly progressing. After setting up an Alioth project and a SVN repository, we now have a mailing list on Alioth: http://lists.alioth.debian.org/mailman/listinfo/pkg-fonts-devel The point is now gathering the interested people in this mailing list and make the project more precise. This mail is BCC'ed to people who explicitely mentioned they want to be added to the Alioth project and which I've added to pkg-fonts. These people have been explicitely invited to subscribe to the list (but they're obviously free to not do so). All other people are of course interested and welcomed to join in and request to be added to the project. Just send me your Alioth logins. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Looking for a Korean native speaker for a few translation updates
Hello, fellow Debian developers and users, The Korean translation of Debian in general, and especially the Debian Installer, has been made up to now mostly by Changwoo Ryu, one of the few DD's in Korea. I'm however without news from him for several weeks now and we have, for D-I and "related" packages, a few translations which need updates. So, I'm seeking Korean speakers who could just one time look at a few translation files I may send them, and complete them. I will of course help people in case they're not familiar with translation tools and gettext stuff. As the work is quite small, I think this won't be a problem. I estimate the needed work to a few dozens of minutes, not more. Please contact me in private in case you can help. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
