Re: Stuff the installer does which isn't done on upgrade....
On Thursday 03 August 2006 06:24, Nathanael Nerode wrote: So upgraded systems don't get the benefits of certain changes to the installer's defaults, or defaults in programs used by the installer. http://wiki.debian.org/Sarge2EtchUpgrade Anyobdy (Marco d'Itri?) can add some comments regarding the udev/dbus/hal (.../pcmcia-cs/hotplug/usbwhatever/...) situation to that page? Or does the normal upgrade from a default sarge installation (2.4 based!) to a default etch installation provide everything already through dependencies? cheers -- vbi -- Jesus is my duct tape. -- Robert Lindsay on alt.religion.kibology pgpEAJmSNA4VG.pgp Description: PGP signature
Re: Urgent
On Friday 28 January 2005 15.49, Steve Greenland wrote: On 28-Jan-05, 04:30 (CST), Francois Bottin [EMAIL PROTECTED] wrote: For those not speaking french, this is a nigerian scam... The first I have ever received in this language, albeit very poorly written. That's sad, because the English ones are the epitomy of prose styling, not to mention a model of correct grammar and spelling. YOU FORGOT TO MENTION THAT THEY OFTEN AT LEAST GET THE RULE ABOUT CAPITALIZING NAMES ETC. AND THE FIRST LETTER OF EVERY SENTENCE RIGHT. -- VBI -- Press any key to continue or any other key to quit... pgpgtzMdTbF4s.pgp Description: PGP signature
Re: shell script sniplets in /usr/bin?
On Saturday 29 January 2005 18.28, Frank Küster wrote:
Santiago Vila [EMAIL PROTECTED] schrieb:
On Sat, 29 Jan 2005, sean finney wrote:
why not do something like this in
any script that uses gettext:
#!/bin/sh
PATH=${PATH}:/usr/share/gettext/scripts
. gettext.sh
Because we already have /usr/bin for that and there is no need to
change every script that uses gettext.
You wouldn't need to change every script - you just need to move
gettext.sh to /usr/share/gettext/scripts and create /usr/bin/gettext.sh
with the content Sean suggested.
Which buys us what?
This new gettext.sh would still be a non-executable script snippet which is
not intended to be called by the user directly, as far as I can understand.
-- vbi
--
featured link: http://fortytwo.ch/gpg/subkeys
pgp2B4fyYnmnv.pgp
Description: PGP signature
Re: Free Beer: Need packaging assistance...
On Wednesday 06 July 2005 23.15, Mikael Olenfalk wrote: So if there is a DD living in Stockholm, Sweden; I'm would be pleased to pay for dinner+beer (or equivalent) for a laptop-packaging-session Debian is about free speech, not free beer, so you can have that cheaper: just allow the DD to talk to you for the whole evening/afternoon. (Ok, I'll shut up again now. Sorry for not contributing anything helpful.) -- vbi -- pgp4ykiPIpoHR.pgp Description: PGP signature
Re: How to recognise different ETCH wishlists from quite a long way away (revised)
On Friday 08 July 2005 14.33, Javier Fernández-Sanguino Peña wrote: TODO: Should this be in http://wiki.debian.net/index.cgi?ReleaseProposals ? It's http://wiki.debian.net/?EtchTODOList - which contains a short disclaimer on its difference vs. ReleaseProposals. Manoj: Mere wishlists by random bystanders are no help to anyone. I think I can agree with your sentiment that they don't get things done. OTOH I feel it worthwhile to collect these ideas on what people are missing in Debian - it does help people to find other people with interests in similar areas, and I'd argue that the list does no harm. If you don't feel it is helpful to you, just ignore it. regards -- vbi -- Bescheidenheit ist so beliebt, weil sie einem die Arroganz erleichtert. pgpWK31VqwWEo.pgp Description: PGP signature
Re: How to recognise different ETCH wishlists from quite a long way away (revised)
On Saturday 09 July 2005 00.39, Steve Langasek wrote: On Fri, Jul 08, 2005 at 03:49:36PM +0200, Santiago Vila wrote: IMHO, we should keep dummy packages around for at least two releases, to support upgrades which skip one release. In practice, upgrades that skip a release are not supported. There was no way at all that upgrades from potato-sarge could have been supported, and it's not a goal of the release team to support direct upgrades from woody-etch. While it is only sensible to state in bold, big, fat, huge letters that upgrades over two releases are not supported, breakting these on purpose does nobody any good when keeping this minor support in doesn't cost more than 4k on the mirror network. cheers -- vbi -- Beware of the FUD - know your enemies. This week * Patent Law, and how it is currently abused. * http://fortytwo.ch/opinion pgpV5pYml0g0H.pgp Description: PGP signature
Re: GCC version change / C++ ABI change
On Monday 04 July 2005 11.51, Horms wrote: I am not sure about 3.4's ability to compile 2.4.27, but it seems unlikely to me that all of the gcc versions you mention above will be omitted from etch. I'm quite confident that the release team and/or gcc maintainers will agree that 'is needed to compile 2.4 kernels' is a big enough reason to keep some gcc version around if Debian gets to the point to decide which old gcc versions should be shipped or dropped. cheers -- vbi -- featured link: http://fortytwo.ch/gpg/subkeys pgpnSHnGznqSt.pgp Description: PGP signature
Re: How to recognise different ETCH wishlists from quite a long way away (revised)
On Monday 11 July 2005 09.59, Javier Fernández-Sanguino Peña wrote: On Sat, Jul 09, 2005 at 08:25:11AM -0500, Manoj Srivastava wrote: This is a huge list, with probably 0 chances of getting accomplished. How about this: remove every single item from the list, and only add items when there are people who sign up to be responsible for the work involved in actually seeing that item come to fruition? Errr.. the wishlists with names within brackets are those that have been taken over by somebody, the ones that don't are up for grabs. Except that it isn't true, exactly. At least in my case - the issue I suggested is exactly one of the cases that annoys Manoj so much. cheers -- vbi -- Oh, mi hai uccisa! -- Dal film Quintet pgppFGKgKSmdJ.pgp Description: PGP signature
Hosting for Debian machine
On Thursday 07 July 2005 14.13, martin f krafft wrote: If you can help the Debian Project out in this area, we would `appreciate it`_. Please contact the Debian host system administration team at [EMAIL PROTECTED], and feel free to contact me at [EMAIL PROTECTED] as well. The ETH Zurich agreed to host one machine. I have sent email to debian-admin on 27 June, followed by a reminder on 6 July. I have not heard anything from them. The people at ETH are wondering what's going on... Any news on that? (I'm not involved, but as a ETH alumni, I'm obviously curious. And I just wondered if you - Branden - know about this already since madduck didn't cc his email to you.) cheers -- vbi pgpmCZAT5Hplp.pgp Description: PGP signature
Re: Free Beer: Need packaging assistance...
On Tuesday 12 July 2005 11.51, Mikael Olenfalk wrote: it was not my intention to state that Debian is about free beer Sorry - you misunderstood me. I tried to make a (bad) joke, nothing more. greetings -- vbi -- featured link: http://fortytwo.ch/smtp pgpXlfH0UtbyY.pgp Description: PGP signature
Re: GCC version change / C++ ABI change
On Monday 11 July 2005 22.18, Roger Leigh wrote: Adrian von Bidder [EMAIL PROTECTED] writes: On Monday 04 July 2005 11.51, Horms wrote: I am not sure about 3.4's ability to compile 2.4.27, but it seems unlikely to me that all of the gcc versions you mention above will be omitted from etch. I'm quite confident that the release team and/or gcc maintainers will agree that 'is needed to compile 2.4 kernels' is a big enough reason to keep some gcc version around if Debian gets to the point to decide which old gcc versions should be shipped or dropped. We even have GCC 2.7.2 in unstable (gcc272). Does anyone actually use this anymore, or could it be removed for etch? Some embedded people who still use Linux 2.0 + uclinux? Not sure at all, but that's what we used not that long ago (around 2000;2.4 was long out then, so 2.0 was already ancient. Ok, it is a bit long ago, but still...) greetings -- vbi -- Die Veränderlichkeit der Naturkonstanten scheint eine Idee zu sein, deren Zeit gekommen ist. Nur die Natur ist noch nicht so weit. -- Max Rauner, Neue Zürcher Zeitung, 21.4.2004 pgp2oOGL8UdU8.pgp Description: PGP signature
Re: is it a bug to not depend on a library package needed for some binary?
On Sunday 17 July 2005 10.14, Karl Chen wrote: Suppose package P contains files /usr/bin/B1 and /usr/bin/B2. B1 is the important program, and B2 is not as important. Is it OK for the declared package dependencies to not satisfy all the run-time shared library dependencies of B2? What if they are listed in Suggests? I have found many such packages. This is what Recommends: is for. I'd say a Suggests: is too weak (except if the helper program B2 is really, really unimportant - perhaps it should not be installed, or just put to /usr/share/doc/contrib or so? But as soon as B2 is something that actually is used by many people, a hard dependency would make sense. And, of course, for not-so-small B2, Goswin's suggestion to split it out into its own package makes sense, too. cheers -- vbi -- Today is Boomtime, the 56th day of Confusion in the YOLD 3171 pgpzjgiQHqyrp.pgp Description: PGP signature
Re: Removal of transitional dummy packages
On Sunday 17 July 2005 23.28, Joerg Jaspert wrote: On 10353 March 1977, Santiago Vila wrote: we need to remove from the archive all the Woody-to-Sarge transition dummy packages. No, that's not true, we don't *need* to remove woody-to-sarge dummy packages, as they are also woody-to-etch dummy packages. We do not support that. No. So yes, woody-sarge packages should be removed, there is no reason to keep them. Upgrades from woody go via sarge and then to etch. Support and test woody - etch upgrades? No. Knowingly (and on purpose) break woody - etch upgrades where keeping the support is as cheap as keeping a simple arch:all dummy package? I vote no. (Based on a recollection that potato - sarge transitions worked reasonably, with a little hand holding, quite a long time into sarge's testing cycle.) No, I don't think dummy packages should be kept around forever, traces of potato-etch support, IMHO, is certainly not anything worth to keep. cheers -- vbi -- this email is protected by a digital signature: http://fortytwo.ch/gpg pgpkot62CxlH5.pgp Description: PGP signature
Re: Mass-filing bugs based on piuparts?
On Thursday 21 July 2005 14.41, Lars Wirzenius wrote: [piuparts] Go ahead - if you, as you say, investigate the bugs manually, it doesn't matter how you discovered the bug. Just curious: what kind of bugs can piuparts help discover? cheers -- vbi -- The jig's up, Elman. Which jig? -- Jeff Elman pgpYpSaumNCys.pgp Description: PGP signature
Re: Please confirm (conf#1ce969f7398dbe523f2f81436bb3412d)
On Thursday 21 July 2005 20.32, Kirk Reiser wrote:
IMPORTANT INFORMATION!
This is an automated message.
The message you sent (attached below) requires confirmation
before it can be delivered. To confirm that you sent the
message below, just hit the Reply button and send this
message back (you don't need to edit anything). Once this is
done, no more confirmations will be necessary.
INFORMAÇÃO IMPORTANTE
Esta é uma mensagem automática
A mensagem que você enviou (em anexo) requer confirmação
antes de ser entregue. Para confirmar o envio basta
pressionar o botão de Reply e enviar esta mensagem de
volta (não é necessário editar). Uma vez que isto seja
feito, novas confirmações não serão necessárias.
This email account is protected by:
Active Spam Killer (ASK) V2.5.0 - (C) 2001-2002 by Marco Paganini
For more information visit http://www.paganini.net/ask
--- Original Message Follows ---
From: debian-devel@lists.debian.org
To: [EMAIL PROTECTED]
Subject: omuxucutbpmajzge
Date: Thu, 21 Jul 2005 13:35:29 -0500
This is a multi-part message in MIME format.
--=_NextPart_000_0011_3B59FAAF.40318ED4
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: 7bit
RÐG8Ëaù¿Ú\{h/nJ#àÇ º
/³W°eóØ¢KÙ#Ò;êbHG
ÑWB®ZètìÜ`cmosW-R¦Üðt¼B
:ÞsæhðFêÚ|
~´|Òõ(lÔi]׺¬[UÐÕÇÐBbß«ïCC×ÔGÞi#ú¿à/üq
tîÅn/Ú9à/gWî5åºßÊpÐåÆ8xLk9-ÄNuÁZðnéÜcOÚLµR¶-3p{bíÃîåDn]
1Sn8YEee1°.HÒ ýàViЧ¥eò½»ûw¯ÞK®^DSNÁ¡ûÑÚMôþ1-3¡å[¨ÎæÂÃRöt#(Ó¬z.I»
Á¥
×ù].
Î#fÐû¦äiRÐñòC`ßJÄÁfzÅg,8
¶rE®ÌÚ%`|ù?(è
3lJÅùþzHkAxXNUúÛåõtÚ9Fu Û
[ÓQÓyElµAyé¢gLÅ/»Ëò8[廾ãZÓ#ö¥EDvS
±/cÐÏ
æz¿BÁîHë`%iWh?o2O7}!þø;%OTJNÖ#3Ëï¹gÄ©¯ÑÕ·õ0UQ¡UBÁg¯*»}0?ø£·Xý
±«Õ)pDJ!ÓиXYÁî.öOäu^ñöF!Z¨[hQ»ßÎïßà[®Á*0Â.ìgY£íP$$©-%cÙé¾[¢wmæ
,H¨ÌþNå2;/Sµ²ôcZ P©J»hÊÁ¼£ú}pM
ªxÞ/ÈZzØ úEpÁyíHWSÍLvÞIÃÇÙræ¯2¦ºza-Xß½9JÑZªÉ^N«CÀ[ÛIô×ùÖÎe:9
`ܤçý³.¾KPy^õ®Xøê²
à¬LCÍØLH §7Ź6ézpO%Í8ËÐ9Vô/Æ8ظ$siÍ%[óë²á[cBaâ±Ãv0ÁÉÝXo¶
v´ EªÕÇȾE
°8_DÌ°þÖ}JÈT÷NMAj}]Ø ó¢t¢ïéá´H³ç
;;ì3¯Ò¤Åg
ZîÀo¦¶×}s7'þ¢U{¸§Å¥$ÓÕÂWÆûï4ÓÒ½Q¢9Ëü¸ÒO¡-_S¥¨MÖlåü¸BW%æÞì è|
m¸ûéä° )¢2}¾ÈÚòJ]¨-\ÉqjûMwè'kHòDä¢ý¤-Z
Âì4¾ýwKDI[«Ø4ÉÀc^Ò6#pOQu§ghh4
eA EIøÃ]ÏvdFäûwr}B±¯
^#TX.^©ÃpàJ«R-ñ%0Ìef¢9ÓÌ2ä)XBk¶~zF/¼ùN.¹3AQh kô~ÄÂÊøWÁG
ìâîtæ#ÈyÒvßÖ½ÀWéêTñøFèùï^·s
?äÇëíVmmn6
ø$ì¢ÞlH¯Ñr^YõÔ`ø5Ë.Uef.C/®àp4C¨5´©Ém,t¼Wí£kJ9 Ò?kÙñh¿Ìh¶°ÆÛðƪĿ·g
©¼ðþV Ò箺Àò`ÌN
Üòcûvª/½¼3Jæ6Ô5ìç,;ùí~Põ¿£øiÏÙ¶{:Øf
Яû?v9ÊulÔÅ6S,Îü¾}ÆáI»ÀÙq VܤH¦¾hý;£s
8¶±fX.÷¤zUÅë»6ÌÊ0BÀYÉìöOÐ5/BôñúAÝÒjßç õHÕPãÉdþ;hµ{©sÆ¡¨XüGCÏ(S.Q
ìöZ%ð¬â½Ä.ûL;ÝRgêû'h´òmò7îvù!s}âR
-[.¿§æÖNá0ɪ¦Q}(f.ïå?s7ô÷hÄóvf
-ÁòjY±²Ú-à?ô.^ýP¹c¼Û`]§]Å×AUÃó·~N2i8*(ç{ëd
2¦XÜC%ö)[áïè:»{c7Cuvî_¡SòÅSd$dy
°bDˤ²µ]æV9¦u£¥SnÙ8²2O¸hצ[X5Ì°dìTÉ2¨þ NLr}fXoîBóÇ^Væ§ã
ïÆóC9\iÒìeiÉÝFçQèûàªÔ(h¤Nsûc5ÌàÈD³Ù÷w* »¼ìg[BÛëé(1iÑ)îj6Ýø
ª^Î^:Û¨ô:]w°âÍ,ý7ÓP¾`®]S¹ÂµQuê8B®«×I«ÝH¡
ÙÅù}.²÷¿än1ÑݤOÐOýqû`·sÞIu.ÄG´uÙ{¯d$i×I¦
iMò4ÔvÈùŽ
}ö'¸çÔ9Ïñ8,8kîvº0õô$?þ©Ëa*'Ø8sÊ3USQø#WÙæ̧ûàÎÕS±©'ÂZgú}°
½kÞxr¨Þ#1¹a¥t4Y(msûî¹jjÐ]øÂ]ê;zßtÕöÌ°]'Fé8Þ,8Ã|õh
æÔø$¼m±jÈ®µ0â
ýA¬³UÝ ¶ToÚÉ
i®LW
Þ_3Óitn1a0Ng
*ST{#ÅÊ:ÚZIçîúIHÎ÷ôSÂHúq1m1üDûuèØõè4CêhÔÚ³q¨LXØi¿r6ð;`Ò¤©kGhöm
Í ÇÁ¼F¨R³a`º
ÊãBe:Ïbý?~©N宩Hì g#ü:i¨«q
(Original message truncated)
--
All wiyht. Rho sritched mg kegtops awound?
pgpgLJeooaWVe.pgp
Description: PGP signature
Re: mass bug filing on packages that are blocking use of cdebconf
On Wednesday 03 August 2005 00.46, Joey Hess wrote: [debconf dance] Adrian von Bidder [EMAIL PROTECTED] postgrey tags +pending (fixed in svn) I hear a new upstream version is in the works, so I'll wait a week or two before uploading. cheers -- vbi -- featured product: SpamAssassin - http://spamassassin.org pgpNqPg2Ppqrz.pgp Description: PGP signature
Re: Please notify your rdepends' maintainers if you break an interface
On Sunday 14 August 2005 02.40, Robert Collins wrote: On a related note, should we consider defining a convention similar to soname for dynamic languages like perl/python etc? I.e. for a python library 'foo', install the code as 'foo1', and have a dummy package 'foo' which has a __init__.py containing 'from foo1 import *' ? While something like this might be a good idea, I feel that Debian shouldn't go ahead on this - better if such things were addressed as conventions upstream. cheers -- vbi -- Today is Sweetmorn, the 7th day of Bureaucracy in the YOLD 3171 pgpcIjVq9fr5A.pgp Description: PGP signature
Re: Using buildds only (was: Results of the meeting...)
On Monday 22 August 2005 16.08, W. Borgert wrote: [...] This is a really nice idea: A DD with a strange sense of humour could [...] If we're starting to worry about what kind of damage a DD can do to the world by providing some bogus uploads, let's just not. Any DD can cause code to be executed as root on a potentially very big number of machines world wide, source-only uploads or not, and there are many ways to obfuscate malicious code within a big, complex application. No technical measures will ever help here, really [1]. That's why we have NM and don't maintain the source code of your packages in Wiki-style... cheers -- vbi [1] granted, *if ever* somebody tried something, technical measures can make forensics and tracking the offender harder or easier. -- Beware of the FUD - know your enemies. This week * Patent Law, and how it is currently abused. * http://fortytwo.ch/opinion pgpSTdekHt4X0.pgp Description: PGP signature
Re: Results of the meeting in Helsinki about the Vancouver proposal
On Monday 22 August 2005 12.58, Marc Haber wrote: I can imagine that for archs with less than 50 machines reporting to popcon it could be possible to have some kind of registration mechanism. Uh, please don't add huge technical overhead for corner cases that will rarely happen, if ever. I'm confident that unless a port is really showing severe neglect, nobody will ever be interested in a precise body count. Personally, I think the 50 users limit is just silly. Let's stick with what really matters: can we (the Debian project) maintain the port? Thus I propose we only limit on the number of developers: are there people who are willing and competent to maintain kernel, boot loader, platform specific installer bits, libc and toolchain? Furthermore, I think port maintainers should be much more aggressive to exclude packages from being built on their port. For example (without having the experience) it might not make sense to build KDE3 for PDP8 or ENIAC - yet the packages are built and take a HUGE chunk of buildd time on every upload. Why not have a per-port blacklist (maintained by the port maintainers, not the package maintainers) of packages that are not suitable for a port, and just put up a section in the release notes (or wherever) on why such-and-such packages are not available. If enough people want them, someobdy will certainly run to put up an archive on apt-get.org with unofficial packages. (discalimer: I only run x86 myself, so perhaps this is a stupid idea.) cheers -- vbi -- Die große Koalition ist die formierte Gesellschaft des Parlaments zur Abwehr mißgünstiger Wählereinflüße. -- Helmar Nahr pgpn3ynLKYmDs.pgp Description: PGP signature
Re: Will the amd64 port be rejected because of the 98% rule?
On Monday 22 August 2005 12.17, Andreas Jochens wrote: On 05-Aug-22 11:48, Andreas Barth wrote: * Andreas Jochens ([EMAIL PROTECTED]) [050822 11:36]: If not, what does the 98% rule really mean? Your port needs to be able to and does build the vast majority of the archive before we consider it fitting for release. That there are more This is of course a fully reasonable requirement. I hope that the final policy will use these words instead of the 98% rule which will likely cause misunderstandings. Amen. Generally, Debian needs a *lot* more #include common-sense in all these things. Debian is run by humans, and the rules that Debian runs on constantly change. Trying to fix these rules down to the last corner case that might happen once in a decade just doesn't make sense. Deal with these corner cases when they come - yes, there will be flamewars, but at least they'll have some reason and not be silly endless purely-theoretical debates like we're having now. -- vbi -- Das Geheimnis des Könnens liegt im Wollen. -- Guiseppe Mazzini pgpFoxM2ashV0.pgp Description: PGP signature
Re: vancouver revisited
On Monday 22 August 2005 11.25, Peter 'p2' De Schrijver wrote: [ the 'must have a working installer' requirement ] Trivial. debootstrap does that. Debootstrap is not an installer, in very much the same way that tar isn't, either. They both are. They can install debian, so it's an installer. This is getting silly. I think nobody debates the fact that some CPUs never had any PC-style machines made and are targetted at the embedded market - yet a Debian port may still make sense. So can we just rephrase the 'working installer' bit and call it 'well-documented, working and supported (by Debian's documentation etc.) installation method'? If a populer CPU evaluation board ships on a PCI card, installing Debian on that board using some kind of firmware-uploader from a host computer is the sensible thing to do - the important things are - that the end result is a Debian system (i.e. working package management) - that I can sensibly bootstrap such a system from source in the Debian archive (not 'somebody has hand-crafted a firmware image for that board, so take that and go from there'). cheers -- vbi -- this email is protected by a digital signature: http://fortytwo.ch/gpg pgpLE91HtW30S.pgp Description: PGP signature
Re: Will the amd64 port be rejected because of the 98% rule?
On Tuesday 23 August 2005 06.44, Joe Smith wrote: By the way, i386 does not make the cut according to the vancouver prospect due to the number of buildds required. So are we left with 0 archs in etch? :) That will certainly speed up the release. LOL. Release NOW! Release now, damnit! I think it will be our fastest and smoothest release ever. I'm sure somebody will manage to botch the release notes or there will be some leftover non-empty Packages file lying around in some directory... -- vbi -- Available for key signing in Zürich and Basel, Switzerland (what's this? Look at http://fortytwo.ch/gpg/intro) pgpXE3WgPZWJd.pgp Description: PGP signature
Re: Results of the meeting in Helsinki about the Vancouver proposal
On Monday 22 August 2005 23.51, Steve Langasek wrote: On Mon, Aug 22, 2005 at 06:22:11PM +, W. Borgert wrote: On Mon, Aug 22, 2005 at 07:29:31PM +0200, Adrian von Bidder wrote: really matters: can we (the Debian project) maintain the port? Thus I propose we only limit on the number of developers: are there people who are willing and competent to maintain kernel, boot loader, platform specific installer bits, libc and toolchain? That sounds sensible. It ignores the fact that every port is a drain on centralized project resources, whether it has users or not. How so? (I mean, how does my proposal to drop the 'has users' requirement in favor of 'do we have developers' ignore the resource usage. I certainly do not dispute that a port uses resources.) And even if: would a userless port have the developers? For one thing, the develoeprs are users themselves, and for another thing, even 'doorstop architectures' where 90% of the users are seriously computer infected, only a few of those are likely to be competent enough to maintain kernel and toolchain. So I'd claim the (difficult to define) 'has users' requirement is not so much different from a (IMHO easier to define) 'has developers' requirement. cheers -- vbi -- Beware of the FUD - know your enemies. This week * The Alexis de Toqueville Institue * http://fortytwo.ch/opinion/adti pgpzaYRHf0ZFu.pgp Description: PGP signature
Re: better init.d/* : who carres ?
On Wednesday 24 August 2005 17.15, Miquel van Smoorenburg wrote: Make sure you use only POSIX features when doing this. I think grep -o is a GNU extension, FreeBSD doesn't have it for example. Doesn't the 'only POSIX' apply to the shell code only? At least, shouldn't it be judged on a per-tool basis? While awk is (was?) usually mawk on Debian, and not gawk, I don't think anybody uses a BSD grep on their Debian system. Please don't standardise on a minimal future set only for the corner case that somebody cripples his system beyond every reassonable limit. The 'POSIX shell' rule is here for a reason: there are people with /bin/sh being not bash. For other tools, this rule can be relaxed, imho. cheers -- vbi -- Ich kenne niemanden, der so oft Recht hat wie ich. -- Arno Schmidt pgpiwgHowvhar.pgp Description: PGP signature
Re: long long support on all archs?
On Wednesday 31 August 2005 18.03, Florian Weimer wrote: * Lars Wirzenius: Isn't this: int64_t, which can, if necessary, be provided using suitable autotools magic. exactly the answer to your: [...] Some upstream developers have to deal with old Solaris installations, though. We might want to show at least some restraint to facility backporting, too. ? typedef int64_t long long; cheers -- vbi -- Beware of the FUD - know your enemies. This week * Patent Law, and how it is currently abused. * http://fortytwo.ch/opinion pgpaKt4hdI1W1.pgp Description: PGP signature
Re: architecture-specific release criteria - requalification needed
On Wednesday 21 September 2005 15.30, Petter Reinholdtsen wrote: [arch release criteria] Personally, I find the list of requirements sensible, and very understandable after the clarifying rounds on the lists. This colors my view of the discussion. AOL!!1! The only thing I'd modify is the 50 users thingy - drop that, because - as Ingo says - it's hard to tell, on the assumption that if there are enough Debian *and* upstream people to maintain kernel, toolchain, libc, boot-loader and Debian installer (d-i or other), there is enough justification for the port. So 'm68k is having difficulty showing 50 users' becomes 'will m68k get a working gcc4 within a reasonable timeframe' which is easier to demonstrate. (I'm *not* just bashing m68k here. There are other arches where gcc4 ICEs, too, and there was quite a bit discussion about non-working kernels on certain SPARC variants IIRC.) That said, I can live with the 50 users idea. cheers -- vbi -- featured link: http://fortytwo.ch/smtp pgpOuukWoMwCM.pgp Description: PGP signature
Re: architecture-specific release criteria - requalification needed
On Thursday 22 September 2005 11.15, Debian-armeb Porting Team wrote: We are keeping patches[7] for the armeb port separate, and are ready to contribute them now, or at any future time that is more appropriate. Another chicken-and-egg - are package maintainers expected to accept patches for architectures that are not yet official? What kind of patches are these? - general porting issues uncovered by armeb (and not uncovered on other bigendian arches for some reason): I guess these should be immediately submitted. - things like configure scripts etc.: these are normally quite small and isolated, so I don't see a reason to not submit these. So there remain (very few?) cases where the patch is bigger (for whatever reason) - these will probably need more discussion. Even then: it's your stated goal for armeb to become a regular Debian architecture, so having your patches in the bts is one step closer to the goal. Obviously, some maintainers will not want to apply some of these patches, but a 'wontfix' bug doesn't hurt nobody... cheers -- vbi -- Computer programmers don't byte, they nibble a bit. pgprsnwBBBoWT.pgp Description: PGP signature
Re: Please have a look guys
On Wednesday 28 September 2005 17.36, you wrote: Please have a look at this guys. [word document attached] [silly disclaimer to finish it] Please, do not post word documents on this list. For several reasons: - we're reading email here. Why should I need to start an additional application to read your document? - many people read mail over an ssh connection in a text-based mail program, and it's not easy for them to start openoffice or kword to read the word document. - .doc is a document format used by the MS Office application suite, which runs on MS Windows only. It may surprise you, but many people who read this list do not use a Windows machine to do so. - The .doc document format has been repeatedly used to spread trojans/viruses in the past, and so many people will not open .doc documents from unknown people. Finally: the subject of your email and the introductory text do not give any information why we should be reading what you wrote. The Debian project (or rather, the individual developers - most of them, in any case) usually welcome input in form of good ideas, constructive ciriticism, whatever. But with more than 100 emails on this mailing list per day, you will need to make us *want* to read your text - usually, when I can't figure our what somebody is trying to tell me within the first three lines of text, I'll just ignore the email. Oh, and: using some disclaimer in legalese at the end of your email just makes you look stupid, it doesn't make anyone happy. greetings -- vbi -- Wie man sein Kind nicht nennen sollte: Perry Ode pgp2Yuvk5P65P.pgp Description: PGP signature
Re: Bug#331072: ITP: cinelerra-cvs -- non-linear video editor and compositor for Linux.
On Saturday 01 October 2005 17.07, Andreas Kuckartz wrote: But your reaction proves that the name cinelerra-cvs is misleading. But IMHO that's not something the Debian packager can do anything other than write it in the description. Renaming the package would only confuse users searching for Cinelerra CVS. cheers -- vbi -- Wenn ein Politiker stirbt, kommen viele zur Beerdigung nur deshalb, um sicher zu sein, daß man ihn wirklich begräbt. -- Georges Clemenceau pgprxRG2GLev9.pgp Description: PGP signature
buzz/rex binaries/install media?
Yo! (Yes, I thought about sending this to -curiosa instead... :-) For research/fun/..., I want to install historical versions of Debian. Does anybody have install media of rex and buzz? I guess it is possible to create packages by starting at bo and compiling the older binaries, but I don't know how easy it would be to recreate the installer disks... cheers -- vbi -- Elephant, n.: A mouse built to government specifications. pgp1RDBDC0CP7.pgp Description: PGP signature
Re: buzz/rex binaries/install media?
On Tuesday 18 October 2005 19.40, Matej Vela wrote: See http://www.ibiblio.org/pub/historic-linux/distributions/debian/1.1/ for buzz disks. Thanks. Now, does anybody know if buzz/Linux 2.0.0's 'ne' driver didn't support realtek PCI network cards, or if it's a qemu problem? (I suspect the latter, as the ne2k-pci of 2.0.38 also doesn't work.) Ok, this is getting OT - I'll shut up now on this topic. cheers -- vbi -- featured link: http://fortytwo.ch/smtp pgpCu6ykF5xxm.pgp Description: PGP signature
Re: what to do with iputils (ping, etc)
On Friday 21 October 2005 22.22, Noah Meyerhans wrote: It depends on what you mean by up to date. If we're only including glibc headers, then we can only use functionality that glibc supports. If we bypass glibc and directly use kernel functionality, then we get all the latest and greatest kernel networking features. What kind of features are we talking about here? cheers -- vbi -- You can only live once, but if you do it right, once is enough. pgpxnRHynW3AH.pgp Description: PGP signature
Re: Bug#335173: ITP: dspam -- Highly accurate and fast statistical spam filter
merge 335173 195948 thanks On Saturday 22 October 2005 12.08, Rudolf Weeber wrote: * Package name: dspam I am packaging this program, because we are using it the students' representation at university, and having a standardized, easy to install package would be very handy. Have you talked with all the other people who are interested in packaging dspam for Debian? (see http://bugs.debian.org/195948 - this ITP was already filed several times in the last 2 years.) greetings -- vbi -- Oxymoron: Microsoft Works. pgpORrEGZpLpu.pgp Description: PGP signature
Re: ITP: jahshaka -- Realtime editing and effects system
Just a few hints for the future: - you should not cc: a wnpp bug (ITP, RFP, ...) to d-devel, because these bugs go to d-devel anyway. - if you want to cc: a bug submission somewhere, please use the X-Debbugs-CC: header (read up in the bts documentation) instead of directly cc-ing, because that way the bts can insert the bug number and a proper reply-to header before the message hits the mailing list. On Saturday 22 October 2005 22.58, you wrote: Description : Realtime editing and effects system What kind of effects? Show effects? Sound effects? Graphics effects? And what kind of editing? Since effects and real-time are mentioned, I guess it's not a HTML editor... ;-) The long description alludes to graphic effects since it mentions OpenGL, but I think this short description could be made more clear. - this ITP closes the RFP bug #200984 So why submit a new bug instead of just retitling the RFP? (read the bts documentation: send a mail to [EMAIL PROTECTED] with 'retitle n new bug title' in the body. Jahshaka is still beta, but it's really promising and having it packaged under Debian will allow more feedback upstream. Depending on how beta the package is and how fast development progresses, you may want to open a marker RC bug so that the package won't enter testing. Consider that when etch releases, you'll have bug reports on the version that was released with etch for 1 year. Etch is a long way right now, so you'll have plenty of time to think about that. greetings -- vbi -- Available for key signing in Zürich and Basel, Switzerland (what's this? Look at http://fortytwo.ch/gpg/intro) pgpuqO4XkKFj7.pgp Description: PGP signature
Re: Versioned BTS question:
On Sunday 23 October 2005 21.48, Ken Bloom wrote: I'm tracking through some old bugs I submitted, cleaning up. I'd like to close bug 256715, because jpilot and gtk-engines-smooth no longer interact (because jpilot uses GTK+2 now). What's the appropriate version to specify to the BTS? If you can track it down easily: as close as you can find to the version that made the bug report obsolete. If you can't or you don't want to spend the effort: if, for example, jpilot/stable has the problem and jpilot/testing hasn't, just close the bug for the version in testing. Make a not in the closing message that it may not be the exact version, but I doubt anybody will ever care. cheers -- vbi -- featured link: http://www.pool.ntp.org pgpYdNOEP20Oh.pgp Description: PGP signature
Re: Debian based GNU/Solaris: pilot program
On Thursday 03 November 2005 04.37, Erast Benson wrote: If don't, Nexenta will continue its way more like Ubuntu does. You'll hire heaps of Debian developers and actually pay people to contribute their stuff back to Debian? Now there's a thing! Which Debian developers are in your pay (just curious)? I'm always in favor of Debian developers being able to hack on Debian packages as their daytime job. -- vbi -- Jede Zeit ist eine Sphynx, die sich in den Abgrund stürzt, sobald man ihr Rätsel gelöst hat. -- Heinrich Heine pgpxw1MBQiRcn.pgp Description: PGP signature
Re: [Fwd: Re: Debian based GNU/Solaris: pilot program]
On Thursday 03 November 2005 08.32, Erast Benson wrote: Matthew: [...] whether you want to be part of A Debian Release. Hard to say right now... Lets see how all this thing will progress. But, *yes* we are willing to cooperate. So I guess this summarizes the technical side of this discussion. To use the lkml attitude: show us the code. Release your system, show us that you can actually work with the Debian community rather than just discuss things on a mailing list by pointing out that there is a authorizatrion-required web site that contains much more info for those inclined to apply for a password. Debian/Opensolaris should do this: get the code working and published, and *then* work with the Debian project to get it integrated. Since you'll be using Debian source packages, this should be mostly doable by filing portability patches to the Debian bug tracking system. I leave the license question to others - I'm not qualified. I just say that you'll have to seriously address this if you want to become a part of Debian. (Saying 'Sun's lawyers did think it's ok' will *not* be enough.) -- vbi -- Every bug you find is the last one. pgptKazsi4CQu.pgp Description: PGP signature
Re: Debian based GNU/Solaris: pilot program
On Thursday 03 November 2005 20.51, Erast Benson wrote: HW vendors will *never* open their IP in drivers. Ok, this becomes a bit OT here, but let me just remark that Linux today supports a *lot* of hardware, and that quite a few drivers (some RAID controllers, Intel SATA stuff, most of the S/390 and a lot of the HPPA stuff, I'm sure there's more) are actually actively supported by hardware vendors. So you seem to live in a parallel universe at least to some degree. -- vbi -- Beware of the FUD - know your enemies. This week * Patent Law, and how it is currently abused. * http://fortytwo.ch/opinion pgpfYbZmD9hLv.pgp Description: PGP signature
Re: Debian based GNU/Solaris: pilot program
On Friday 04 November 2005 19.00, Andrew Suffield wrote: Complete bullshit. Get a life. plonk Ahhh, yet another instance of asuffield. -- vbi -- featured product: GNU Privacy Guard - http://gnupg.org pgpToLVOlXVEk.pgp Description: PGP signature
GPL... (was: Re: Debian based GNU/Solaris: pilot program)
On Friday 04 November 2005 14.33, John Hasler wrote: Wouter Verhelst writes: Any *distributed* changes to foo.c must be contributed back to the community. That's not true either. Any distributed changes must be made available to those to whom the changes were distributed. In practice changes usually become available to the community but that is not required. ... and it is also not required to make the changes available in a useable form. (/me remembers some Montavista hacked gcc for some embedded platform: I tried to forward port their modification once, but gave up because all they distributed was the complete toolchain source with no indication what upstream version, exactly, it was based on[1]. Legally ok, to the letter of the GPL, but totally useless beecause isolating Montavista's work was virtually impossible. I'm not picking on MV specifically here, it's just a good example from personal experience.) [1] nontrivial - I concluded that it must have been a CVS snapshot with some additional upstream patches applied. -- vbi -- Could this mail be a fake? (Answer: No! - http://fortytwo.ch/gpg/intro) pgpJ90YmDUABc.pgp Description: PGP signature
Re: apt-proxy
On Monday 07 November 2005 15.53, Ian Campbell wrote: On Mon, 2005-11-07 at 11:51 +1100, Brian May wrote: However, I prefer the approach over apt-cacher, as the apt-sources entries remain independent of the server that will be used to retrieve the files. Is there a good alternative? I use apt-cacher and have mod_rewrite rewrite /debian/ to /apt-cacher/ftp.uk.debian.org, similarly for /debian-amd64/ and /debian-security/ etc. For those not fluent with mod_rewrite, would you mind posting the configuration snippet? cheers -- vbi -- Available for key signing in Zürich and Basel, Switzerland (what's this? Look at http://fortytwo.ch/gpg/intro) pgpdXzKMt1Bdk.pgp Description: PGP signature
Re: Debian DPL Debate Comments
[cc to you - I don't know if you read the list] On Friday 18 March 2005 17.22, Ritesh Raj Sarraf wrote: As for example, it's been now around 7 years for me now using Linux and I do have a fair amount of knowledge now. It would be great if DD's here could harness the skills in wannabe contributors like us and prepare us help this marvelous community. In particular to me, I'm willing to contribute to Debian as maybe a DD, Package Maintainer, SysAdmin or any other work you people find as an undiscovered skill in me. It's just Not The Way It Works(tm) Nobody will assign you some work 'just so' - if you want to contribute, think about what do *you* think could be better in Debian? How would you do it? Then, find people (or the right mailing list) who do some work in that area (if you don't find the right place, a question to this list is o.k.) and work with them. That said, if you just have some spare time and want to do something for Debian, fire up your web browser and browse Debian's bug data base on http://bugs.debian.org. Bug fixing help is always welcome. If you're not sure what you should do with a particular bug, you can always ask on the #debian-bugs or #debian-devel IRC channel on irc.debian.org. greetings -- vbi -- Beware of the FUD - know your enemies. This week * Patent Law, and how it is currently abused. * http://fortytwo.ch/opinion pgp7syn8XF1ss.pgp Description: PGP signature
Re: Sarge release for amd64 - Please help to fix the remaining bugs
On Monday 25 April 2005 14.51, Andreas Jochens wrote: Steve Langasek wrote: libmysqlclient-lgpl - Linuxthreads test has to be switched off for amd64 [...] Unfortunately, quite a few important packages still Build-Depend on libmysqlclient10-dev: exim4 Does that mean amd64 installer come without a mailer by default? Or will the amd64 installer install a different mailer? postfix Especially since at least one of these two would be very nice to have... greetings -- vbi -- featured link: http://fortytwo.ch/gpg/subkeys pgpaIFwotqoXi.pgp Description: PGP signature
Re: Free Game Console
On Saturday 30 April 2005 07.54, Dillinger wrote: Hi, I invented Macromedia Flash. [...] Can I get one of those things your're smoking? -- vbi -- Could this mail be a fake? (Answer: No! - http://fortytwo.ch/gpg/intro) pgp2E1218gns7.pgp Description: PGP signature
Re: Dualing banjos
On Saturday 07 May 2005 16.56, Brad and Billie Fick wrote: do you know how I can get the sheet music to this? If so I would greatly appreciate it. Thank you There we go again. I am so glad this happens, helps to lighten the mood everywhere and certainly eases the way to general happiness in the world (the same kind of help we see at the beginning of the Hitchhiker's Guide. The yellow bulldozer and the vogon fleet included.) (Brad and Billie: it's probably not entirely your fault that you have problems understanding a single word of the above. Please see this web site: http://wiki.debian.net/?DuelingBanjoes) cheers -- vbi -- Today is Pungenday, the 55th day of Discord in the YOLD 3171 pgpFm6CH0M4qs.pgp Description: PGP signature
Re: Bug#309241: ITP: dguitar -- Guitar Pro 3/4 tabs viewer and player
On Sunday 15 May 2005 23.24, Grzegorz Bizon wrote: Description : Guitar Pro 3/4 tabs viewer and player Somebody should file a wishlist bug against all guitar related software packages to include a certain song as example data. I won't name it. If you're new on this list, google for self-perpetuating google flop. -- vbi -- Beware of the FUD - know your enemies. This week * The Alexis de Toqueville Institue * http://fortytwo.ch/opinion/adti pgpbe71xQBgnF.pgp Description: PGP signature
Re: removing ipfwadm
On Monday 16 May 2005 23.27, Marco d'Itri wrote: On May 16, Adam McKenna [EMAIL PROTECTED] wrote: I am not sure whether the ipfwadm package should be removed. Kernels up to 2.4 still have support for ipfwadm filtering rules, so theoretically people could still be using it with current kernels. Wait until sarge has been released and then kill it. Is it orphaned? If not, why kill it? Some people have invested many hours writing their firewall scripts, and if they can continue to use them they're happy. (Not me - ipfwadm hasn't done enough for my taste in a long time.) cheers -- vbi -- Kallisti! pgpZJAdMpXCBK.pgp Description: PGP signature
Re: updated cogito package - now with docs!
[cc:ed as I don't know if you read both -devel and -mentors] On Wednesday 11 May 2005 22.05, Sebastian Kuzminsky wrote: [cogito] Sebastian, can I humbly request that you don't announce cogito package updates on (at least the -devel) mailing list? While I - and, I guess, many others - are thrilled to see cogito packaged, I'd hate it if everybody now started to announce every new package version on -devel... thanks -- vbi -- Beware of the FUD - know your enemies. This week * Patent Law, and how it is currently abused. * http://fortytwo.ch/opinion pgpgNKSZ1IIUd.pgp Description: PGP signature
Re: RFC: A new video-related section
On Friday 27 May 2005 14.15, Gergely Nagy wrote: On Fri, 2005-05-27 at 14:13 +0200, Pierre Habouzit wrote: the right thing to do would be to switch from sections, to keywords, so that kmplayer could live in sound + video + kde, instead of multimedia that is not very informative. Now this, I'd second :) (OTOH, I'm not volunteering to implement support for this, I don't care about this that much :P) Isn't this exactly what debtags is trying to do - so the implementation is already 50% there. (Not that I'm involved with debtags.) cheers -- vbi -- Beware of the FUD - know your enemies. This week * Patent Law, and how it is currently abused. * http://fortytwo.ch/opinion pgpFxYiUeRtJE.pgp Description: PGP signature
Re: How to find really old source of the shadow package
On Monday 30 May 2005 02.03, Nicolas François wrote: Does anybody know where I can find older sources? [ of shadow ] - have you tried asking the shadow maintainers ([EMAIL PROTECTED]) - perhaps somebody has old CVS repositories or whatever lying around? - The Debian changelog goes back to 1997 - have you tried contacting these people, perhaps they have some old sources (/usr/share/doc/changelog.Debian.gz). greets -- vbi -- Wibble. pgpk2n89FdOrj.pgp Description: PGP signature
Re: Is Ubuntu a debian derivative or is it a fork?
On Tuesday 31 May 2005 19.17, Stephen Birch wrote: Still looks more like a fork than a derivative . or a spoon :-) I have problems with your terminology - what do you mean by 'fork', and what do you mean by 'derivative'? To my understanding, Ubuntu is certainly a derivative of Debian (since it derives most of its packaging from Debian), and it's a fork (since Debian is not dead, and both projects are maintained.) Passing of code between branches of a fork is something that can happen - for example, the gcc/egcs fork was originally announce that way: both branches would take code from the other side.) cheers -- vbi -- Manoj madduck: Umm, if you wanna hack at kernel-package in non-standard ways, you need to be one with the source madduck make is not one with its own Makefiles. -- #debian-devel, Fri, 04 Mar 2005 17:50 +0100 pgpHd9i0WCRAw.pgp Description: PGP signature
Re: notes on deckit WAP phone simulator
On Saturday 04 June 2005 07.50, venkat prasad wrote: sir, can u please give me the information bout the decik WAP phone simulator.i.e., the brief description about the phone simulator. As far as I can tell, Debian does not ship the decit WAP phone simulator, so I don't know what information we should be able to give you. thank you -- vbi -- OpenPGP encrypted mail welcome - my key: http://fortytwo.ch/gpg/92082481 pgpqg1oUmiNRy.pgp Description: PGP signature
Re: Perl or Java project
On Saturday 04 June 2005 19.20, Joshua Jackson wrote: Where could I find out about projects that still need developers. I could code in perl and java. Please tell me where I can read the resources regarding to the available projects in debian. Java: A group of people tries very hard to get as many Java things working with free Java environments (sablevm, kaffee, gcj etc. instead of Sun JDK). I'm sure they can use help. http://lists.debian.org/debian-devel-announce/2005/06/msg2.html cheers -- vbi -- Beware of the FUD - know your enemies. This week * Patent Law, and how it is currently abused. * http://fortytwo.ch/opinion pgpx0FzNJorRC.pgp Description: PGP signature
Re: And now for something completely different... etch!
On Tuesday 07 June 2005 01.03, Javier Fernndez-Sanguino Pea wrote: [ End user improvements ] - better support for displaying as many languages as possible without having to search for corresponding font packages. From what I can see gnome is slightly better than KDE in replacing missing characters, but I think both still can't display the http://www.wikipedia.org titlepage with all characters. I think a font metapackage that depends on a set of fonts that cover most of unicode would be a great thing. [ Release improvements ] A new release process that would encourage us to seriously think about the next release after (at most) 8 months, so that a release within 15 months is realistic. Ideally without blocking new KDE/Gnome/... releases for longer than absolutely necessary. Is somebody maintaining this list on wiki.d.n or wherever, ideally with status updates and pointers to people who will do this? (Sorry if this is already covered, just reading this whole thread now.) Is etch already unfrozen or is there a grace period for some reason? I see security.d.o doesn't have etch right now. Is this just an issue of infrastructure not being ready just now or did I misunderstand the idea of testing having security support? (IMPORTANT IMPORTANT IMPORTANT This is no rant - I'm just trying to understand what's going on IMPORTANT IMPORTANT IMPORTANT) cheers -- vbi -- http://wiki.debian.net/ReleaseParty pgpo4mfEb4C7E.pgp Description: PGP signature
Re: And now for something completely different... etch!
On Tuesday 07 June 2005 01.47, Marco d'Itri wrote: On Jun 07, Javier Fernndez-Sanguino Pea [EMAIL PROTECTED] wrote: In my wishlist there is NO support of 2.4 kernels Hmm. I've never verified this myself, however until recently it was often claimed that 2.6 is still quite a bit worse than 2.4 for some workloads - so dropping 2.4 prematurely would probably be harmful. Making it the default kernel however would certainly be sensible. - inetd begone! - xinetd (better mechanism to control DoS, privilege separation, etc.) What about you try a decent inetd instead? Wasn't that exactly what Javier proposed? Or is xinetd not sensible enough? cheers -- vbi -- Today is Pungenday, the 12nd day of Confusion in the YOLD 3171 pgp4zMggUmrva.pgp Description: PGP signature
Re: And now for something completely different... etch!
On Tuesday 07 June 2005 19.51, Marco d'Itri wrote: On Jun 07, Adrian von Bidder [EMAIL PROTECTED] wrote: In my wishlist there is NO support of 2.4 kernels Hmm. I've never verified this myself, however until recently it was often claimed that 2.6 is still quite a bit worse than 2.4 for some workloads - This does not make it true. No it doesn't. But it indicates that there are still people who prefer 2.4 to 2.6. Dropping 2.4 can easily be done on relatively short notice prior to etch release, so no need to worry about now. Also, I feel that the decision to ship 2.4 or not can be left up to the kernel team - if they have the manpower, fine, if not, dropping 2.4 certainly is an option. cheers -- vbi -- Available for key signing in Zrich and Basel, Switzerland (what's this? Look at http://fortytwo.ch/gpg/intro) pgpiK9LtGpwnr.pgp Description: PGP signature
Re: And now for something completely different... etch!
On Tuesday 07 June 2005 23.32, Roger Leigh wrote: Frans Pop [EMAIL PROTECTED] writes: On Tuesday 07 June 2005 23:02, Roger Leigh wrote: Existing installs are already configured with debconf. Their /etc/locale.gen will not be touched. If you do dpkg-reconfigure locales, then users could have the locale switch to UTF-8 if they so choose. AFAIK locales are automatically regenerated when the locales package is upgraded, so this _would_ effect every existing install directly on upgrade to the new release. locale-gen is run, but /etc/locale.gen is not necessarily altered. If you don't change it, it will regenerate the same locales you already have. But 'the same locale I already have' would probably mean 'the locale with the name of the locale I previously had' which has now suddenly changed its behaviour. No easy way out - either you force people to adapt locale.gen, or you don't change locale names. cheers -- vbi -- L'uomo - diceva S... - e' un animale ben sciocco, almeno a giudicare da me stesso. -- Nicolas de Chamfort, Caratteri e aneddoti pgp2EjmpgyML8.pgp Description: PGP signature
Re: Bug#312669: /sbin/ifconfig: Add ifconfig to user path
On Friday 10 June 2005 10.40, Bernd Eckenfels wrote: Hello Olaf, On Thu, Jun 09, 2005 at 02:58:21PM +0200, Olaf van der Spek wrote: ifconfig is in /sbin and only in root's path. But ifconfig is runnable and useful for normal users, so it'd be nice if it could be added to the path of normal users too. .. So I am inclined to ignore this wishlist bug, however I wait for reponses on the developer mailing list. Given that it is trivial to do $ echo PATH=$PATH:/sbin:/usr/sbin ~/.bash_profile or the equivalent for whatever $SHELL a user is running, I'd support that. cheers -- vbi -- featured product: GNU Privacy Guard - http://gnupg.org pgpBH7WoJxVjB.pgp Description: PGP signature
Re: TODO for etch ?
On Friday 10 June 2005 21.39, Nikita V. Youshchenko wrote: Hello. Is the TODO list for etch available anywhere? It is now. http://wiki.debian.net/?EtchTODOList Please help updating it. Because I really mean it, I repeat here the guidelines that I feel can keep this list useful instead of providing a battleground for edit-wars... - Don't list issues with single packages here - we have the bug tracking system for this! http://bugs.debian.org - Don't list proposals here on how the Etch release should be managed. There is ReleaseProposals for this. - For all issues, please try to provide links to mailing list discussions etc. - while the Wiki is good for keeping track of issues up to some point, it is not a good discussion medium imho. So, if you list controversial issues here, DON'T discuss these things here and don't just remove them - add links to relevant parts of the mailing list archives. (obviously, this is not a 'etch won't be released until this list is empty' kind of thing, but rather a 'things that could be done better in etch' list. greetings -- vbi -- Try not. Do. Or do not. There is no try. pgp0iiKOCTfqU.pgp Description: PGP signature
Re: Bug#312897: ITP: texlive -- The TeXlive system packaged for debian
On Monday 13 June 2005 09.41, frank wrote: [texlive vs. teTeX] Let me add some comments from my point of view (Debian teTeX maintainer). Sounds like packaging texlive and trying to get it really stable would be the thing to do, with the goal of phasing out teTeX for etch+1 Not becuase I don't value your work, Frank, but from what you said it sounds like texlive is a better maintained superset of teTeX - or are there reasons why somebody specifically would want to stick to teTeX (assuming a transition plan etc. etc. to solve all Debian/packaging specific issues.) greetings -- vbi [pity you couldn't make it on Saturday.] -- OpenPGP encrypted mail welcome - my key: http://fortytwo.ch/gpg/92082481 pgpym8LkgyMAx.pgp Description: PGP signature
Re: And now for something completely different... etch!
On Monday 13 June 2005 23.00, John Hasler wrote: Jesus Climent writes: Exactly my point, what impedes an admin to set some defaults wether the system comes as it comes now or with some predefined options and settings? Nothing, except for the fact that most admins haven't the foggiest idea how to do that. Thus the suggestion that the default runlevels be what most people expect them to be. The people you probably mean when you write admin (with the quotes) usually, in my experience, go into blank-stare-mode when I mention the word 'runlevel' or even 'command line'. I guess you can count me to the the people who care will have their own ideas anyway, 90% of all others don't know anything and so wouldn't be able to take advantage of any special runlevel configuration fraction. cheers -- vbi -- Today is Setting Orange, the 19th day of Confusion in the YOLD 3171 pgp5HgMg0W1UA.pgp Description: PGP signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
On Tuesday 14 June 2005 08.00, Eric Dorland wrote: 3. Accept MoFo's offer of Debian-specific trademark usage. I don't believe #3 is acceptable under the DFSG. IMHO this *trademark* license corresponds quite exactly to the *copyright* license that require renaming on change, which seems to be DFSG-ok (TeX fonts?): Debian offers a version of firefox but people who take Debian's firefox and change it will have to rename it. cheers -- vbi -- The Computer made me do it. pgpGK0chUvA9Z.pgp Description: PGP signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
On Tuesday 14 June 2005 18.21, Eric Dorland wrote: * Matthew Garrett ([EMAIL PROTECTED]) wrote: Julien BLACHE [EMAIL PROTECTED] wrote: Matthew Garrett [EMAIL PROTECTED] wrote: What is DFSG 4 if not a grudging acceptance of this sort of behaviour as free? (This is a compromise. The Debian Project encourages all authors to not restrict any files, source or binary, from being modified.) Says it all. Right. We don't like it, but we think it's free. Requiring a name change because we apply a security patch or fix a bug crosses the border. It's not like if we were forking their codebase. We have permission to apply security patches and fix bugs without changing the name. We (as in Debian) may have the permission, but that permission does not flow downstream. So? As I understand DSFG 8, this covers only the case that the firefox package distributed by Debian *as is* must still be usable legally when used outside Debian. Yes, it's not nice, it's crap, but it's still entirely possible within the (pseudo-)legal framewark Debian gives itself. cheers -- vbi -- featured product: the KDE desktop - http://kde.org pgpRYJIOqdyd5.pgp Description: PGP signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
On Tuesday 14 June 2005 16.20, Humberto Massa Guimares wrote: * Towns :: Does calling it firefox or thunderbird hurt free software? At first, no. But it *does* hurt our users. Why? Because they are confident that getting something from the Debian mirror, modifying it and re-distributing under the same terms is allowed. And they can be burned after some time. And they *will* blame it on Debian. DFSG 4 again: it is grudgingly allowed that people are required to rename what they get from Debian. -- Beware of the FUD - know your enemies. This week * The Alexis de Toqueville Institue * http://fortytwo.ch/opinion/adti pgpqEGDpMiJxW.pgp Description: PGP signature
Re: Bug#313569: ITP: LinuxTaRT -- The Automatic Random Tagline, a versatile, fast and feature-rich email signature generator
On Tuesday 14 June 2005 14.24, Colin Tuckley wrote: TaRT features include random taglines, optional daemon functionality, display of current date, custom layout of signature, and special date tagline text. The command line syntax is simple and well explained. LinuxTaRT is designed to be run as a stand-alone daemon, from crontab, or in your login script. Could you please elaborate how this is different from signify? (And I guess there are still other things to produce taglines.) (Not that I want to prevent you from packaging this - but after the 50th window maker and the 30th wiki, we now start to collect random funny text generation programs, too?) And please clarify: is it a daemon or should it be run from cron? Daemon to be run from cron doesn't make sense to me. cheers -- vbi -- Fnord. pgpjYU9w7aalk.pgp Description: PGP signature
mail clients and threading... (was: Re: And now for something completely different... etch!)
On Tuesday 14 June 2005 19.14, Humberto Massa Guimarães wrote: [...] Hmmm. Is it just my kmail, or does your mailer produce strange (or no?) In-Reply-To headers? All your posts I saw (and none others afaict) appeared to be in reply to some completely irrelevant other message in the same thread - it's extremely annoying to read your postings that way. cheers -- vbi -- Beware of the FUD - know your enemies. This week * Patent Law, and how it is currently abused. * http://fortytwo.ch/opinion pgp0zUh6k4URu.pgp Description: PGP signature
Re: ftp-master, ftp and db .debian.org moving - hosting sought
On Wednesday 22 June 2005 20.02, Olaf van der Spek wrote: [debian infrastructure] I've been wondering, would it be an idea (for the long-term) to use (more) distributed ... or p2p concepts to reduce the dependency and load on central servers? You said it yourself: in the long term. I think that some of the P2P network concepts might be very interesting for some things like file hosting etc. - but this won't be feasible within the next few weeks or even months. Additionally, you need to keep in mind that - depending on what exactly you'd want to do - current oldstable's tools would reasonably have to be supported at least until oldstable becomes veryoldstable, so any benefits of such a new system would have a big effect only slowly. So I guess, the standard open-source-project-answer applies: if you like the idea, write the code, propose to implement it - at least as a small-scale prototype - and then we'll look at it. cheers -- vbi -- Today is Prickle-Prickle, the 28th day of Confusion in the YOLD 3171 pgpeSov2LgFgs.pgp Description: PGP signature
Re: Getting rid of circular dependencies
On Monday 27 June 2005 18.15, Gustavo Noronha Silva wrote: [circular dependencies] [uninstalling foo-data at libfoo uninstall] This should really be fixed in the packaging tool -- aptitude will handle this very elegantly, maybe bringing its expanded package states to libapt itself would be nice -- rather than using this kind of trick. Possibly. And - as a clarification of the policy, really - I'd vote for having one of the the next dpkg and apt releases strictly enforcing dependencies, making packages with circular dependencies uninstallable. (But, in the spirit of good communication, this should probably be announced on d-d-a, or at least by bugs on all affected packages.) cheers -- vbi -- A la fuerza, ni los zapatos entran. pgptDUNQk28Dj.pgp Description: PGP signature
Re: May one use ~rc1 within versions although older lintians are complaining?
On Tuesday 13 March 2007 20.23:16 Roman Müllenschläder wrote: Because my laptop, where I'm building the packages on, is running Edgy ;) Maybe I should compile lintian by hand ... tried using sources from feisty but they need to much dependencies ... If you're building packages for Debian, you should use a Debian machine, not an Ubuntu machine. If you're building debs for Ubuntu, you should discuss with the Ubuntu developers if ~ in version numbers is ok with all of their tools. If you're building packages just for yourself: I think all the relevant tools can cope with ~ for quite some time now, so you can ignore the lintian warning. cheers -- vbi -- A user will find any interface design intuitive...with enough practice. pgpJQvRo8qO33.pgp Description: PGP signature
Re: Compiling Debs on AMD vs. Intel and 32bit vs. 64bit
On Thursday 15 March 2007 20.02:14 Greg Folkert wrote: And for clarity, IA32 cover 32-bit Intel and works for AMD 32-bit processors. IA64 is the Itanium series of processors, amd64 cover the AMD K8/Opteron processors AND the Intel emt64* Intel processors. ... and just for completeness: x86_64 was the name the Linux kernel people chose for AMD64. I don't know where the term came from, exactly. cheers -- vbi -- Fnord. pgpRzemOPwD1Y.pgp Description: PGP signature
Re: Compiling Debs on AMD vs. Intel and 32bit vs. 64bit
On Saturday 17 March 2007 09.29:10 Peter Samuelson wrote: x86=64 would have been amusing too. Is it a veiled Commodore 64 reference, or is it quoted-printable? Not to speak of broken mime decoders that would just display x86d. I'd rather say it's to do something with Georg Orwell. If 2+2=5, then we can also have 86=64, I don't know what happens to the x, though. Hmm. Or we could just call the architecture x=0.744 cheers -- vbi -- Wer A sagt, der muß nicht B sagen. Er kann auch erkennen, daß A falsch war. -- Bertold Brecht pgpeHazG8KJK1.pgp Description: PGP signature
Re: many rejects (Re: Second call for votes for the debian project leader election 2007)
On Thursday 29 March 2007 06.24:52 Henrique de Moraes Holschuh wrote: On Wed, 28 Mar 2007, Manoj Srivastava wrote: On Wed, 28 Mar 2007 12:52:33 -0300, Henrique de Moraes Holschuh [EMAIL PROTECTED] said: You do not handle signing subkeys? What makes you think that? Any key that is used needs to be in the debian keyring, is all. I just checked, and yes, subkeys are handled just fine. Sorry about the confusion. IIRC signing subkeys are not accepted at package uploads, so maybe that's what you were thinking about. cheers -- vbi -- Today is Sweetmorn, the 18th day of Discord in the YOLD 3173 pgp4Wqhb91miP.pgp Description: PGP signature
Re: Second call for votes for the debian project leader election 2007
On Friday 30 March 2007 08.47:53 Manoj Srivastava wrote: OK, so please take this honest. I don't think I have ever been dishonest about it. Amused, perhaps, dishonest, no. Language issue. s/honest/serious/ Admittedly, I'm guessing. cheers -- vbi -- The young lady had an unusual list, Linked in part to a structural weakness. She set no preconditions. pgpHGnBVeTojA.pgp Description: PGP signature
Re: many rejects (Re: Second call for votes for the debian project leader election 2007)
On Sunday 01 April 2007 23:19, Henrique de Moraes Holschuh wrote: On Sun, 01 Apr 2007, Adrian von Bidder wrote: IIRC signing subkeys are not accepted at package uploads, so maybe that's what you were thinking about. AFAIK, they are. Policy URLs are not accepted, that's what I was thinking about. I use signing subkeys and usually a policy URL, so I just remembered that I have to take special steps before signing packages. Sorry about the confusion. cheers -- vbi -- You will be awarded some great honor. pgpxvKOyqFFFP.pgp Description: PGP signature
Xorg 7.2
Yo! Just a quick heads-up for those who don't read planet and have been wondering why Xorg 7.2 is lingering in experimental: There's an excellent announcement on David Nusinov's blog at http://gravityboy.livejournal.com/34738.html. I wish such stuff would be posted to the mailing lists and not just to blogs. To David and the other XSF people: keep on as you have the last years! X just is a non-issue, and that's just what I expect from it - it just works. (proprietary nvidia hardware excluded, but then that's my fault for having such hardware ...) cheers -- vbi -- featured product: the Apache web server - http://httpd.apache.org pgpHMBujzx2vN.pgp Description: PGP signature
Re: UNSUSCRIBE
On Tuesday 17 April 2007 20.51:16 Dmitry E. Oboukhov wrote: man procmailrc On gmail? -- vbi -- this email is protected by a digital signature: http://fortytwo.ch/gpg pgpjhb3v1ODBT.pgp Description: PGP signature
Re: Xorg 7.2
On Thursday 19 April 2007 03.15:21 David Nusinow wrote: We need to push XCB forward though, and how to deal with the java bug mentioned in that post isn't clear yet. What I don't quite understand is how a non-free package should block this upgrade. Yes, Java is used by a lot of people and I'd certainly not push this into testing until the problem is solved, but we're talking about unstable here. If Java is broken in unstable because of a Java bug (AFAIU this is really a Java bug, not an X bug?) and is not so easy to fix, the by all means lets break Java. Somebody apparently had pressure from somebody to push Java into non-free, so reports that Java is broken in Debian unstable should get the pressure up to get it fixed, no? cheers -- vbi -- what is the process? Do we vote, do we pray or do we send bribes? -- Ian Grigg, trying to get a new OpenPGP RFC out pgp7LU6mDFir0.pgp Description: PGP signature
To whoever will take over mysql (... and to everybody else thinking about playing games with version numbers)
Please DO NOT DO THIS AGAIN: +++ $ apt-cache policy mysql-server-4.1 mysql-server-4.1: Installed: (none) Candidate: 5.0.32-7etch1 Version table: 5.0.38-3 0 600 http://syydelaervli unstable/main Packages 5.0.38-1 0 700 http://syydelaervli lenny/main Packages 5.0.32-7etch1 0 800 http://syydelaervli etch/main Packages 4.1.11a-4sarge7 0 199 http://syydelaervli sarge/updates/main Packages 199 http://syydelaervli sarge/main Packages +++ An unfortunate string of events lead me to upgrade a server from sarge to etch, using the mysql-server-4.1 package and stupidly assuming that a package with the package name mysql-server-4.1 would contain a MySQL server version 4.1. Cost me quite some time to undo the damage (juggling backup tapes, merging database contents etc.) because one application is not entirely MySQL 5 compatible and thus partly corrupted the database. Providing no transition path is better than this. If aptitude had told me that it needs to uninstall mysql-server-4.1, I'd have noticed. cheers -- vbi -- We warn the reader in advance that the proof presented here depends on a clever but highly unmotivated trick. -- Howard Anton, Elementary Linear Algebra -- If the thunder don't get you, then the lightning will. pgpCPZYFpjzCl.pgp Description: PGP signature
Re: To whoever will take over mysql (... and to everybody else thinking about playing games with version numbers)
On Friday 04 May 2007 08:45, sean finney wrote: hi, On Fri, 2007-05-04 at 07:52 +0200, Adrian von Bidder wrote: An unfortunate string of events lead me to upgrade a server from sarge to etch, using the mysql-server-4.1 package and stupidly assuming that a package with the package name mysql-server-4.1 would contain a MySQL server version 4.1. um, shouldn't the fact that an upgrade of mysql-server-4.1 started installing a package named mysql-server-5.0 have been a good hint? Yes, certainly. As I said, it was an unfortunate string of events, I should have noticed. But having a package with the version number in it that doesn't contain that version was still, IMHO not the way to do it. anyway, this issue is moot in = etch, since we've adopted a new versioning scheme which should avoid messes like this in the future. currently we have an empty mysql-server package which depends on the recommended version of mysql-server-NN, and no transitioning occurs otherwise (similar to how linux-image is dealt with). Fine so far. the only problem was to get from sarge to this without leaving anyone behind, we had to grease the wheels for the 4.1 users a bit. ... who might habe been just as happy to continue using 4.1 ... and, if necessary, update to 5.0 manually later on. Anyway, it's done etc. so EOD. cheers -- vbi -- A real person has two reasons for doing anything ... a good reason and the real reason. pgpXnpXPhJWJn.pgp Description: PGP signature
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Wednesday 30 May 2007 22.46:30 Kris Deugau wrote: I've been writing custom utilities and libraries for various systems at work, and with one particular project recently it's become (more) important to know exactly which Debian release it's running on (at some stage or other between version-controlled-code and installed-binary) so that I don't try to call a missing binary or create a .deb that requires a package that doesn't actually exist in the target dist. In general: don't do that. My machine has base-files from etch and thus can be considered to be etch, but there are a lot of packages from lenny and sid on it (including libc6, thanks to the dependency handling). And if I don't reinstall the machine before lenny, it will even mix etch, lenny, lenny+1 and sid in a few years. So what version is installed on the machine? Version problems like you describe almost always boil down to versioned package dependencies. Obviously, if you're in a controlled environment and you know that your target machines are clean etch or lenny, the problem becomes a lot easier. cheers -- vbi -- featured product: GNU Privacy Guard - http://gnupg.org signature.asc Description: This is a digitally signed message part.
Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Friday 01 June 2007 20.51:27 Kris Deugau wrote: Instead, we try to make them work as far as their dependencies are met. ... which means what, exactly, if my program expects /usr/lib/apache2/suexec but the system (stock Debian sarge) only has /usr/lib/apache2/suexec2? Or vice versa for etch? Just make sure you depend on whatever version of apache that matches where you expect the suexec binary to live. Yes, you'll need to check for all such cases but it will get you much further than relying on /etc/debian_version because even people heavily mixing Debian releases will be happy. cheers -- vbi -- 24h Business Support: ... for example, when one of our products stops working, we'll blame another vendor within 24 hours. -- Scott Adams/Dilbert, 2006-06-13 signature.asc Description: This is a digitally signed message part.
Re: Bug#427297: ITP: sturmbahnfahrer -- simulated obstacle course for automobiles
On Monday 04 June 2007 14.20:46 Frank Küster wrote: Michael Welle [EMAIL PROTECTED] wrote: The german term 'Sturmbahn' as in 'Sturmbahnfahrer' describes a trail were you have to vanquish some barriers to train your physical fitness. [...] [1] and I'm german, not swiss as my sig might suggest to some Just some trivia since we're speaking about .ch ... it's Kampfbahn here. Never heard the combination with Fahrer, though. (I'm doing military service, but not on troops where the Kampfbahn is our business) -- vbi -- OpenPGP encrypted mail welcome - my key: http://fortytwo.ch/gpg/92082481 signature.asc Description: This is a digitally signed message part.
Re: Please all dependency info into your init.d script
On Tuesday 10 July 2007 20.04:38 Russ Allbery wrote: Toni Mueller [EMAIL PROTECTED] writes: Slapd may require an external SQL server if a suitable backend is defined, and I guess that a whole slew of other applications have similar problems. You should require everything you might use directly using the Should-Start stanza, which says that you should start after those services if anything provides them but that not having them available isn't an error. Hmmm. With slapd, for example, it's certainly possible where one scenario (slapd uses SQL database) directly contradicts another scenario (startup of SQL database uses auth info which is provided by slapd). Not sure how a packager should deal with this. (slapd being used only as an example. Other scenarios for other services are certainly possible.) cheers -- vbi -- featured link: http://fortytwo.ch/gpg/intro signature.asc Description: This is a digitally signed message part.
Find complete set of debs
Hi! [please cc: me. Thank you.] How can I (more or less efficiently - I do have a script but it's very crude and probably buggy) download all .debs (and for bonus points the source pkgs, too) that belong to some .deb that I have (same src package, same version)? cheers -- vbi -- So does the bible contain invariant sections? It sure does: $ bible rev22:18-19 -- Drew Parsons, in a GFDL debate signature.asc Description: This is a digitally signed message part.
Re: Find complete set of debs
On Friday 07 September 2007 09.48:36 Adeodato Simó wrote: * Adrian von Bidder [Fri, 07 Sep 2007 07:49:19 +0200]: No, all the other .deb packages that come from the same source pkg as the one I have. (But usually I only want i386 and all architectures.) Time to properly learn grep-dctrl, I guess, that's one tool I've completely neglected so far. I guess it should provide the info if invoked the right way. I guess the hard bit is the same version bit. Do you mean like downloading from snapshot.debian.net and stuff? Or is it assumed that versions you pass to the script will be present in the mirror's pull (i.e. stable or testing packages, or up to date unstable versions). The problem occurs right after I've installed some software, so all the necessary data is still available in current testing/unstable/wherever. cheers -- vbi -- OpenPGP encrypted mail welcome - my key: http://fortytwo.ch/gpg/92082481 signature.asc Description: This is a digitally signed message part.
Re: Find complete set of debs
On Thursday 06 September 2007 19.33:50 Neil Williams wrote: On Thu, 6 Sep 2007 15:45:28 +0200 Adrian von Bidder [EMAIL PROTECTED] wrote: How can I (more or less efficiently - I do have a script but it's very crude and probably buggy) download all .debs (and for bonus points the source pkgs, too) that belong to some .deb that I have (same src package, same version)? You mean each architecture? No, all the other .deb packages that come from the same source pkg as the one I have. (But usually I only want i386 and all architectures.) Time to properly learn grep-dctrl, I guess, that's one tool I've completely neglected so far. I guess it should provide the info if invoked the right way. cheers -- vbi -- If you look at debian it has included a qmail-src packet that does patch and changes your local copy of qmail to work as expected (i.e. not the qmail way). -- Anders Arnholm, 2001-08-28, OpenBSD ports mailing list signature.asc Description: This is a digitally signed message part.
Re: Bits from the Security Team
On Friday 19 October 2007 17.52:29 Steve Kemp wrote: I don't believe that post contains significant new information, (except that I like pies!), and as such I didn't believe it deserved massive visibility. That you like pies is important. Seriously: I think exactly this kind of not really much new stuff going on, but here's what we're continuing to do kind of information should be more visible, because it, too, is valuable information to somebody who is not involved tightly in the Debian teams. To the insider, it's obviously not important as they key people keep in touch anyway. Though in the specific case of the security team, the flow of security updates is an indication that the team is working (and I didn't want to imply that I felt the team was not working anyway!), so maybe your judgement was better than mine - it's not a case of wrong vs. right anyway. To be honest I'm a little disappointed that you chose to complain here about that, rather than commenting/mailing me personally. Could've cc:ed you at least. Apologies. cheers -- vbi -- featured link: http://www.pool.ntp.org signature.asc Description: This is a digitally signed message part.
Bits from the Security Team
Hi everybody, Allow me to point out the message at http://blog.steve.org.uk/articles/2007/10/19/as-i-move-on-through-the-year which is really a Bits from the Security Team. Why is - once again - a message that I'd consider appropriate for d-d, or perhaps even d-d-a (though I admit that the real information content is not extremely high. But still, it is information that Steve is active and outlines some of the problems and ways how people can help) hidden on a blog? Ok, not that hidden, it's on planet, but still. Fragmentation of Debian's communication infrastructure is something that seriously disturbs me because people being aware what the other people are doing is a big part of what defines a community. Next we're supposed to read, in addition to mailing lists, planet and IRC twitter, have an account on Debian's (yet to be created) open source xing clone and tune in to our SAT network radio channel which will be relayed through open source firmware modification in Iridium satellites, creating screams of anguish from the single but important developer living at the south pole where Iridium has no coverage. You get the picture, I'm sure :-) (Apologies if I'm just too quick and Steve posted his Bits to d-d or d-d-a but the mail just hasn't reached me or the mail archives yet.) cheers -- vbi [cc:s appreciated, eve though replies may not strictly be necessary] -- Oh, so you mean that we can both get a more secure system, *and* make emacs stop working? A win-win situation! =) -- David Weinehall on lkml signature.asc Description: This is a digitally signed message part.
Bug#607043: ITP: jwhoisserver -- Java Whois Server - a small whois server written in java
Package: wnpp Severity: wishlist Owner: Adrian von Bidder avbid...@fortytwo.ch -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +++ * Package name: jwhoisserver Version : 3.3.0 or newer Upstream Author : Klaus Zerwes zero-sys.net zero...@users.sourceforge.net * URL : http://jwhoisserver.net/ * License : Affero GPL Programming Lang: Java Description : Java Whois Server - a small whois server written in java Java Whois Server - a small, fast and highly configurable RFC 3912 compliant whois server written in java and using RDBMS (mysql,postgresql,hsqldb,sqlite,firebird) as a storage engine. +++ I'm currently working with Klaus and several friendly people on IRC to improve the package since I don't know dbconfig and Java, which the package uses. If somebody else wants to continue who knows more about the technology: don't hesitate, I'm not keen on maintaining this package. We're using it at work, so having it in Debian would be nice. Current status of my work is at https://fortytwo.ch/hg/pkg-jwhoisserver. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk0HKswACgkQKqpm2L3fmXqXtwCgjFLQ+VNKV8xcQ1mIY3U/Ckl2 ixMAoLroIAv7AH6n+AqZSylCzDbZOZj1 =rGqJ -END PGP SIGNATURE- -- 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/20101214082912.5924.3667.report...@localhost
Re: Bug#566126: ITP: openpgm -- Implementation of the Pragmatic General Multicast protocol
Hi Steven, On Thursday 13 January 2011 13.18:58 Steven McCoy wrote: A year later and I have a basic Autoconf/Automake system in trunk for OpenPGM ready to package for Debian. Nice to see progress, note that I'm not involved in zeromq packaging anymore (except to sponsor the odd upload) because I didn't follow up on my plans to do cool stuff with zeromq. So my interest on getting involved in openpgm packaging is similarly limited at this time. Still, it would obviously be nice to have openpgm available in Debian, so maybe somebody else is interested in working with you on this and/or sponsor your upload. cheers -- vbi -- featured product: the GNU Compiler Collection - http://gcc.gnu.org signature.asc Description: This is a digitally signed message part.
Re: Equivalent packages between Linux distributions
On Wednesday 19 January 2011 00.54:44 Silvio Cesare wrote: I have generated a list of roughly equivalent packages between Linux distributions (currently Debian 5 and Fedora 13). The list is automatically generated. Cool! Maybe I have missed a pointer or whatever: how did you compute this similarity? Number of identical files? Or filenames? I was just wondering: GSoC project: * run this after every release of a major distribution * add this info to aptitude/... : if I install a package that doesn't exist, add this to the search database (not sure what aptitude looks at right now, exactly, but it already has the infrastructure for proposing a package if the given name doesn't exist.) But please make this optional, on small systems apt already is only barely usable. cheers -- vbi -- to debug such lockups in the future you can do: ... NOTE: dont use the keyboard in this mode for too long, it can lock up. -- Ingo Molnar, lkml signature.asc Description: This is a digitally signed message part.
Re: does aptitude really need to lock the status database when downloading?
On Friday 04 February 2011 12.47:21 Fernando Lemos wrote: do, say, an apt-get upgrade, apt prepares an upgrade plan that uses a given set of packages. If apt wouldn't lock [...] new plan would have to be created, the user would have to be asked for confirmation again. Doesn't sound that great. If apt can (can it easily? Not sure) determine if the package db has not changed, this could be a noop for 99% of the users. Not sure if it's worth the complexity, thogh, I've only had this issue very occasionally. cheers -- vbi -- featured product: GNU Privacy Guard - http://gnupg.org signature.asc Description: This is a digitally signed message part.
Re: The node command in Debian
On Monday 07 February 2011 13.54:24 Henrique de Moraes Holschuh wrote: 1. they can declare a conflict with each other, so that the packaging system will never let both get installed in the same system. JavaScript and AX.25 sounds like it might be quite a distance in terms of people involved, although this is really just a guess. Start with a package conflict plus explanatory notice in README.Debian and move on to other measures if enough people complain, perhaps? Downside is of course that this discussion will probably repeated a few times. cheers -- vbi -- As we found out later, our activities had both saturated an uplink two hops up from our university, at the Nordic University Network level and made some DoS-alarms go off at the national level. All part of a fun release. -- serving Debian sarge and Ubuntu Breezy CD images http://www.acc.umu.se/~maswan/2005-12-10/2gbit-freesoftware.html signature.asc Description: This is a digitally signed message part.
Re: Qt3 removal rational
On Wednesday 09 February 2011 01.12:57 Lisandro Damián Nicanor Pérez Meyer wrote: Of course, we can simply orphan Qt 3, and hope somebody will step up to maintain it; we are unconvinced this is a responsible step for us to take as it would place the maintenance burden of a large package onto the QA team. If qt3 is really popular with scientific apps, which presumably are slow moving targets which are not esaily /quickly ported to qt4, it should be enough motivation for the people who need qt3 to take on the maintenance, so no need to burden the QA team. You need a piece of software, you do the necessary packaging work - it's that simple, at least in theory. cheers -- vbi -- Today is Setting Orange, the 40th day of Chaos in the YOLD 3177 signature.asc Description: This is a digitally signed message part.
Re: Kernel
Heyho! On Tuesday 08 February 2011 22.57:51 Pontus Andersson wrote: Hi. I like to make a request regarding the Debian Linux kernel. I think the tux boot should be compiled with the Debian logo.. With tux boot I mean that some distros e.g. Arch and slackware boots with the logo while displaying the boot process. As Paul has said, there is a patch to include the Debian logo at boot. As far as I know, the kernel still displays the traditional penguin at boot if a framebuffer is used, but note that on recent systems framebuffer has been replaced by kms which is loaded a bit later in the boot process and doesn't display any logo (either tux or the swirl with the patch.) -- vbi -- Fuyez un ennemi qui sait votre défaut. -+- Pierre Corneille, Polyeucte -+- signature.asc Description: This is a digitally signed message part.
Re: Bug#612694: ITP: scanmonitord -- scanner button daemon
Hi, On Thursday 10 February 2011 01.32:12 Jakub Wilk wrote: Description : scanner button daemon Scanmonitord is a daemon which runs device monitors on one or more devices. [...] I'm curious (and you might want to add it to the description): does this tie in with modern desktop systems via DBUS or whatever, or is this a standalone thing? cheers -- vbi -- The ants in France, stay mainly on the plants. signature.asc Description: This is a digitally signed message part.
Re: enable/disable flags in /etc/default
On Saturday 26 February 2011 21.44:07 Tollef Fog Heen wrote: I'd like us to decide on a policy about enable/disable flags in /etc/default in general. +1 on those who don't like to have them. The init scripts (or whatever) need to * provide a sane default for startup order * allow users to override this * allow for startup of a daemon to be (de)activated persistently (persistent over package upgrades, that is.) * and the package scripts (pre/postinst on upgrade especially) need to respect this (i.e. work in a sane way when the daemon is down, not leaving it started if it wasn't started etc.) * all documentation needs to be updated so that users finally don't end up doing silly things just so that mysql isn't started on boot[1]. I'm sure I forgot some, but I that are the ones I can just think of. The whole topic shouldn't be Debian specific. I have no idea, but isn't there an LSB or whatever spec? Where does it fall short? Who should be involved to get something that other distributions could use as well? -- vbi [1] Yes, I know, the mysql needs to be installed for kde but I don't want to run it case has finally been solved. Similar cases will keep coming up, I'm sure... -- Nirgendwo fällt Humorlosigkeit mehr auf als beim Lachen. -- Oliver Hassencamp signature.asc Description: This is a digitally signed message part.
Re: Potential memory leaks reported by Valgrind against some frequently used commands
Hi! On Wednesday 02 March 2011 03.38:42 Ron Johnson wrote: On 03/01/2011 06:19 AM, ximalaya wrote: Hi all, [snip] BTW, I ever tried on Redhat Linux 9, no such problem. This is the interesting part. Is RH keeping their patches, or are upstream and other distros just not determining them worthwhile? Or is it an eglibc libc issue? (Not sure what libc RH is using.) -- vbi -- Vertrauen ist gut. Anwalt ist saugeil. signature.asc Description: This is a digitally signed message part.
Re: Call for projects for Google Summer of Code 2011
On Wednesday 02 March 2011 10.43:44 Ana Guerrero wrote: Debian is applying as mentoring organization to the Google Summer of Code (GSoC) this year Dealing with the init scripts / service enable / disable mess. See current d-devel discussion. As much a discussion / social skills project as a coding project, so I'm not sure if GSoC is the right place. Or do it as a pure coding project, implement a proper set of tools, but then it's a question if it will be adopted into Debian in the end, which would mean wasted effort. (And please don't start discussion of the actual problem here, there's the other thread for this...) cheers -- vbi -- Jetzt ist der Herr Bush Präsident, und weil ihm wieder langweilig ist, will er endlich den Saddam loswerden. Der Herr Bush hat nämlich keine Praktikantin. -- http://bush.d0t.de/ signature.asc Description: This is a digitally signed message part.
Re: Speeding up dpkg, a proposal
On Wednesday 02 March 2011 17.02:11 Marius Vollmer wrote: - Instead, we move all packages that are to be unpacked into half-installed / reinstreq before touching the first one, and put a big sync() right before carefully writing /var/lib/dpkg/status. You don't want to do this. While production systems usually are upgraded in downtime windows (with less load), it is sometimes necessary to install some package (tcpdump or whatever to diagnose problems...) while the system is under high load. Especially when you're trying to find out why the machine has a load of 20 and you can't afford to kill it... On a machine with lots of RAM (== disk cache...) and high I/O load, you don't want to do a (global!) sync(). This can totally kill the machine for 20min or more and is a big no go. -- vbi -- featured link: http://www.pool.ntp.org signature.asc Description: This is a digitally signed message part.
