Bug#595907: ITP: webhoneypot -- The Dshield Web Honeypot Project.
Package: wnpp Severity: wishlist Owner: Christian Pohl * Package name: webhoneypot Version : 0.1.123 Upstream Author : Johannes Ulrich * URL : http://sites.google.com/site/webhoneypotsite * License : GPLv2 Programming Lang: PHP Description : The Dshield Web Honeypot Project. -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100907080154.13339.56159.report...@aringill.pohlcity.local
Bug#1072515: general: Repeating cracking sound in headphones when nothing is playing.
Hi Hakan! Sure. I hope attaching the files to this mail works. On Tue, 4 Jun 2024 10:20:34 +0300 =?UTF-8?Q?Hakan_Bay=C4=B1nd=C4=B1r?= wrote: > Dear Christian, > > Can you please share the outputs "lspci -vvv" and "dmidecode" commands > (please run them as the root user) as text files? This will allow > anybody interested to see your hardware details, so pinpointing your > computer's details plus the hardware used for sound will be much easier. > > Cheers, > > H. > > On 3.06.2024 ÖS 6:09, Christian Böck wrote: > > On Mon, 3 Jun 2024 12:42:17 +0200 Andrius Merkys wrote: > > > Hi Christian, > > > > > > On 2024-06-03 11:38, Christian Böck wrote: > > > > when using headphones with my laptop (Thinkpad W550s) I get a > > repeating > > > > cracking (~1sec intervalls) when nothing is playing. > > > > > > I have a similar issue on a workstation with Ubuntu 22.04. What is your > > > operating system version? I believe the issue started manifesting once I > > > installed Jack. Do you have Jack on your machine? > > > > > > Andrius > > > > > > > > > > Hi Andrius! > > > > I'm running an up-to-date Debian 12 64Bit (bookworm) and I don't have > > Jack installed. > > After some messing with duckduckgo the problem seems to be, that the > > system puts the audio-chip to sleep, but not the headphone-amplifier. > > I hope someone from Debian can fix it. > Getting SMBIOS data from sysfs. SMBIOS 2.7 present. 66 structures occupying 3194 bytes. Table at 0xACBFD000. Handle 0x, DMI type 222, 14 bytes OEM-specific Type Header and Data: DE 0E 00 00 01 99 00 03 10 01 20 02 30 03 Strings: Memory Init Complete End of DXE Phase BIOS Boot Complete Handle 0x0001, DMI type 14, 8 bytes Group Associations Name: Intel(R) Silicon View Technology Items: 1 0x (OEM-specific) Handle 0x0002, DMI type 134, 13 bytes OEM-specific Type Header and Data: 86 0D 02 00 02 04 15 20 00 00 00 00 00 Handle 0x0003, DMI type 7, 19 bytes Cache Information Socket Designation: L1 Cache Configuration: Enabled, Not Socketed, Level 1 Operational Mode: Write Back Location: Internal Installed Size: 32 kB Maximum Size: 32 kB Supported SRAM Types: Synchronous Installed SRAM Type: Synchronous Speed: Unknown Error Correction Type: Parity System Type: Data Associativity: 8-way Set-associative Handle 0x0004, DMI type 4, 42 bytes Processor Information Socket Designation: U3E1 Type: Central Processor Family: Core i7 Manufacturer: Intel(R) Corporation ID: D4 06 03 00 FF FB EB BF Signature: Type 0, Family 6, Model 61, Stepping 4 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) SS (Self-snoop) HTT (Multi-threading) TM (Thermal monitor supported) PBE (Pending break enabled) Version: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz Voltage: 1.0 V External Clock: 100 MHz Max Speed: 3000 MHz Current Speed: 2400 MHz Status: Populated, Enabled Upgrade: Socket BGA1168 L1 Cache Handle: 0x0005 L2 Cache Handle: 0x0006 L3 Cache Handle: 0x0007 Serial Number: None Asset Tag: None Part Number: None Core Count: 2 Core Enabled: 2 Thread Count: 4 Characteristics: 64-bit capable Multi-Core Hardware Thread
Re: Reviving schroot as used by sbuild
On 2024-06-25 15:02, Simon McVittie wrote: > Could we use a container framework that is also used outside the Debian > bubble, rather than writing our own from first principles every time, and > ending up with a single-maintainer project being load-bearing for Debian > *again*? I had hoped that after sbuild's history with schroot becoming > unmaintained, and then being revived by a maintainer-of-last-resort who > is one of the same few people who are critical-path for various other > important things, we would recognise that as an anti-pattern that we > should avoid if we can. This 100%. The effort put into this is obviously appreciated, but the risks mentioned above ring too true. > At the moment, rootless Podman would seem like the obvious choice. As far > as I'm aware, it has the same user namespaces requirements as the unshare > backends in mmdebstrap, autopkgtest and schroot (user namespaces enabled, > setuid newuidmap, 65536 uids in /etc/subuid, 65536 gids in /etc/subgid). As a datapoint, I use rootless podman containers extensively both for autopkgtest and as an sbuild backend (though the latter is affected by #1033352 for which I still need to implement a cleaner workaround). I think the only problem I encountered was a corner case when passing in a device into a container: at some point, autopkgtest runs su which uses the setgroups() syscall, and group permissions get lost. The solution was to setup up the proper gidmaps. I documented my findings here [1]. Though this latter issue shouldn't be a problem on buildds, where devices aren't passed in. Best, Christian [1]: https://salsa.debian.org/rocm-team/community/team-project/-/blob/master/doc/rocm-autopkgtests-in-containers.md?ref_type=heads
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. --
Looking for co-maintainers for MySQL and Quaga
Hello I'm looking for a co-maintainer for my MySQL and Quagga packages. Any volunteers? :-) bye, -christian- pgpD6y7qSVqF0.pgp Description: PGP signature
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é")
Added a section to your wiki
Hallo Joey, I added the section ReleaseAsSubsystemChoice to your wiki (http://wiki.debian.net/index.cgi?ReleaseProposals). I wasn't sure whether it should be included into ReleasePerSubsystem or not. I made it separate so you can delete it easier if you think it is complete nonsense. For questions please cc to me. I am not subscribed to debian-devel. Christian
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. --
Re: Bug#285625: ITP: expocity -- An enanced Window Manager based on metacity
> == > Date: Tue, 14 Dec 2004 16:33:43 +0100 > From: martin f krafft <[EMAIL PROTECTED]> > To: debian-devel@lists.debian.org > Subject: Re: Bug#285625: ITP: expocity -- An enanced Window Manager > based on metacity > == > > enlighten us non-Darwinists: what does Exposé do? How does this > differ from tabs as provided e.g. by fluxbox. http://www.apple.com/macosx/features/expose/ bye Christian
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.
New author/maintainer for pinfo needed
Hi, I've so far maintained the package pinfo, an alternative info-file viewer. The last release has been some time ago and there are also some open bug reports. I've talked with the author about the package and he decided that he has no longer time to work on this package. Therefor the program needs a new author to be viable in the future. Ideally the new author is also a debian developer or in the new maintainer queue and would take the package over. If nobody is interested in becoming the author of pinfo, I'm going to orphan the package in a week. Christian -- Debian Developer (http://www.debian.org) 1024D/B7CEC7E8 44BD 1F9E A997 3BE2 A44F 96A4 1C98 EEF3 B7CE C7E8 pgphZQOcX31R1.pgp Description: PGP signature
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]
Re: Bug#291945: eleventh-hour transition for mysql-using packages related to apache
Hello On 2005-02-11 sean finney wrote: > On Fri, Feb 11, 2005 at 10:15:55AM +0100, Francesco P. Lovergine wrote: > > FYI: new mysql FLOSS includes OpenSSL license, so many packages could > > migrate to current libmysqlclient starting from no starting from now.. > > that's great to hear! i'm cc'ing the relevant wishlist bug i have open > against mysql-server. christian: any chance of getting an openssl enabled > version of the mysql-client and mysql-server packages? Yes, I will re-enable openssl in the next upload. bye, -christian- -- 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]
Bug#295311: RFH: mysql-dfsg -- mysql database client library
Package: wnpp Severity: normal I request assistance with maintaining the mysql-dfsg package. The package description is: MySQL is a fast, stable and true multi-user, multi-threaded SQL database server. SQL (Structured Query Language) is the most popular database query language in the world. The main goals of MySQL are speed, robustness and ease of use. The generated binaries are mysql-server, mysql-client, mysql-common, libmysqlclient12 and libmysqlclient12-dev. There is also a set of packages from the mysql-dfsg-4.1 for the next version branch that I do also maintain (and look for help for). The packages are currently quite stable and matured but never the less have quite complex scripts and it's a widely used package which should not be left alone when I'm on holidays or ill. Also there are licensing issues every couple of month with which you can tease the always helpful MySQL employees... *evilgrin* Although I'm happy for anybody who helps a but, I'm looking specifically for an official Debian Developer as a Co-Maintainer who is able to upload packages. bye, -christian- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295312: RFH: mysql-dfsg-4.1 -- mysql database client library
Package: wnpp Severity: normal I request assistance with maintaining the mysql-dfsg-4.1 package. The package description is: MySQL is a fast, stable and true multi-user, multi-threaded SQL database server. SQL (Structured Query Language) is the most popular database query language in the world. The main goals of MySQL are speed, robustness and ease of use. . This package includes the client library. The generated binaries are mysql-server-4.1, mysql-client-4.1, mysql-common-4,1, libmysqlclient14 and libmysqlclient14-dev. There is also a set of packages from the mysql-dfsg (4.0 branch) for the last version branch that I do also maintain (and look for help for). The packages are currently quite stable and matured but never the less have quite complex scripts and it's a widely used package which should not be left alone when I'm on holidays or ill. Also there are licensing issues every couple of month with which you can tease the always helpful MySQL employees... *evilgrin* Although I'm happy for anybody who helps a but, I'm looking specifically for an official Debian Developer as a Co-Maintainer who is able to upload packages. bye, -christian- ~ ~ -- 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]
Bug#298461: ITP: cyboi -- The Cybernetics Oriented Interpreter (CYBOI) is needed to execute applications defined in the XML-based Cybernetics Oriented Language (CYBOL).
Package: wnpp Severity: wishlist Owner: Christian Heller <[EMAIL PROTECTED]> * Package name: cyboi Version : 0.4.0.0 Upstream Author : Dennis Reichenbach <[EMAIL PROTECTED]> * URL : http://www.cybop.net/ http://www.cybop.org/ * http://developer.berlios.de/projects/cybop/ * License : (GPL) Description : The Cybernetics Oriented Interpreter (CYBOI) is needed to execute applications defined in the XML-based Cybernetics Oriented Language (CYBOL). Both are part of the Cybernetics Oriented Programming (CYBOP) project which provides a new theory to creating software systems. CYBOP aims at enabling domain experts (medicine, insurance, banking, transport etc.) who have no idea about programming, to create their own knowledge models to better be able to contribute to software development. Furthermore, CYBOP wants to eliminate the many inter-dependencies of classical software systems and the need to repeatedly apply the same software patterns, by separating application knowledge from more hardware-close system control. This all is somewhat comparable to XAML in WinFX (Windows Longhorn), only that it will be much better from a knowledge-modelling point of view, closer to nature and to the principles of human thinking ;-) It will allow to define not only GUIs, but complete applications in pure XML. See the latest paper on our website for more information! -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.24 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- 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: Do not make gratuitous source uploads just to provoke the buildds!
Hello Wouter On 2005-03-16 Wouter Verhelst wrote: > That's not to say that a request to prioritize a package is to be > ignored; however, the power of deciding which packages get built first > should be with those that actually build the packages, rather than with > those who want their packages to be built. The former are expected to be > following the larger picture; the latter are not. Given that the only really relevant thing is when the package enters testing, which already can be changed by the maintainers, the only thing a maintainer can wish is to have his package build within the 2 or 5 days, or? As only 2 days might be a problem, wouldn't just prefering high+security uploads be enough to make everybody happy without disrupting the buildd order too much? friendly, -christian- -- 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: State of gcc 2.95 use in Debian unstable
On Tue, 15 Nov 2005, Thiemo Seufer wrote: > while preparing an upload of gcc-2.95 which fixes its worst problems > I wondered how many users of it are actually left. 9 packages in > unstable still declare a build dependency on gcc-2.95 or g++-2.95, > this makes it IMHO a plausible release goal to get rid of 2.95 > maintenance for etch. I guess it is not a good idea as long as Linus still has the line " - Make sure you have gcc 2.95.3 available" in his README in the kernel source tree. Best wishes, -- Christian Fromme Mail: kaner at strace.org GPG: 9DE5E8B9 "If you seek the kernel, then you must break the shell." (Meister Eckhart) -- 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: switching to vim-tiny for standard vi?
On 20.12. 08:36, Steve Greenland wrote: > I'm still missing the incentive. Joey Hess wrote in his earlier message > that "It's now only marginally larger than nvi". It achieves that by > removing many of the features that distinguish vim from nvi, to the > point that my guess is that most of those who prefer vim will need to > install the full vim anyway, while those that prefer nvi will just fell > vaguely dissastified by the change. If the result of this is that a) > base is not smaller, and b) vim users still have to install vim-nottiny, > and c) nvi users now have to install nvi, I don't think it's a net win. As much as I personally prefer vim, I feel your arguments a) b) and c) are the strongest I've read so far in this thread and therefore I also have to agree on the conclusion: Keep nvi as default. Cheers, Christian -- 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]
Re: Bug#345160: ITP: libgpod -- a library to read and write songs and artwork to an iPod
Felipe Sateler <[EMAIL PROTECTED]> writes: > There is already a libgpod0 package on Christian Marillat's archive, so I > guess there must be an issue regarding this package's relation with debian. No issues for this package. I simply did these packages because this is more fast to me, instead of waiting for an official package. Nice to play with artworks and videos :) Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345160: ITP: libgpod -- a library to read and write songs and artwork to an iPod
Mike Hommey <[EMAIL PROTECTED]> writes: > On Fri, Dec 30, 2005 at 10:54:25AM +0100, Christian Marillat <[EMAIL > PROTECTED]> wrote: [...] >> No issues for this package. I simply did these packages because this is >> more fast to me, instead of waiting for an official package. Nice to play >> with artworks and videos :) > > Something troubles me. You make unofficial packages while waiting for official > packages. Aren't you DD ? Wouldn't uploading these unofficial packages > in unstable make them official ? ligpod should be packaged by the gtkpod maintainer because for now only gtkpod use this library. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345160: ITP: libgpod -- a library to read and write songs and artwork to an iPod
Josselin Mouette <[EMAIL PROTECTED]> writes: > Le vendredi 30 décembre 2005 à 17:55 +0100, Mike Hommey a écrit : >> Something troubles me. You make unofficial packages while waiting for >> official >> packages. Aren't you DD ? Wouldn't uploading these unofficial packages >> in unstable make them official ? > > I don't think we need more packages maintained by Christian Marillat. Same apply for you... Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345160: ITP: libgpod -- a library to read and write songs and artwork to an iPod
Josselin Mouette <[EMAIL PROTECTED]> writes: > Le vendredi 30 décembre 2005 à 17:55 +0100, Mike Hommey a écrit : >> Something troubles me. You make unofficial packages while waiting for >> official >> packages. Aren't you DD ? Wouldn't uploading these unofficial packages >> in unstable make them official ? > > I don't think we need more packages maintained by Christian Marillat. Moron are still here in 2006. Happy new year... christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Sun, Dec 18, 2005 at 08:31:26PM +0100, Florian Weimer wrote: > > Afaict from the webpage 7zip (LZMA) is quite a bit slower bzip2. - > > Have you perhaps run some benchmarks? > Memory use during decompression would be interesting, too. For pure lzma it isn't really bad, it's about 100kb + directory_size and this is usually 8 MB (that is a sane value), but smaller directory sizes may be used as well. Some data discussion, also for the speed issue: (user time only) compression of libgcj6 (17612800 uncompressed), the first file i found that is big enough for usefull data gzip- 7.5 sec - 5118403 bzip2 - 16.9 sec - 5039522 lzma 8MB (-a2) - 53.8 sec - 3643734 lzma 2MB (-a2) - 50.3 sec - 3648493 lzma 1MB (-a2) - 48.1 sec - 3675183 lzma 1MB (-a1) - 41.1 sec - 3707349 lzma 1MB (-a0) - 23.5 sec - 3985219 lzma 512k(-a0) - 22.6 sec - 3994574 lzma 2MB (-a0) - 26.5 sec - 3979074 decompression: Memory usage about gzip - 0.2 sec - no idea, but few bzip2- 3.2 sec - 3700 kb lzma 8MB - 0.8 sec - 8200 kb lzma 2MB - 0.8 sec - 2150 kb lzma 1MB - 0.8 sec - 1120 kb lzma 512k- 0.8 sec - 620 kb In the end adding lzma to dpkg can't harm, it's just a small patch and has no external requierements, code size just grows like 12 kb or something. Cheers, Christian -- "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." (Aurelius Augustinus) Translation: <http://gnuhh.org/work/fsf-europe/augustinus.html> -- 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]
Re: new mplayer 1.0pre7try2 package
Nathanael Nerode <[EMAIL PROTECTED]> writes: > aj@azure.humbug.org.au: [...] > Contrast rte, where the ftpmasters told Marillat exactly what he needed to > remove to get the package in Debian, and he didn't do it, and declared that > he would keep uploading it. Leaving *that* in limbo is totally reasonable. I've *never* received any e-mail saying that. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer 1.0pre7try2 package
Joerg Jaspert <[EMAIL PROTECTED]> writes: > On 10540 March 1977, Christian Marillat wrote: > >>> Contrast rte, where the ftpmasters told Marillat exactly what he needed to >>> remove to get the package in Debian, and he didn't do it, and declared that >>> he would keep uploading it. Leaving *that* in limbo is totally reasonable. >> I've *never* received any e-mail saying that. > > Right, you've got a list of reasons why it got rejected and half > of that is still true. I still don't see why rte can't enter in main, when ffmpeg is already in main and does the same. For the record rte is an mpeg encoder. Now from the ffmpeg package 0.cvs20050918-5.1 I see : , | $ ffmpeg -formats | grep -i mpeg | ffmpeg version CVS, build 3276800, Copyright (c) 2000-2004 Fabrice Bellard | configuration: --build i486-linux-gnu --enable-gpl --enable-pp --enable-zlib --enable-vorbis --enable-libogg --enable-theora --enable-a52 --enable-dts --enable-dc1394 --enable-libgsm --disable-debug --prefix=/usr | built on Jan 17 2006 23:46:35, gcc: 4.0.3 20060115 (prerelease) (Debian 4.0.2-7) | E dvd MPEG2 PS format (DVD VOB) | DE m4v raw MPEG4 video format | D mov,mp4,m4a,3gp,3g2 QuickTime/MPEG4 format | E mp2 MPEG audio layer 2 | D mp3 MPEG audio | DE mpegMPEG1 System format | E mpeg1video MPEG video | E mpeg2video MPEG2 video | DE mpegts MPEG2 transport stream format | D mpegvideo MPEG video | E svcdMPEG2 PS format (VOB) | E vcd MPEG1 System format (VCD) | E vob MPEG2 PS format (VOB) | DE yuv4mpegpipeYUV4MPEG pipe format | DEVSDT mpeg1video | DEVSDT mpeg2video | DEVSDT mpeg4 | D VSDT mpegvideo | DEVSD msmpeg4 | DEVSD msmpeg4v1 | DEVSD msmpeg4v2 ` D is for Decoding and E is for Encoding, so ffmpeg can encode in mpeg1video and mpeg2video. Christian -- 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 an
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]
