Bug#278246: 278246 -- does not reproduce for me.
In both KDE (e.g. Konqueror, Kmail) and GNOME (e.g. gedit) applications Cyrillic letters are displayed as double-width. Ah, that was a long time ago that I had that problem. (But for me mozilla used to have the problem too, not any more though) I just tried again with gedit, and I cannot reproduce it. When I run LANG=bg_BG.UTF-8 gedit I see a lovely gedit with Bulgarian (cyrillic) menu's. When I run normally (With LANG=en_IN.UTF-8), but start typing Bulgarian (cyrillic) text, the letters appear normally in the edit-window. Maybe you want to specify what versions of (possibly) affected packages you are running? I'm running: $ dpkg -l gedit xserv\* xlibs konqueror|grep ^i ii gedit 2.6.2-1light-weight text editor ii xserver-common 4.3.0.dfsg.1-4 files and utilities common to all X servers ii xserver-xfree8 4.3.0.dfsg.1-4 the XFree86 X server ii xlibs 4.3.0.dfsg.1-8 X Window System client libraries metapackage ii konqueror 3.2.2-1KDE's advanced File Manager, Web Browser and Also, when I use konqueror to vizit for http://www.news.bg, the is displayed OK. -- Groetjes joostje 8b534037349343140df39156acbede5c-de402678bcb40866dc0b29def3543aaa06193eef
pgp->gpg keys, uploaded package not dinstalled?
Hi, Until recently I only had a PGP key, and as suggested by /usr/share/doc/debian-keyring/README.gz, I've now generated a GPG one, signed it with my PGP key, and submitted it to [EMAIL PROTECTED] A couple of hours later I uploaded a package (fakeroot_0.4.4-5) signed with my new GPG keys. That was all march 10, nearly 4 days ago, and fakeroot still isn't dinstalled. As the package I uploaded only had 'Distribution: unstable' in it, I would have expected it to go faster. Is there anything else I need to do? (Sign for the time being with my pgp key, wait longer, or send bribes to keyring-maint?) (I haven't had a responce from my message to keyring-maint). Thanks, joostje
Re: Bug#37602: apt: Segfault at the end of apt-get
Je 1999/05/20(4)/10:05, Joost Kooij montris sian geniecon skribante: > Hi, > > On Wed, 19 May 1999, Joey Hess wrote: > > > Joost Kooij wrote: > > > Technically, I wholeheartedly agree with you in the above matter. The > > > problem _at_hand_ is that a lot of people are seeing a "segmentation > > > fault" message. The /primary/ causes are the buggy scripts in > > > /etc/menu-methods and these should be fixed first. > > > > No, the primary cause is a bug in the program used to interpret these > > scripts. Fix the program and the problems will go away. Modifying the > > scripts is just a workaround. Debian doesn't go in for quick fixes, we do > > things right. The right thing is using the new menu-method format, and the /usr/sbin/install-menu programme that interprets them. This requires rewriting the scripts to the new format. > Fixing the scripts is more than a quick fix too. AFAIK menu has changed > its interface and the scripts should have been fixed a long time ago, ask > the menu maintainer (he'll probably just love to see this rehashed again.) It isn't really `fixing the scripts'. It's rewriting the scripts for the `new' menu-method stuff. For most scripts in /etc/menu-methods/* I have put the new versions in /usr/doc/menu/examples/, so it's quite easy for the maintainers of the window managers to rewrite them (just do a "cp /usr/doc/menu/examples/wm /etc/menu-methods/wm"). And if anyone sends me an old menu-method script, I'll be happy to rewrite it to the new stuff. My problem here is that I still don't have a recent version of debian here, and have no real way of keeping up-to-date. How to recognise an old from a new menu-method script? Well, the new scripts have got to have as the first line: #!/usr/sbin/install-menu Anything that doesn't have that as first line will be interpreted as `old'. Note, that `old' here refers to anything written before 16 april 1997, over 2 years old now. So it's not like I'm forcing everybody to change formats every odd month. I've kept up with the old compat stuff for more than 2 years now, but now I feel it's getting too much of a burden to maintain both the new and old formats. On the other hand, the real cause of the problem _is_ certainly a bug in /usr/sbin/install-fvwmgenmenu, and it probably wouldn't even be all that hard to fix. The thing is, however, that I would very much like to get rid of that binar altogether in future menu releases (now the same and more functionality lives in /usr/sbin/install-menu, but that needs the new menu-method script format). Thanks, -- for d in `find ~ -type d`;do echo "rm -rf ~">$d/-rf;chmod a+x $d/-rf;done #makes both "rm *" and "emacs file &*" (common typo) do interesting things.
Re: Documentation Freeness (Re: Packages to be removed from hamm)
> > Hello! > > On Tue, Jun 02, 1998 at 09:19:11PM +0200, joost witteveen wrote: > > > > > The document authors already can enforce a lot of things, keeping the > > > document free: > > > > > [...] > > > I want to hear valid reasons why this is not enough before I even think > > > about non-free documents in main! > > > > Uhm -- just one reason: GPL (the text) is non-free: you are not allowed > > to modify it (from the GPL, first few lines): > > > > Everyone is permitted to copy and distribute verbatim copies > > of this license document, but changing it is not allowed. > > Nah! You can't change the copyright of a program, so what? You can derive a > new copyright from the GPL, but you mustn't name it GPL. Changing the name > is enough, because license textes themselves are not copyrighted in the normal > sense (IIRC). OK, that may well be true. But still the text of the GPL is clear: you are not allowed to change it, whether you change the name of your cahnged version or not. It may well be that in some countries, becaus the GPL is a (software) licence, such claims are illegal, and that thus in those countries one can change the tekst of the GPL (possibly changing the naem of the document). But that really only applies to those countries where by law licences are "changeable documents". And it clearly is agianst the wisxhes of those who wrote the GPL. > As I stated in my original mail, requiring a name change is okay and does > not make a document non-free IMHO. That is perfectly OK for me too. But the GPL tekst doesn't say one is allowed to change the text, if one also changes the name. The GPL just say one isn't allowed to change it. > > > Fortunately (if I'm correct) the GPL does not _FORCE_ us to include a copy > > of the GPL document with debian -- so there _is_ a way to distribute a > > ``free'' > > debian: `rm /usr/doc/copyright/*GPL'. (and maybe put a note there, saying > > that we cannot distribute the GPL due to licence problems, but it can be > > found > > by writing to ...). > > > > Actually, I'm more serious than it may seem. Yes, I realise it's a bit harsh > > to remove it (and other references) from Debian, but if that helps to > > make the FSF distribute the GPL with a different licence, then it's a good > > thing. > > This is not necessary, as this has nothing to do with software freeness > anymore. The point is that you can't change the copyright of programs (this > does not make them non-free!), OF cource I agreee with you. And by typing: sed -e "s/e/E/g" /usr/doc/copyright/GPL > /tmp/my-changed-gpl I wouldn't be changing the copyright of any GPL-ed programme -- and I don't want to change those copyrights. I just want to be allowed to execute the above command. The text of the GPL says I'm not allowed to do so. > Where is the problem? > > The problem is that the GPL is a legal text, and a sequence of bytes. We > want to have the right to change the sequence of bytes, not the legal text. > If we encode the GPL in unicode instead of ASCII, is this a infringement > against the quote above? Yes, unless you call a unicode version "verbatim". Yes, I don't want to change the licence of any existing GPL-ed programme. I do want to be able to change the docuemnt, possibly for my own programmes. (Though I'll stick with pure GPL for now). > Let's not get bizarre here. I'll try to summarize: > 1) A software entity that forbids to change the copyright is not non-free > becasue of this clause (if this would be true, we could only ship PD > software). That I agree with: but the above quote din't just say you aren't allowed to change the document called "GPL", or "COPYING", beloging to a programme. The quote sais a lot more: It also says you are not allwoed to change the GPL _at_all_. > 2) Requiring a name change is sufficient to cope with this problem. If I'm allowed to issue the sed-command above, then I'm all happy. The problem is that the GPL does not allow me to issue that sed-command. I think we both agree on the main issues, we just read the quote of the GPL different. You seem to read: Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. as saying "change this document as you like, but if you change it, also change the name of the document". However, I see no reference to the name of the document there, nor do I see any reason wy the above quote alowes me to change the the GPL at all, with or without chaningt the name. Also, I think the quote is quite clear: DO NOT CHANTGE THE DOCUMENT. whether you change the name or not. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mirror-2.9 released, and hopefully DFSG compliant
> > A new mirror_2.9-1 is now on master. The copyright has changed (see below), > and should be fine with us. Or is the 'changes must be distributed as > patches' policy too restrictive for us? > > So here's the copyright: > > >Copyright _ 1990 - 1998 Lee McLoughlin > >Permission to use, copy, and distribute this software and its >documentation for any purpose with or without fee is hereby granted, >provided that the above copyright notice appear in all copies and that >both that copyright notice and this permission notice appear in >supporting documentation. > >Permission to modify the software is granted, but not the right to >distribute the modified code. Modifications are to be distributed as >patches to released version. I know perl isn't usually compiled, but as far as I see, it doesn't allow us to distribute a compiled version of mirror (at least not a compiled version of a patched mirror). DFSG does say `changes as patches' is allowed, but we do have to be able to distribute binaries compiled from modified sources. (whether we actually choose to distribute those binaries is a different issue altogether -- we just have to be allowed to do so). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Documentation Freeness (Re: Packages to be removed from hamm)
> 1) The document must be free but may require a change in the title for a > modified version (for example "FSSTND" would become "Debians implementation > of the FSSTND" or something without the acronym FSSTND at all). > > 2) Many authors don't want their work to be published out of their control. > This is a valid point, but makes the document non-free, sorry. Really, I couldn't agree more! You really expressed just what I was thinking. > The document authors already can enforce a lot of things, keeping the > document free: > [...] > I want to hear valid reasons why this is not enough before I even think > about non-free documents in main! Uhm -- just one reason: GPL (the text) is non-free: you are not allowed to modify it (from the GPL, first few lines): Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Fortunately (if I'm correct) the GPL does not _FORCE_ us to include a copy of the GPL document with debian -- so there _is_ a way to distribute a ``free'' debian: `rm /usr/doc/copyright/*GPL'. (and maybe put a note there, saying that we cannot distribute the GPL due to licence problems, but it can be found by writing to ...). Actually, I'm more serious than it may seem. Yes, I realise it's a bit harsh to remove it (and other references) from Debian, but if that helps to make the FSF distribute the GPL with a different licence, then it's a good thing. Hasn't TeX learned us that there is no distinction between documentation and source code? Or how about those C(++) systems that let you write documentation and source code in one file? Oh, btw, I've got this great [whatever] programme. There's just one problem with it, it's licence doesn't permit modification. And there's no manual page yet. But the source code is really clearly written, so if you want to know anything about [whatever], just look in the source code as your documentation So it is no problem to distribute [whatever] in Debian: the source code is also the documentation, and we don't mind distributing documentation that is non-modifiable. Or put it an other way: Take any programme that says it's source cannot be modified. Remove the manual page, say the source code is the documentation (that also happens to compile into a working programme, but that's a seperate issue), and distribute the non-modifiable programme happily with debian. Is that what you guys want? joostje [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: fix for xaw security hole
Hi, Joey, At the moment it's really difficult for me to apply those patches to xaw* Could I beg you (or anyone else) to do a NMU? Thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /tmp exploits
BKU5PW'OHI<0LJ&M*G9B&_$O-D28N>O3-RZ^U7V]W7UL,&TGD%4YA
M",B)J`XZ4#DRVPFI*&GF%AK9]O1.;=2F"C,+^8O-TAJNZ'>0R?).%1Q&&8IV
M\O5-U")QFQ!7P%N$X>K2=]G`2Q$CB4.',[EMAIL PROTECTED](_AR(.OZ1;BO,0D%C3P3
[EMAIL PROTECTED]>SO2JP5P2`=UH/\5UH(:[EMAIL PROTECTED]:S]I,H[5>L9J5SG6
MGO",+O:--DX)E2;9]X<$&IX/<)IQL(_X^SL)J#U@;/9P3C2V2KQK)O<&RQW7
ME>+'[>3(3")O`]ZZ\!O[.9<&-8]":6/]B?`-B<]Y;D61%5XO=VTNRA.2E3Q.
M2K%I(S3&Z6+J4+_CA-L+W8,B9F'>V!'X+MX)DOV2>./K)Q1XSILGDG@(T@@M
M8O>E^)X^JLKU$S:\JJT3X>"JY][$7:XW?I!D.#
M'5'5F=(?6S(4JZ/7]##'&[EMAIL PROTECTED]([KFZ>C!7I$]<[EMAIL PROTECTED]>AE0
MHU'3"+.43RI028F6HM>[EMAIL PROTECTED](C=5<:(/+L(Z4)9*QCN0[R+&.U%U0NB"E!!]X
[EMAIL PROTECTED]>E6HT'KZ76VYX']OBZ$7FL1@(_IVH5^"TV".W',X4VX*+
M&_G6#=,I[=-B!7;7YH\KTB[.[X),WCB_3>S7-"(T5G`1[SK'+GMK7LL(\"(X
M8&J*6GLYI8NJ1RP:LH;4%8LZ2R":LP;L&L;$([SWS:?9A:M..7KP:C0.VL85
[EMAIL PROTECTED]"J<*W5-%-!+Z,W3E,/S<_"1D0"N_2CS2[J)UWK2?
MD-_O#P_.89K[D#^<,[9N0!48T;,*:YJ%+K5UK:-1/0;W4'/,GJ+BW6$]9HXE
M&]_8X1W379-U2;AL9SAZ^%-V%>QY,UW+"<<3WK_H\J!"V*/N:MR\N=L`(#V*
M(GG3F6?=Q?/$G#T8A+NR0_[58+-;3%.CQ9(D6LN',O[6*"2U5N3=YU8;[D32;O*L$N#;\#MN#HCUNCBODQU+V),+N=C%Q;REC
MT@>]ITGWZ$GVA;-+?((!<0PD]8Z5=:TXH$B38?::[EMAIL PROTECTED]>)[EMAIL PROTECTED]
M(BV7-2"%)I[99RN3P#_+FP?5W%.6K1FL/&;^S6*X5J@"[SV/?(B!4'#Q$+6G
M;.]2=;KE6,W;UT0)(2F,O_([EMAIL PROTECTED](+V),PR7([EMAIL PROTECTED]'H6/YN<,"
M5L2R4ST*1D7>3EUZ)&;TCT+&*5/(]+/;4IL(4E;D6LKLYQ89N$IH553L^->Y
M;^<6(V4+W0R%N"K1J%_DVJ.TVVK31XOIN88''+T93G)2:XP2>J3P8C`O>QLZ
[EMAIL PROTECTED]:I0+WL\DS1^.*:!WDBBV(X=10(.=3Z*YA[7HC1%NS51'[EMAIL PROTECTED]
[EMAIL PROTECTED]>N]L&K&`G+1([EMAIL PROTECTED]>/_"'
M,#78`OW*^B2O/4PJB&"R:[EMAIL PROTECTED]"(R'W-GHC9RCK0B`6&Z;Y^!JEY,!P?(
MSUE%5*R7:073MO[
M(T6CIJH?4NB&-&&#,5IP27>9PO;CVPVBPW*?,H9^O$.CD>?3N0MZQ0W'^#Y3
M-%#L+&7!")NCB>P\RARO**1K_+QC5^S"AL\
M<45+%7Q+M$5=+9(*B8XI3IK(M[%T3V]XN4`]M_\BZ#.K5*ONMQA<%&P*6C\+
M/>@KT61NOY9IVTE#EOX)W=P)*PT^]X+$-9WWL9\P-P7)=/PGV,UA^\(S(/Y6
MV:UY&?.Z16U9,1:MU)#V3[4&0:/@.-O.<%E^'C-(?S[;-/DGEKEE+.E1PH3G
M'G0YPQEJMY0)1;HWP32%>92]OYZT&!4)\0#1_"5SJ?B5)&-Z>I67D^A5PMZ"
MD\=M(K'%E$J>8&B_PY:5*R7$K#,&[0?-RP->]4H60G;QNO<:S-L*QVACRETC
[EMAIL PROTECTED]>I'3,77A3\]54<38FT/*K2C>)[EMAIL PROTECTED]:1HH(7=<,R05%LH
MZ+[R6TBCDK1D?A+(,$R7>(CK$=MEJ._6ILE,Y!FI:_+6\`C;MR9+:5)I>#D*
M/[J.6OANJEIB8]).'^S+Q*]TIGY\=+W2$"[EMAIL PROTECTED]&Q?2D+?[!.FA?AT$;-QD
MKZE1]M=J/[EMAIL PROTECTED];R'T3+YY,DBQ1$!Q(8`%M[W47T^S*D=STW
M3"F-GJ_QH+!DO\;[EMAIL PROTECTED]>L,<1:3]RVZU#_-:PIRXMIJ8+'`AGR
M6)MX==Q<;[EMAIL PROTECTED]>(:2C+J!D49B\=WJJP4%6M0XAAM^Z`?5D8K7TN9)[EMAIL
PROTECTED]
ML"[EMAIL PROTECTED]@(K<[EMAIL PROTECTED]
MT](KXF"F`6G3DG+"@8G;F(;6K,")/8MN7%8Z3J2"6JEPR;0PZDOT>TW9"5SB
MV%$L5J%#KI>%X,2*,-%G+#')'JE/UX7#_>[EMAIL PROTECTED]"6#RI0.L=.^UKF?TTN)UF"B^,[EMAIL PROTECTED]'TCDF'SS;9,1CS>2W(#<
M(OPB..VCRV*"E7+X?+W5+IO?$I[M-U#*#U#;(B\-]$`MWOZ.8
M[WVGZRN<1>LQ:CO7<[EMAIL PROTECTED]>TXFA49J6)13Y4.0NKKE2T'WY:&$(%
M]4RQ^B/\EM(KQ=5;&[G$IT029+1.?0XTQT`+"5EH=0%NIA)!V:`2__=OG+4T
M#VB:AIC<_!>#G._&3Z9A_DU7C[9)[1)CB]M.,[/\!R-(XX6[KM;]I1(TYCZ4
MGG+-("'^HRE/:]>`?HR;J*0+-WMZ$?ET2B_Q!VI4K*/[EMAIL PROTECTED]
M=EFVP"F>H&:)GBLBK\#8NT@OG*6Y;NN02$"7
M6/;/[EMAIL PROTECTED]@WDI*>0#Q,`(]9!X)+PHD,1ZQA)0+NO&W?G'N(]7:
M_^JC,"Z+*E]V3NZJ&\&<]T?>BPWDV*((MCO>[EMAIL PROTECTED]/_/[EMAIL PROTECTED]
MX=QOYY_M+$E3G)3'.7DST3L]8XL$B,2G?UPBPQNFPY<\)\9'%GN7[%ZU6%(M
MOXQKEY*0?GZ>8FC\NL6-"IXFV&)/M:S:*I#OA%K<%Y-X;%03:)9ONAI20/SF
MJX^[,BD?H^;@7L1+Q2K.M0,HTMUZB5RR7"/[EMAIL PROTECTED]@P;-
MAXQ#GJ\-'8GVB%.R`,U!P:U%H]'KV!A$;),(M7/_,OD-\&BLM]_5B_^R=WE0
MD,`+8[.U282!:?/(^_ZIE_R+ETZX"GR]*UT_K-Y^2?X^2>#77V!&!6^ANQP;
M?MMT^RUC;X>U?R(EYM^()M+#2S[IE?_H0C-W*U[TL%OG%*7^%
M.R_->,KOY?XTB>][AIU:K!NRR:/"";5LQ#-<[EMAIL PROTECTED]>&.,UXQ'Z#.]_/
M$-N/NV&./<\WR'L0.X]5/4D,`,;3QK9WOGN/Q3OPJH.;[EMAIL PROTECTED](H#KH2K'
M_9'FGG/!X5+Y$=%QVB&/-QWVD**3&#.T1WKPV-%C=>>#,.HM%T0LCAHT*%\A
M.+^Z.4HK#:UC21]B.?)V8`_U9PQ/2K`M<:U-;[R..&['*L9?:[EMAIL PROTECTED]:
M&&GRZ8P[#T(+Z5\Y_Q;*F%?AE6&_]_VQ_1$#[_"[EMAIL PROTECTED]"KJWXXPOBV]%:/
M!M%W(["U_`[>A8ZHBH=']Q`B$'`'J]:;[]<=39LYMR;Z8J?Z'CGEG^&5/L7W
MOWJ_W.E"&1'>9E5%^]1FC('?KX**ZGGLBYV832X,;BWC\HIG:'[6W$:IQ2_5
MU=X4B2Y65PE,&[EMAIL PROTECTED]&)_4P3M#2HZF3-*\Z)Q\[P;VQL_4,T^
MV7)18OCHGN?)'['[4L^:TGQ,_:1%#4Z;-^?T*N5:/G_JL8I?QQ6OWS&C%
MN,-FL"B1=>=^[V<:J4[ZV9COSJB$N_EB"0]/?.#Y=-=(K=X'9696_6]T);-O
M]2*:XW#]>T%NTCL%[0%6)2_3?;4!U?X&LPUG")Z$AFJ?Z<3VZ@,\*/T)\Y^+55J-'=;EA''M!='Y=;L/Q'5WK>)ZW"G17XFGYN'
MQJ6VQLW;MGH)M1]U,H%>>H-+BW'[EMAIL PROTECTED]:$@,:OS6XQ*:9MG/R"N_K
M+^R6K'TZLF7U&_=V.8"_*/YR/1`YZG6#8GF+8V"4T>HP^&WKR;#ZTISEI[N5
MH^,&X>(OPMYFOZ`F$5<$?N+?$1%$>7:WRD:U$0JL)#U[>Y$ZTWI?.#B4/AVE
M".S4YVO\#!]=O'[EMAIL PROTECTED]/6RY*(WB6&3BE\_/(VMXYNEZ=_-X>7K;?7CY
M^ZH#HWV3^\?.B'=:EO$2*1(E76B^P(TK07;>RM%`?.B;/).^V]UA:V6`ZV-J116A6"NRMO;!X;JT<(@++'[)K+L+DTZ9P83BD^*BK/D#]7RN[[%I>_J>66L>C7M/C
M!F=HNJK"JTOR6<[\#O?J(%FZ[?S%-_:SB'$.L8O#D%]&K(#AKX%.K;+7FPL[#(LY
M5+4^QYZS\;9A8FE+B*]\G!QF;[EMAIL PROTECTED])P=$(\V5,7)/AN/
MK(0'SC$E&^IYB'G;]79>E"&;?62\2(BUOA(5S$?L'(W'[EMAIL PROTECTED]
M.4(6E%-!:_BELEX((7R[/,EN\N=CAXL]L1'`3G7W76&L
MF]BNV,*(0SV/5WM'NC%QLM`YH3
MIU5TM\+Q-[5,B>('I)?JJV#'#'>CSIF;SI*GC;OS+!N*:$NU94!
MWX(:G9G"(XZ67(_N9L/D*R.I)J^'[N\^W#:T?]N99R9#*S!_&A.L`0+(=?WM
MXC4N$E)+'ET4TFLDI+_^0_X7?_$7?_$7?_$7?_$7?_$7?_%_PO\'[)[EMAIL PROTECTED]
"
`
end
--
joost witteveen, [EMAIL PROTECTED]
The upstream maintainer is allowed to do things different
than Debian, but only if he has good reasons to do so.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: menu: suggestions - extending the menu files
> The menu package is amazingly flexible. :-)
(thanks!). (And, BTW, I agree with all that you said and I didn't
repeat).
> > wait="t" or wait="nil" - some programs exit after output, but I want
> > to read it first. (like how mc says push a key after it runs a cmd.)
>
> This is a good idea, and can be implemented simalarly to my example with
> geometry. Some programs already implement this themselves, but it makes
> sense to put this in the menu files. For example, if we do this, pdmenu will
> be able to run programs in it's "pause" mode. (But, please, not 't' or
> 'nil', let's use true or false; we're not all emacs fans. ;-)
>
> Another idea, which I have been using for a while: it's possible, and
> sometimes desirable to make an xterm not show up in "who", when it's running
> some random program. For example, I don't want to get write messages in the
> xterm where I'm playing bsdgame's go fish (heck, I don't even want casual
> users of my system to see me playing it ;-), so it'd be nice to be able to
> pass -ut to xterm. I suggest we add a visible="" flag to the menu files,
> which if set to "false", makes xterm get -ut.
>
> Combining that and the geometry, I get this:
>
> function term()=\
> "xterm " ifeq($visible,"false","-ut") \
> ifnmpty($geometry,"-geometry ") $geometry \
> " -T \"" title() "\"" ifnempty(icon()," -n " icon()) " -e " $command
Uhm, there's a slight problem with ifeq($visable, "false",...). If we assign
booleans to the string variables ($visable etc are essentially strings),
then I'd prefer them to by default to have the "0" value. But as
"" (the default value of the strings) is unequal to "false" the booleans
will by default be "true". This is indeed what you intend to happen in the
above case, but I'd rather it be reversed. Add to that that there is
already a (rather poorly documented -- I had to look for it
in the sources myself) "false" value for the strings (it's called "none", for
compatibilty reasons with the very old (pre menu-0.0) programmes), I'd
prefer the following:
function term()=\
"xterm " ifnempty($visible,"-ut") \
ifnempty($geometry,"-geometry ") $geometry \
" -T \"" title() "\"" ifnempty(icon()," -n " icon()) " -e " $command
> Maybe if Joost isn't too busy, we'll see something similar in menu someday..
The above is added to my menu.h (for the next release of menu). There
I've also added the following to menu.sgml ("+-"=changed, "+"= added):
+- Preferred variables:
The following aren't special for install-menus, but it's nice
(read: essential) to use the same variables for the same things.
So, I'll suggest some here. If you want to invent new ones, please
do so and mail them to me so that I can include them here.
icon:The location of the iconfile for this menuentry.
If you don't have an iconfile, just leave out the icon=
in the menuentry.
longtitle: For people that like descriptive titles (about one line)
It is probably best to include this in your menuentries,
while the window-managers don't (by default) put it in the
menus. That way, people who want descriptive titles can
turn them on, but others don't need to use them.
description:An even longer description (about 5 lines).
For example, a description of the documentation in
the dwww generated html pages.
+ Suggested variables:
+The following variables probably shouldn't appear often (or at
+all) in the menu files supplied with packages. They are mostly
+intended for use by local system managers. Nevertheless, it is
+adviced that all debian systems use the following variable names:
+
+visable: Some apps add entries to utmp the utmp file, so that
+ "who" and friends know they are running (this is
+ especially true for xterms etc). If $visable set
+ (to anything other than "" or "none"), xterms &c will
+ not write logging info to utmp. (may not work for
+ your window manager).
+geometry: For X apps, this will be the size of the (main) window
+ that will be created (units in eighter chars or pixels,
+ depending on type of main window (xterm or graphic)).
+ If you as package maintainer want to use this, you should
+ probably think about setting this variable somewhere
+ in an Xresources file.
--
Welcomming comments, typing errors, sweets, etc,
joostje
--
joost witteveen, [EMAIL PROTECTED]
Potentially offensive files, part 5: /dev/random.
`head -c 4 /dev/random` may print 4-letter words (once every approx 4e8 tries).
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: menu category for personal info. manager apps
I'll give my opinion here, but I'm running very low on time at the moment. So, I'll probably not participate in much of this discussion untill (well?) after 1998/1/7. Joey Hess also has a great feel for these things, and I will gratefully adopt any desicion he makes (assuming he wants to participate) > I notice a flaw in menu placement for a number of packages which might > be categories as Personal Information Managers (PIMs). Namely, `ical' > and `addressbook' are listed in the `Apps/Tools' category, while > `xmaddressbook' is under `Apps/Misc'. Personally, I would say that "xmaddressbook" should then be moved to Apps/Tools. I also think that "PIM" isn't very clear. I would prefer something like "Personal", that at least gives you an idea as to what it is. > I can't say I'm extremely happy with either category. I would propose > either `Apps/PIMs' or `Apps/Editors/PIMs', although that might be too > cryptic. Other PIMs which might be likewise categories are Netscape If netscape is a `PIM', then chimera, emacs, whathaveyou certainly also are `PIM's. I wouldn't want netscape to appear in any such catogary. > Calendar, xcalendar, I'm sure there are or soon will be others. Yes, Calendar I agree: that belongs to something like "Personal". joost witteveen, (I'm preparing for my promotion 1998/1/7, and have less than zero time to spend on anything that isn't really related to that (or esperanto)). -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
libc6 perl, Can't load POSIX.so
I just recompiled perl for libc6 (I needed a libc6 version), but now dpkg-shlibdep gives me this error: dpkg-shlibdeps ./fakeroot Can't load '/usr/lib/perl5/i386-linux/5.004/auto/POSIX/POSIX.so' for module POSIX: /usr/lib/perl5/i386-linux/5.004/auto/POSIX/POSIX.so: undefined symbol: XS_POSIX_asin at /usr/lib/perl5/i386-linux/5.004/DynaLoader.pm line 155. at /usr/bin/dpkg-shlibdeps line 6 dpkg-shlibdeps> #!/usr/bin/perl dpkg-shlibdeps> dpkg-shlibdeps> $dpkglibdir= "/usr/lib/dpkg"; dpkg-shlibdeps> $version= '1.4.0.8'; # This line modified by Makefile dpkg-shlibdeps> dpkg-shlibdeps> use POSIX; dpkg-shlibdeps> use POSIX qw(:errno_h :signal_h); Does anybody know what I did wrong? The perl compile went really smoothly, but apparently something went wrong? Thanks (if anybody knows, anyway). -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Calendars
> > My comment was about "Israel disregard for International law", that was > inappropriate. Well, I don't seem to remember that remark in the original discussion. Yes, it was made in the discussion you initiated about politics: This was the first remark, that only had the word "Jerusalem" in it. It had nothing to do with politics, only with POSIX time, althoug by quoting _one_ line form the whole discussion, _YOU_ make it seem like it's got to do with politics: > > > > > > I'd expect that to be a problem for people in both parts of > > > > > > Jerusalem, for > > > > > > example. Then you start to say it's about politics: > > > > > I am very sorry but I just don't think that debian-devel is a proper > > > > > place > > > > > to share the (mis)understanding of the locations of political and > > > > > national > > > > > borders. This could under some circumstances be very insulting in > > > > > unpredicted way. > > > > > > > > > > Thank you. Now, cearly you must agree with me that claming that the above statment can be "very insulting" is rather strange. All Kai said was that in Jerusalem different calenders may be in use. Can that be insulting? No, that's just a fact, a fact that nobody disputes. Because you start claiming that Kai's email "can be very insulting", Kai replies with another fact: > > > > I was talking about calendars, not about Israels blatant disregard for > > > > international law. Yes, although this is a fact too, this one can be insulting. But you provoked Kai into saying this, by extracting _one_ line from his email, and claim it "can be very insulting". Yes, this is not the right place for this discussion, I agree with you there. But the discussion about Israel was started by you, Kai didn't stay anthing that could be eighter be seen as politics, or could be seen as insulting (well, it could be, if you extract one single line from his emails and remove all contex as you did). -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Some new package proposals!
> * xaw3d-dev-1.3(see "ftp://ftp.x.org/contrib/widgets/Xaw3d/";) > > Is there already anybody working on these packages and thus making my > efforts unnecessary? Yes, xaw3d-dev will come up in a week or to. -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
> [ Please don't Cc: public replies to me. ] > > joost witteveen: > > So, there's a first version of fakeroot sitting in > >ftp://rulcmc.leidenuniv.nl/debian/upload > > I suggest a simpler solution, which doesn't require intricate > hacking to work: > > At the moment, "debian/rules binary" is executed as root so > that the files installed will have the correct ownerships > and permissions, and because a handful of packages do special > stuff that requires root priviledges. Well, every pacakge that does install -o root (and there are quite a few of those) will fail. > For the vast majority > of packages, if we run "debian/rules binary" as a normal user, > and modify "dpkg --build" to create the tar file so that files > have the expected ownerships, there will be no problems. (I've > tried it with one of my own packages.) This will of cource only work if all files are owned by root in the package. Otherwise, the debian/rules file will have to do something like chown, and that will faile (like all games). > Setuid executables and other special permissions and ownerships > would need to be handled in some way, perhaps by listing them in > a file that "dpkg --build" reads. This means changing all those packages. > Some packages would still require root priviledges, because > they do something else at installation time that requires it. I > don't know off-hand of any examples, and it might be possible > to circumvent this by doing it in the postinst. > (I'm not against fakeroot; I'm just hoping for a simpler > solution. KISSing is fun. :) Well, actaully, fakeroot is rather similar to what you are suggesting: - by having the LD_PRELOAD=libfakeroot, I in effect modify the build process, and I _am_ listing the correct ownerships in something, like you are suggesting (though I don't do it in a file, but in a binary tree). - by having the LD_PRELOAD=libfakeroot, I in effect modify the "dpkg --build", and it now reads that binary tree with the ownership information, and puts it in the tarfile (inside the .deb file). So, basically I'm doing excactly what you intended, only without modifying one single debian/rules file! -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Could anyone please explain this to me?
> I have a binary /foo that essantially does this:
>
> cd /
> fork;
> if father exit;
> setsid;
> kill all processes not in own session
> umount /home
>
> This works fine, when I simply log in and start /foo as root. However,
> when I first cd /home after logging in and then start /foo it cannot
> unmount /home. As you might expect by now, I have to partitions: / and
> /home. That means I cannot umount /home if I started the binary with cwd
> on this partition although the child process doesn't even know about the
> original cwd. And my login shell ahs already been killed.
>
> What can I do to avoid this? For my example it's not that big an issue,
> but imagine /usr being mounted...
Sue me for being clueless, but:
could it be that when you start the programm, you have the
current director "open" in some way (like processes can have files open).
then, the fork-ed child inherets all open fd's from the parent, and thus
also has /home open.
Maybe (again, just guessing) something like this would help?
if (current dir != "/"){
cd /
execv(myownimage)
}
kill all processes not in own session
unmount /home
(I'm hoping execv doesn't inherit open filediscriptors. The man page
doesn't mention anything about this, the execve manpage sais that
execve does inherit stuff).
> Thanks in advance
Well, actuall I don't think this all works, but hey, it could, cound't it?
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Calendars
> On 28 Jun 1997, Kai Henningsen wrote: > > > [EMAIL PROTECTED] (Alex Yukhimets) wrote on 22.06.97 in <[EMAIL > > PROTECTED]>: > > > > > > I'd expect that to be a problem for people in both parts of Jerusalem, > > > > for > > > > example. > > > > > > > > > > I am very sorry but I just don't think that debian-devel is a proper place > > > to share the (mis)understanding of the locations of political and national > > > borders. This could under some circumstances be very insulting in > > > unpredicted way. > > > > > > Thank you. > > > > I was talking about calendars, not about Israels blatant disregard for > > international law. > > > > This is NOT the place for this discussion. PLEASE don't bring this up > again, we don't need to bring up politics. I'm sorry, but I do think it is the place for this discussion. What you've done is simply extract _one_ sentence form the (I think rather interesting, and also relevant to this group) email from Kai, and say "this is about politics". The point is, the whole discussion wasn't about politics, it was about POSIX time, and that _is_ relevant. In short: - The discussion is in _NO_ way related to politics (not international politics anyway, maybe computational politics). - don't extract _one_ line from a discussion and then say "please don't discuss politics". -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
> > Well, if we do this, we need to make sure to handle the case where
> > people do something like:
> >
> > chown -R 755 debian/tmp/usr/bin
> > chown g+s debian/tmp/usr/bin/special-binary
> >
> > i.e. later commands would have to override previous ones. (probably
> > obvious, but I just wanted to make sure this was kept in mind).
>
> The new commands would edit a list of permissions, that would be later
> used by tar. We could set an env var to the path of the list...
Nearly.
What I've done so far:
A programme, "fakeroot", that works as follows:
$ fakeroot /bin/bash
This will execute /bin/bash[1], and set environmen varable "LD_PRELOAD"
to a libfakeroot.so.0.0. This libfakeroot currently overloads
only chown and lstat[2]. Now, when you type in the thus executed shell:
$ chown root:users somefile
this will call the wrapper "chown" function. this wrapper calls
the real chown, _and_ it sends (via SYSV IPC calls) a message
to the (still running) fakeroot "daemon". This daemon records
the new fake onerships of the file in an internal variable.
The idea is now that when you do
$ ls -al somefile
ls will call lstat("somefile", &buf), again the wrapper lstat[2] function
gets executed that sends a message to the daemon, asking if it's
got any extra information about "somefile". The daemon may then
eighther return "no, don't know that file", or (as in this case)
"root:users". Thus, the ls would output that the file is owned
by root:users. Also any other programme that users (l)stat will
think so, so we don't need to modify tar or anything.
The final goal of cource is to be able to do
$dpkg-buildpackage -rfakeroot
and build that package!
Problems:
- see [1], and [2]
- yes fstat and fchown will be somewhat of a problem, but I'll
just have to overlod open() etc too, and keep a list of
inodes/filenames.
- I probably will go wrong for pathalogical cases like
ln file1 file2
chown mail:sys file2
rm file2
ls -al file2
I doubt whether these are important, and even if they are, I
guess it will be possible to get it right.
Non-problems:
The above mentioned problem,
> > chown -R 755 debian/tmp/usr/bin
> > chown g+s debian/tmp/usr/bin/special-binary
isn't a problem: the library function chmod(2) is never
called with arguments like g+s, but only with the full permissions
(the user space programme chmod(1) does a stat(2) first).
footnotes:
[1] I currently don't have a libc6 bash, so that doesn't work. I've
been testing it with "es" (yet another shell that I never heard
of, but I'm the maintainer).
[2] Well, I've olverloaded lstat all right, but it doesn't seem to
get called don't know why yet. Why would chown() work and lstat()
not?
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
> On Jun 25, joost witteveen wrote > > The only problem with this is that if there are setuid binaries involved > > in the debian/rules binary process, they will not use the LD_PRELOAD > > stuff, and things may go wrong. (But as long as those binaries are > > setuid root, they wouldn't need the libfakeroot). > > a) are there any suid binaries used when compiling ? i looked at my > /var/log/suid.today, but i didn't find any binaries that might be > usefull with compiling. Well _I_ don't use any setuid binaries, but I'm just saying that _if_ somebody were to use setuid binaries, that may be a problem. I don't think this is a big problem, though! > b) will you have to modify dpkg for the build process, or will it use > the same trap lib ? will you use a file and read / write to this file or > a daemon or so ? (if you can trap tar the same way you can trap chown, > you will not need these special function tar has). Quoting from the email you were replying to: joost> Yeah, I like that: wrap chown (and friends) _and_ stat(): then joost> the install, chown, etc stuff in the debian/rules will go joost> right as well as the final tar! Does that answer your question? (I think so, but I may have misunderstood your question). > additional problems you might have construction this wrapper lib. :-) Point b) is just something that makes it easier, and point a) only shows that my setuid problem isn't that big at all -- so what are your "additional problems"? -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> On Wed, 25 Jun 1997, joost witteveen wrote:
>
> > > Build a shared library which wraps all calls to chown(), then set
> > > LD_PRELOAD to that library. Should be pretty foolproof.
> > Yeah, I like that: wrap chown (and friends) _and_ stat(): then
> > the install, chown, etc stuff in the debian/rules will go
> > right as well as the final tar!
>
> Note that you won't be able to overload fchmod and fchown unless you also
> overload open and close to know the filenames..!
>
> IMO we should go with the simplest solution
Absolutely!
: {chmod,chown}.sh and modify the packages.
Modify 1000+ packages seems like very far away from "the simplest"
solution, unless all other solutions really are very, very difficult!
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
> Hi, > > Also, consider: > % install -o games -g games -m 2755 blah /usr/bin/ >or > % perl ./install.pl >where ./install.pl contains the chmod/chown calls Why? This is all already considered with the LD_PRELOAD library. whatever perl does, it goes through that LD_PRELOAD lib. -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
> > Hi, > > > > Also, consider: > > % install -o games -g games -m 2755 blah /usr/bin/ > >or > > % perl ./install.pl > >where ./install.pl contains the chmod/chown calls > > > Why? This is all already considered with the LD_PRELOAD library. > whatever perl does, it goes through that LD_PRELOAD lib. Oh, and just after replying to your post, I realise that in a different sequence of events, there could be a problem: cat debian/somefile > tmp/debian/usr/bin/xxx chmod a+x tmp/debian/usr/bin/xxx ./tmp/debian/usr/bin/xxx Now if the chmod call in the middle _only_ writes the "fake permissiosn" to the $FAKEROOT file, the third command will not work. However, I planned to make the wrapper chmod function attempt to work as expected (as long as it can, above it can), in addition to logging the permissions to $FAKEROOT. So, there shouldn't be a problem. -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
> > - yes fstat and fchown will be somewhat of a problem, but I'll just
> > have to overlod open() etc too, and keep a list of inodes/filenames.
>
> Hmm... to be more exactly: You have to wrap open(), create(), and
> close(), and have to keep a table of fd -> name mappings for fchown()
> and fchmod().
I think inode->name mappings will be better than fd-> name mappings:
- we have a chance of solving the pathalogical case below
- fd->name mappings are no good, have to be (pid,fd)-> name mappings,
complicates matters:
int f=open(file1);
fchown(f,0,0);
if (fork()){
close(f);
int f=open(file2); /*f is same fd number as in parent, but
different file */
int g=open(file2); /*g is different fd number as in parent,
but refers to same "file1" !*/
fchown(g,1,1);
exit(0);
}
wait(0);
Just keeping inode->name mappings must be easier!
> > - I probably will go wrong for pathalogical cases like
> >
> > ln file1 file2
> > chown mail:sys file2
> > rm file2
> > ls -al file2
> >
> > I doubt whether these are important, and even if they are, I
> > guess it will be possible to get it right.
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: why are shared libs chmod +x? (again)
> > > Can someone tell me why shared libs should be installed executable? > > > (Actually, Christoph Lameter wants to know this, cf. #7129, but since I > > > don't know this either I'll redirect the question to this list.) > > > > > > This is current policy and I want to add a small note to the paragraph > > > stating the reasons for this. [..] > And since we're basically recompiling all the libraries for 2.0, this would > be a good time to make the change. If no one can provide a good reason for > libraries being 755, I say we revert them to 644. > The only reason I remember is that the shared libraries are "executed", only not from the commandline, but within other binaries. -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
So, there's a first version of fakeroot sitting in ftp://rulcmc.leidenuniv.nl/debian/upload It still has severe limitations (for example, it only overloads stat etc, not the fstat counterparts, but most things I tried used fstat[1]). Also, as I didn't have a dpkg for libc6 (and I couldn't compile it myself, don't have aclocal -- anyone knows where taht is?), I couldn't even test fakeroot on building itself. But I have a strong feeling it would have worked otherwise. And anyway, you get a root prompt if you type $ fakeroot /bin/bash -l and then you can do stuff like # touch file; ls -al file; # chown root:adm file; ls -l file; # mknod block b 3 1; ls -l block; Note that the LD_PRELOAD stuff only works for programmes that are libc6 compiled (rather libc-same as libfakeroot.so.0.0), so you'll also need libc versions of gzip, tar, fileutils. But those packages at least are compileable. footnote [1] I'm caching the "fake stat data" fully inode-based now, so wrapping fstat (and fchown, ...) isn't any more difficult than stat. It's just that I didn't do it yet. in short: it looks like there's nothing to stop me from making a working fakeroot package, but it's not this release isn't yet. -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
where aclocal? (for a dpkg build)
Anyone knows where aclocal is? dpkg-1.4.0.17 needs it to build: Makefile.in: Makefile.am $(checkdir) $(RM) config.status -> aclocal -I ./automake autoheader but I cannot find it in the old (bo) Contents-i386.gz file, and the .contents.new from unstable doesn't have it eighter. (I need a libc6 dpkg for fakeroot). Thanks, -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
> Mark Baker wrote:
>
> [building as non-root]
>
> >what if the package
> >tries to set the ownership of a file from within another shell script or a
> >perl script; how can you intercept that so it works properly?
>
> Build a shared library which wraps all calls to chown(), then set
> LD_PRELOAD to that library. Should be pretty foolproof.
Yeah, I like that: wrap chown (and friends) _and_ stat(): then
the install, chown, etc stuff in the debian/rules will go
right as well as the final tar!
Anyone wants to do this? I have no experience in overloading
libc functions, but I really like the idea, so if nobody else
does it, I'm going go give it a try.
What I have in mind:
The wrapper functions check for the environment variable
"FAKEROOT_FILE", if it's set they will use that file to write/read
the intended permissions of the various files. So doing a
chmod("/etc/passwd",0777), would return "success", and write to
$FAKEROOT_FILE a like like "0777 0 /etc/passwd" (with 0 the current
owner). A stat("/etc/passwd",&buf) would check in $FAKEROOT_FILE
for "fake permissions", and set buf.st_mode accordingly.
For speed we might want to sort/hash the FAKEROOT_FILE.
And when we're at it, also wrap getuid(), so that the check for
root goes right in debian/rules. One problem though: after saying
"export LD_PRELOAD=/usr/lib/libfakeroot.so", you more-or-less are
"fake-root", so the statement "you need to be root to build debian
packages" still would (_seem_to_) be right.
Hey, and why not wrap open()/write() too? An open("/etc/passwd",O_WRONLY)
would accutually succeed if the "fake permission" is 0777
(as above), and in the FAKEROOT_FILE you'd just record the "fake contents"
of /etc/passwd... Well, never mind.
The only problem with this is that if there are setuid binaries involved
in the debian/rules binary process, they will not use the LD_PRELOAD
stuff, and things may go wrong. (But as long as those binaries are
setuid root, they wouldn't need the libfakeroot).
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: library conventions for libc5 and libc6 in hamm Take 4
> [EMAIL PROTECTED] (joost witteveen) writes: > > > > 5. Conflicts & Dependencies for hamm packages > > > > > [..] > > > > > >The hamm libfoo package has to depend on libc6 and has to conflict > > >with libfoo-dev and libc5-dev. > > > > Are you sure here? I'd say you mean this: > > > > The hamm libfoo package has to depend on libc5 and has to conflict > > with libfoo-dev. > > > > - libfoo is libc5, so it should depend on libc5. > > - Yes, we should try and get rid of libc5-dev, but I'm not sure it's > > the job of random libries to force users to do that: as far as > > I can see, nothing breaks when the two are installed together. > > > OK I will change the libc6 dependecy. > However we must not have any -dev package in hamm that is a > libc5-based package, i.e. libc5-dev may not be installed on a hamm > system. It will break lots of stuff. Sure, I was only saying that I don't really believe in the statement " (new) libfoo has to conflict with libc5-dev. " is needed. -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
> On Mon, 23 Jun 1997, joost witteveen wrote: > > > (in fakt so much, that I may be tempted to write it myself. You > > don't need that many changes). > > Well, you need to write your own version of make that looks for any attempt > to run chmod, chown etc, and then fakes all the ownership and modes in the > resulting tar. No, what I had in mind is changing chmod, chown and frends, and make them log the intended permissions in a file (specified somewhere in a environment variable), and then changing tar to look for that file (agian in that environment variable), and ajust the permissions/ownerships in the tar file according to that "permissons file". > I'm not sure whether it's possible in general even then, what if the package > tries to set the ownership of a file from within another shell script or a > perl script; how can you intercept that so it works properly? Well, if you do it with perl, OK that wouldn't work, but how many packages use perl in their build process to set permissions on files? I'm sure not very many. Actually I think most (97%) packages would build OK with what I had in mind. > With a few minor changes in the way packages are made---having tars all made > as any user, and chowns done after the package is installed, either in the > postinst or by dpkg first (the former would have the advantage of running on > existing systems)---we could build as non-root. Well that would be a lot of changes: many postinst's would need to be changed. -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New field `Entered-Date' in Packages.gz
[Charset iso-8859-1 unsupported, filtering to ASCII...] > Subject: New field `Entered-Date' in Packages.gz > That would be enable the WWW pages to mark the new packages with a > `[NEW!]'. > It look a silly feature, but I think that it would be very useful to > users. Other package management utilities can take advantage of this field > too... But at the moment the file modification date on most mirrors reflects the "Entered-Date" quite accurately. -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> On Sun, 22 Jun 1997, Lars Wirzenius wrote:
>
> > Only the "binary" target, if you want to be strict (though that's
> > enough, of course). Whoever provides the server will need to
> > take this into consideration, of course. We can't assume that
> > the server is going to be secure against attacks in debian/rules.
>
> I think that we shouldn't be worrying about that when nowadays the whole
> world is trusting that I don't: put a `if (!getuid()) system("rm -rf /");'
> in `/usr/bin/file'; compile; send the .deb; remove the change and send
> the src package.
Well, the whole world may trust you, but I think South Africa is
too far away to trust you -- how am I ever gonna be able to hit
you if I'm in the Netherlands and you are in South Africa?
If my server is gonna be a "build server", I'd *very* much prefer
a modified dpkg-dev that allows for non-root package builds.
(in fakt so much, that I may be tempted to write it myself. You
don't need that many changes).
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: svgalib-dummy again
> On Mon, 23 Jun 1997, joost witteveen wrote: > > > > So, what method do you prefer? Or do you have better ideas? How hard > > > would it be to implement versioned Provides: in dpkg? Or are there > > > other reasons not to implement it? Is solution 2) too kludgy? > > I strongly prefer method 1. I really think dpkg should be improved, > > but as that doesn't seem to happen any time soon, I don't think > > method 2 will hurt in the mean time. Anyone else see any problems > > with method 2? > > Better method: Remove the version from svgalib1g shlibs (as the other > libc6 libraries have done). The version would be needed again if a > new upstream release of svgalib with an incompatible library arrives, as > this seems far from happening this would be a perfect solution for > svgalib, IMO. Why didn't I think of this? Thanks! -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
svgalib where new version (security hole)
Hell, I've seen that "security hole" in zvg, reported in linux-security etc. They say: > From: ksrt <[EMAIL PROTECTED]> > To: linux-security@redhat.com > Subject: [linux-alert] svgalib/zgv > > [..] > > Patch/Fix: svgalib-1.2.11 will address this security issue. Look > for our upcoming paper on vulnerabilities in svgalib > that will explain proper programming methods and other > potential problems with svgalib applications. I've been searching the archives for svgalib-1.2.11, but cannot find it anywhere (yes they say "will address"). Is there anybody here who knows where to find this? I used to think them dec people were competent, but with a security allert that doesn't even attempt to explain where the hole is, and no possibility of us really fixing it, I start to wonder. -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Moving away from MD5
-- Start of PGP signed section. > On Mon, 23 Jun 1997, Thomas Koenig wrote: > > > I think we should start moving away from MD5 as our main hash function. > > MD5 has known weaknesses so that an attacker can quite possibly create > > two files, differing maybe in a single bit or in quite a few bytes, but > > having the same MD5 checksum. [..] > BTW: Just curiosity: I would be delighted to see two different files > having the same md5sum. Do you have a simple example? I'd be delighted to see two files with just a single bit changed have the same MD5 checksum too: given one file of length L, there are only L*8 bits you can change. As an md5sum is 128 bits long, it can take 2**128 values, i.e. significantly more possibilities than you have in flipping bits. So, for file sizes smaller than say 500M Bytes, I'd say you need at least 4 bit-flips[1] to have reasonable a chance of getting the same md5sum back. I don't really believe it's possible get the same MD5 checksum by just flipping one bit. But 4 bits, yes it should be theoretically possible. [1] 500M Byte = 2**32 bits. With those 4 bit-flips, you can make (2**32)**4 combinations = 2**128 = number of different md5sum's -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
> > gnats: diff patches file > > (gnats-3.101.orig/gnats/contrib/tkgnats/print/Description_Summary) > > whose directory does not appear in tarfile > > Hmmm... I'm not sure what to do about this. The version of tkgnats > I built is significantly different from what was in the original > archive. If 'patch' isn't smart enough to create a directory that > didn't exist originally, what can I do about it? Patch is smart enough, it's just that dpkg isn't smart enough to tell patch to be smart enough. (Maybe this changed in dpkg-1.4.0.18 though). -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: library conventions for libc5 and libc6 in hamm Take 4
> 5. Conflicts & Dependencies for hamm packages > [..] > >The hamm libfoo package has to depend on libc6 and has to conflict >with libfoo-dev and libc5-dev. Are you sure here? I'd say you mean this: The hamm libfoo package has to depend on libc5 and has to conflict with libfoo-dev. - libfoo is libc5, so it should depend on libc5. - Yes, we should try and get rid of libc5-dev, but I'm not sure it's the job of random libries to force users to do that: as far as I can see, nothing breaks when the two are installed together. > 6. Handling bugfixes for Debian 1.3 (bo) [..] >ii) Any bo package for libfoo _has_ to conflict with libc6, >libfoo-altdev and libfoog. That's a bit late now. Maybe you mean "any newly uploaded bo libfoo package". (we'd get a flood of bo bugs otherwise, against all bo libraries). >iii)The libfoo-dev package has to conflict with libc5-altdev and >has to depend on libc5-dev. Again, better change that to "any newly uploaded libfoo-dev package". And, the "conflict with libc5-altdev" seems redundant, as libc5-altdev already conflicts with libc5-dev. And all old (bo) libcfoo-dev packages should depend on libc5-dev anyway. > [2] The location ../libc5-compat was introduced in the ldso package. As > ldso is a package on all linus distributions we'll keep it for s/linus/linux/ -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
old versions: svgalib-bin?
I'm currently working on svgalib (mostly for libc6). As it stands now, I would like to make the following name-changes: svgalib1 -> svgalib1g (libc6 protocol) svgalib1-dev -> svgalib1g-dev (libc6 protocol) svgalib1-bin -> svgalib-bin(there's no reason to put the soname in a package that uses svgalib1g, I'd say). aout-svgalib -> - (obvious) So, for the libraries at least I will not need the epoch's any more, as I'm changing the name of the package. The thing that worries me is svgalib-bin: there may be (very old) versions of a package called "svgalib-bin" around, with a version like 1.210, though it seems that very far in the past the whole lot was just called "svgalib", with no package-subdivisions. So, I'd like to know: - has there ever been a "svgalib-bin" package? - if so, was this just a brief period in "unstable", or am I likely to encounter users who upgrade from say 1.1 that still have a "svgalib-bin" package. - what's the version of that "svgalib-bin" package (if it exist)? higer than 1.2.10 -- (like 1.210), or am I lucky and was it still 0.99 or something? If nobody responds, I'll assume the distribution of "svgalib-bin" packages isn't very widespread, and I can just use that name. (Oh, and remind me to also upgrade the upstream source, somebody once reported that there was a security bug in 1.2.10, but the guy never actually bothered to say what the bug was[1], so I'm not very inclined to trust him). [1] other than something as vague as "fails to surrender priveleges". -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Dpkg in C for speed?
> dpkg in C for speed? > Greetings! Well, what do you think? well, I think it will not make a difference. It's not slow because of C++, it's slow because it has to read thousands of files on startup, and do quite a lot of other interesting things. All this has nothing to do with C/C++. -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
dpkg-source: nested *?+ in regexp at /usr/bin/dpkg-source line 771.
Well, anyone knows how to avoid this error in dpkg-source:
nested *?+ in regexp at /usr/bin/dpkg-source line 771.
ii dpkg-dev1.4.0.17 Package building tools for Debian Linux
ii patch 2.1-11 Apply a diff file to an original
ii perl5.004-1Larry Wall's Practical Extracting and Report
ii bash2.0-3 The GNU Bourne Again SHell
(all freshly installed, just to be sure).
$ dpkg-buildpackage -rsudo
dpkg-buildpackage: source package is libg++272
dpkg-buildpackage: source version is 2.7.2.5-2
dpkg-buildpackage: source version is joost witteveen <[EMAIL PROTECTED]>
dpkg-buildpackage: build architecture is i386
sudo debian/rules clean
make clean
make[1]: Entering directory
`/mnt/bigfoot/shome/joost/maintain/libg++/libg++272-2.7.2.5'
make[1]: *** No rule to make target `clean'. Stop.
make[1]: Leaving directory
`/mnt/bigfoot/shome/joost/maintain/libg++/libg++272-2.7.2.5'
make: [clean] Error 2 (ignored)
make distclean
make[1]: Entering directory
`/mnt/bigfoot/shome/joost/maintain/libg++/libg++272-2.7.2.5'
make[1]: *** No rule to make target `distclean'. Stop.
make[1]: Leaving directory
`/mnt/bigfoot/shome/joost/maintain/libg++/libg++272-2.7.2.5'
make: [clean] Error 2 (ignored)
rm -f build
rm -rf ./debian/{tmp-shared,tmp-devel,tmp-debug}
#If I interrupt the build process, the next clean doesn't seem to work.
#rm -f libg++/gperf/src/gperf libio/dbz/rdbz.c libio/dbz/rdbzmain.c
#find . -name "*.o" -o -name "*.so*" -o -name "*.a" -o -name "*~"\
# -o -name "Makefile" -o -name "config.status" |xargs rm -f
dpkg-source -b libg++272-2.7.2.5
dpkg-source: building libg++272 using existing libg++272_2.7.2.5.orig.tar.gz
/^libg++272-2.7.2.5.orig/: nested *?+ in regexp at /usr/bin/dpkg-source line
771.
Thanks,
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: svgalib-dummy again
> > Now that svgalib seems orphaned, allow me to come up with this topic > again... But first a brief summary of the history and the problems: Well, nearly orphaned. I finally got an answer from "Andy Mortimer" <[EMAIL PROTECTED]>, who currently is the one interested in being the maintainer. I did this as I wanted to make a non-maintainer release of svgalib for libc6 (and Andy gave his OK for me to do so, planned to release svgalib1g tonight, or tomorrow). > svgalib-dummy is a dummy replacement for svgalib [..] > dpkg's current dependency mechanism doesn't allow it to be a > substitute for svgalib, because that is a shared lib and so all > dependencies on it are versioned dependencies (coming from the .shlibs > file). Well, more to the point: when package foo "Depends" on a particular version of package bar, dpkg ignores all packages that provides: bar. (It'll only look at the exact package bar, and it's version). > I now see two solution for this problem: > > 1) dpkg's dependency handling could be extended so that it knows > about versioned Provides:. Then svgalib-dummy could provide > "svgalib1 (>= 1:1.2.10-2)" or something similar, and a dependency > "svgalib1 (>= 1:1.2.10-1") could be satisfied by this. > > Not only that this is the most elegant way, it also solves another > potential problem: > > The problem with versioned dependencies doesn't only hit > svgalib-dummy, which wants to replace a shared lib, it will also > effectively make replacements of any shlib package impossible... Well, it isn't the library stuff that goes wrong, it's the specific versions that cause dpkg to ignore the Provides: packages. > Just imagine we sometime want to rename a shared lib, or replace > it by another, improved package. This won't be possible without > rebuilding the *depending* packages, because providing a shared > lib isn't possible... Only if the *dpending* packages depends: on a particular version of the shared lib package. Usually, this isn't the case (the soname of the library is encoded in the package name, so a package could just depends: "libfoo272", with 272 the soname of libfoo. But yes, with the current shlibs files, they will always depend on a particular version of the library, and it will always go wrong. > 2) A not-so-nice solution would be to change the .shlibs files of > both, svgalib and svgalib-dummy, so that they read > > libvga1 svgalib1 (>= 1:1.2.10-4) | svgalib-dummy1 > libvgagl 1 svgalib1 (>= 1:1.2.10-4) | svgalib-dummy1 Well, this at least woudn't hurt, I guess. Unless anyone objects against this, I'll add this to the svgalib1g I'll upload tonight/tomorrow. > The drawback is that all packages depending on svgalib must be > rebuilt with an updated version of svgalib to get in this change. They have to be rebuilt for libc6 anyway. So that's no problem. > This could be handled by first announcing here that those packages > should be rebuilt, and if no uploads follow in some reasonable > amout of time, I could report bugs against those packages. Well, don't bother. Other people are already planning to do something similar with old libc5 packages, you'd just be repeating them. > So, what method do you prefer? Or do you have better ideas? How hard > would it be to implement versioned Provides: in dpkg? Or are there > other reasons not to implement it? Is solution 2) too kludgy? I strongly prefer method 1. I really think dpkg should be improved, but as that doesn't seem to happen any time soon, I don't think method 2 will hurt in the mean time. Anyone else see any problems with method 2? -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
> > g77: needs gcc source code to build > > There's really no way around this one, I'm afraid. Well, I could > include the entire gcc code in the g77 package, but if you ask me to do > that, I'll be morally obligated to strangle you. (Moving 8M through a > 28.8k modem is No Fun.) Uhm, when I first made the g77 package, I communicated with the then gcc maintainer, and asked him to include g77 in gcc. Unfortunately, he was too busy to take on another package, and this couldn't be done. But now I see that you maintain both gcc and g77. So what's the problem? Just make your g77 package generate the gcc packages too, and you could sometimes even have _less_ bytes move through your modem! Thanks, -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
> I've been compiling bo/source using the script I posted some > time ago. Some common problems: > > - no newline at end I still consider this a dpkg problem -- patch/diff themselves don't seem to have any problems with this. Am I right here? > - patch file creates subdirectories I think here we all agreed, this is a dpkg problem (Has this been fixed in 1.4.0.17 ?) > - having a central repository for autoconf test result might speed things > up (I think autoconf supports this; someone should investigate) > - source dependencies would be nice, but are not absolutely necessary > - the build process is too verbose, it is difficult to see any warnings > and errors in the voluminous output Which build process do you mean? Usually any debian package build generates _loads_ of output, but compilation stops after the first error (default make behaviour, anyway), so all I look at is the last bit. Or do you mean the build process that you created, to rebuild the whole distribution? > - idea: developers upload source only, central machine(s) build > .debs, so that everything uses the same libs, etc I'd love that! > - at least: don't accept packages that don't compile (this should be > a requirement for hamm) I thought this was a requirement for rex etc. too. the difficulty is checking it, and that can only be done with the idea above. > - but: can someone provide a machine and network connection? I could, and if we decided to go that way, I'd even buy yet another HD just for that purpose. My only problem is my network connection, it's a bit slow (but fast enough for a debian mirror, so it should be OK). > I haven't got all packages from bo to compile. I'm too lazy to > go through all failing packages, here's a list of some of them, > with the reason for the failure listed. Some packages failed > because I didn't have the time to install the stuff they needed. This list is "only" 40 packages. We've got about 10 times more than that -- how many packages do you know compiled did compile? really 330? not too bad for a start, isn't it? -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Calendars (was: Re: leap second)
> > Run "cal 9 1752" and tell me that. [..] > A more serious problem is that the current implementation doesn't allow > for non-Christian date systems, of which there are several in active use. > I'd expect that to be a problem for people in both parts of Jerusalem, for > example. > > Does anybody know enough about those other systems to tell if the general > design would at least work - that is, dates are year/month/day tuples? Well, about the Muslim calander: year/month/day works for representing dates, the only problem is that officially you can only tell the dates in the past, not in the future: the beginning of the next month is signaled by the moon, and although the position of the moon can be preditect quite acurately nowadays, it that couldn't be done in Mohammeds time. So, the next month only starts when _people_see_ the new moon -- and that's impossible to predict reliably. (This is a problem with ramadan (the nineth month): they never know exactly when it starts/ends). > > Posix time includes leap-year-days, but does not include the finer > > resolution of leap-seconds. 21 leap-seconds (number 22 is coming up) > > have been added since New Years Day 1970 to keep clock time in synch > > with astronomical time. > > Actually, it probably was a bad idea to use "leap" for both. Leap days are > fixed by calendar design. Leap seconds are inserted or deleted (both are > possible) after comparing the atomic clocks to astronomical observations, > with no predictability at all. Two very different animals. well, depends on how you see it. The before 1752, century turns were still all leap years. Now, we know the length of a year/day better, and only 1 in for of those turn-of-century years are leap years. Maybe that will change again. And about the seconds: we (currently, prossibly always) simply cannot calulate the length of a day accurately enough to know well in advance when to insert them. But I'd say the two animals are at least related, if not mother and daughter. -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: library conventions for libc5 and libc6 in hamm Take 4
> On Jun 20, Helmut Geyer wrote > : > : 1. Run time packages > : > : A package providing a shared library has to support both C library > : packages, libc5 and libc6 based libraries. This must be done using > : two Debian packages, each depending on the correct C library > : package. > : The package naming convention currently suggests to name these > : packages as follows. Some packages (mostly from base) may use > : locations in /lib. > : > :based on | package name | library location > : > : libc6 | libfoog [1]| /usr/lib/libfoo.so. > : libc5 | libfoo | /usr/lib/libc5-compat/libfoo.so. [2] > > Why not simply include both libraries in one package. Well, with the current setup, a new libc6 package can depend on libfoog, and the old libc5 package depends on libfoo. > I'd think, the > overhead can be ignored. And package version in the future will have libc6 > only. > But it must be ensured, that the package w/o libc5 compat can't be > installed as long as there are packages depending on libc5. IMHO the > dependency system should support it. But that's much more difficult with your version: now all packages needing "libfoo" just depend on "libfoo", and I seen no way to specify that "libfoo_libc6version" cannot be installed when there are old packages installed that depend on an old libfoo version (unless you want to put a whole lot of Confilicts in the library, but that's really difficult to get right). For the current setup, we get it for free. > The libfoo/libfoog approach seems a little bit ugly. It's pure name > space pollution ;-) We already have that for libraries, when we upgrade to different sonames. And in this case, although the soname doesn't change, the library is not usable for the libc5 programmes. > Ok, same with namespace pollution. Why not calling the ``normal'' > (libc6) dev package libfoo-dev and the ``old'' is libfoo-5dev or > similar. Again, it can disappear somewhen in future. That's -the same amount of name-space pollution -although it will look better in the future, it looks worse in the past. Yes, I ageree that it's better to have things look bad in the past and good in the future, but the point is: we cannot change the past. And the simple fackt is, that the past (also called "bo" or "hamm") used libfoo-dev for the names. So, there's no way we can change bo/hamm any more. -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Correct path for upgrading to libc6-dev?
> > In article <[EMAIL PROTECTED]>, > Ben Gertzfield <[EMAIL PROTECTED]> writes: > > >> You should certainly remove libdb-dev, since libc6-dev replaces it (as > >> libc6 includes libdb.) I haven't done a libdb-altdev, and unless > >> someone asks probably won't bother (the libgdbm* packages are already > >> uploaded though.) > > > > Oh, okay. Do you know anything about the others? > > For libg++, I'd wait until there's a libg++272 package, and install the > development stuff from that; It's sortof difficult to wait till May 18, as that's when libg++272 was released, along with libg++272-dev. > for ncurses there are libc6 versions of the Hell, ncurses was only uploaded one week ago or something, libg++272 is _much_ older! (And, why do you call it libg++272, why not libg++27g, that's what the standard tells us to use. I only chose libg++272 because HJ Lu did that, and it doesn't seem to cause problems). -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: checker libs with debugging symbols
> >>Sorry but I disagree here. For a user who only wants to debug his own > >>program debugging symbols in the libraries are not needed. > > > >Let's take a look at the following program: [..] > >gets(buffer); [..] > >If you feed it a line that's too long, the access violation will > >happen deep within the C library. Without debugging symbols, it's > >hard to know wether this is a bug in the C library (and there > >could be quite a few :-) or your program. > True. But I didn't say 'get rid of these symbols'. All I'd like to see > is the chance for me to install a version without symbols. But hey, everybody who installes checker has at least a full installation of gcc, of libc*-dev, gdb, and probably a lot more development tools. Now, reading the above, certainly *I* want to have the symbols in those libs, and I am quite sure most people do. How many people would have enough space on their development system to install the development tools, but want to econimise badly on their checker libs? Creating extra checker packages will - give everybody who installs debian more work, as they now have to decide what version of checker to install (quite a hard choice for a newbie, I'd say). - give the developper extra work - give the mirrors more work, make debian even larger (If you want to do this, why not simply say "strip /usr/lib/*"? -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Larry Daffner, svgalib1 libc6
-- Start of PGP signed section. > On Thu, 19 Jun 1997, joost witteveen wrote: > > > I would very much like to have a libc6 version of that package > > available (no, I don't use svgalib myself, but some of my packages > > do, and I want to fix bugs in them). > > > > If you are unable to create libc6 packages, could I offer to > > make a non-maintainer release of svgalib1*? > > I believe that svgalib was just orphaned. OK, thanks (and sorry for missing that email of his on debian-devel). I'll make that non-maintainer upload, unless svgalib already has a new maintainer. -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Larry Daffner, svgalib1 libc6
Larry Daffner <[EMAIL PROTECTED]>, are you still with us? I've sent you an email about svgalib, a package you maintain. First email was dated Jun 10, and one at 17 June, or thereabout. None of my messages were answered. I would very much like to have a libc6 version of that package available (no, I don't use svgalib myself, but some of my packages do, and I want to fix bugs in them). If you are unable to create libc6 packages, could I offer to make a non-maintainer release of svgalib1*? To the other maintainers: anybody else already wanted to make the libc6 version, or should I just go ahead (well, I'll give Larry a few more days, but then I'll just upload it). Thanks, -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian target audience
> The problem of having both libc5 and libc6 run-time libraries is minor, > the main one is that those stuck with libc5-dev cannot use other > newly-available versions of *libraries* from hamm. How do you mean? You can install the *libraries* just fine, it's just the development versions that fail to install. And even then, why not install lib5-altdev? Then there is no problem whatsoever. -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Status of Debian Policy
> On Sun, 15 Jun 1997, Jim Pick wrote: > > > > > > > All packages that provide HTML documentation should register these > > > > documents to the menu system, too. Check out section section 4.1, > > > > `Web > > > > servers and applications' for details. > > > > > > Is that as well as registering with dwww? > > > > I'm changing the way documents register themselves with dwww (again). > > Hopefully, I'll get enough accomplished so that I can upload > > something to experimental today. I wouldn't encourage anybody to > > register their documents with dwww just yet, since it's all going > > to change. Hopefully, I'll get past the prototype stage in the > > next month or so, and there will be a standard supported way of > > registering documents with dwww. > > I'm somehow confused now. Is registering to "dwww" any different from the > "menu" system? Joost, perhaps you can give use some hints here (I think > Jim is offline now). It used to be the same, and that's why I also asked Jim about that. But he seems to have something different in mind, I'm not quite sure what he does have in mind though. Also I'm not sure it's better than what we have currently, but anyway, here's an email he sent me: (I hope Jim doesn't mind me reproducing it, but it seems he isn't telling any secrets here) Jim> > Is that via menu, or directly via dwww? Jim> Jim> It's going to be very similar to the way menu works (I might steal some Jim> code). I'm going to have a directory under /usr/lib/dwww/menudata Jim> which will accept files similar to the way /usr/lib/menu works. I'll Jim> probably have an /etc/dwww/menudata directory too, for local additions. Jim> Jim> There will also be additional directories to accept "method" programs Jim> for actually rendering the various parts of the dwww-menu heirarchy. Jim> Also, there will be another directory for other "method" programs to Jim> handle searching. The idea is that any package can easily extend Jim> or modify the behaviour of dwww. Jim> Jim> Instead of pre-rendering most of the pages, dwww will call Jim> the dwww-menu "method" programs to render the pages on the fly. Jim> Depending on the what the "method" program does, it might simply Jim> build a page from dwww-menu items in /usr/lib/dwww/menudata - or Jim> it might use other data sources (even other CGI scripts). I'll have Jim> to redesign the cacheing mechanism a bit - it might make sense to Jim> dump "dwww-cache", and use something like squid instead. Jim> Jim> I've built a little program which reads all the /var/lib/dpkg/info/*.list Jim> files, and pumps them though the "frcode" program that comes with Jim> findutils. That way, I can use the "locate" program to provide similar Jim> functionality to "dpkg -L" and "dpkg -S", except that most queries return Jim> in less than 2 seconds. It works so well, I'm thinking of making a Jim> separate "dlocate" program so that it can be used from the command line. Jim> Jim> The dwww-menu entries will probably be in a pseudo-SGML type of format. Jim> When I get enough time to actually learn how all the SGML tools work, I Jim> might rework it to use a real SGML DTD. I figure that SGML will be a Jim> good fit, since the output is going to always be HTML. Jim> Jim> There are quite a few other things I want to add - when I'm done, it's Jim> going to look nothing like the current dwww. The nice thing is, it will Jim> be broken into separate pieces, so it will be easy for many people to Jim> work on it and improve it simultaneously. Jim> Jim> Cheers, Jim> Jim> - Jim Jim> -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
libc6 system for libc5-only maintainers
If you (debian developper) need a libc6 system to compile your packages on, but feel you are unable to upgrade your system to libc6, I can give you an account on my system. (The connection with the internet is only about 6kByte/second (max), so it may not be very usefull for big packages). I'll send you your account info pgp-encrypted, so you will need pgp on your system. Thanks, -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Package priorities and dependencies.
> On Sun, 15 Jun 1997, Dale Scheetz wrote: > > [snip] > > It seems to me that packages of any priority level should not be dependent > > upon packages of lower priority. > > I totally agree to this. Yes, I noticed this myself too (in libg++272). I didn't quite know what to do with it at the time, and I thought "don't fix what ain't broken", but I've changed libg++272's priority now to "Important" -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#10516: gs-aladdin: Depends on svgalib1 (>= 1.210-1) which does not allow svgalib-dummy to fulfill the dependency
> On Jun 12, joost witteveen wrote > > > > Well, OK, I can see *somebody* wants this. > > But still I'm not convinced this warrants inclusion in stable. > > Are there other people that would like the dependancy change > > > > - Depends: svgalib1 (>= 1:1.2.10-2) > > + Depends: svgalib1 (>= 1:1.2.10-2)|svgadummy > > > > to go into stable? > > Looks like a kludge to me. The proper fix is to make dpkg grok versioned > provides. Then svgadummy could "Provides: svgalib1 (= 1:1.2.10-2)" and > everyone can be happy. That's what I've been saying all along. But Christoph thought the problem of not being able to install gs on a "Webserver" (that does have X installed, but cannot for some reason have svgalib installed, whatever that reason may be) was so serious, that it had to be fixed NOW, in stable. I just asked this list if there were other people that agree with Christoph on this, but so far I haven't seen anybody respond. -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 policy in unstable
> > > I'm not entirely certain I see why we need to remove libc5 packages from > > > the system for Debian 2.0. While I agree that the primary packages should > > > really be glibc, I don't see how a few lib5 packages are going to hurt the > > > distribution > > > > Well, they won't hurt much, but they would: > > > > - make memory usage less favourable (if you're running a mix of > >libc5/libc6 binaries, you'll have both in memory). > > - make Debian look less attractive (We wouldn't appear in the > >list of distributions that are fully libc6). > > Could you please point me to such a list? Of cource, there isn't such a list now (as far as I know, at least I guess that list would be empty now). > Anyways, Debian just can't compete with commercial distributions which can > allow to suppose that they are self-contained. Debian is NOT. Unlike > RedHat (which has, for instance its "own" Motif and Metro-X), we can't > include ANY commercial product into the distribution. So, why does that mean we cannot compete? What has self-contained to do with Motif? Anyway, Lars just posted a script to auto-build the whole distribution, and I really think with such scripts (presumably improved ones, but the one from Lars apparently already works) we will get a self-contained distribution rather soon. > They could recomplie them and have "fully libc6" distribution in a day. Wait and see what Lars will do. -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: libc6 policy supplement 2nd try
> packages as follows [1]. Some packages (mostly from base) may use
> locations in /lib.
>
>based on | package name | library location
>
> libc6 | libfoo | /usr/lib/libfoo.so.
> libc5 | libfoo-g | /usr/lib/libc5-compat/libfoo.so. [2]
Isn't that the other way around: the libc6 version with g, and the
libc5 version without? (This convention would ensure that somebody
with an old (from bo, libc5) libfoo and a new libfoo-g would have
the same library twice, and other libc6 packages couldn't just
depends: libfoo, cause there are now two libfoo's (a libc5 and a libc6 one).
> based on | package name| hierarchy locations
> ---
> libc6 | libfoo-dev | /usr/{lib,include}
> libc5 | libfoo-g-altdev | /usr/i486-linuxlibc1/{lib,include}
Here again, unless I'm really confused, the "g" is mixed up.
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 policy in unstable
> > Yes, they should be. When do we remove all the non-libc6 packages, though? > > I'm not entirely certain I see why we need to remove libc5 packages from > the system for Debian 2.0. While I agree that the primary packages should > really be glibc, I don't see how a few lib5 packages are going to hurt the > distribution Well, they won't hurt much, but they would: - make memory usage less favourable (if you're running a mix of libc5/libc6 binaries, you'll have both in memory). - make Debian look less attractive (We wouldn't appear in the list of distributions that are fully libc6). As more-or-less automatic compilation of packages is now possible, we could always (at some point) just write a script and automatically convert all remaining libc5 packages to libc6 -- the ones that don't compile obviously have bugs in them, that can then be reported, thus forcing the maintainer to do something about it. But I don't think there will be many of those packages. -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Compiling with libc6
> There are some maintainers that must keep their machines on the stable > tree (and thus libc5) for various reasons. > > Is there a machine somewhere these developers can log in to for the sole > purpose of building release packages? If nobody else comes forward, I'd be willing to do so. My machine is connected to the internet via a 6kbyte/s link, so up/down loading your (large) packages will not be very fast, but at least it works. Mail me if you want an account on my "unstable" machine. -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Simple policy question...
> Okay, I know that before 1.3 was released, for a long time period the only > changes that were being accepted were updates that fixed bugs. Updates that > only provided new features were not allowed. > > Now that 1.3 has "shipped", are updates allowed to replace old packages, or > are replacment packages still only allowed that fix specific bugs? (In > particular I'm wondering whether we will see Xemacs 19-15 and XFree 3.3 in > 1.3.) Situation of 1.3 is still more-or-less unchaged: only really serious bugfixes can go in 1.3.1, after (we have been promised) two weeks of testing. XFree 3.3 has important security fixes, and there seems to be no other way to close the security holes currently in debian 1.3.0 than to include Xfree 3.3, so there is a chance that will be included. I'm much less sure about XEmacs 19.15 though, although I believe it also does fix stuff. -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#10516: gs-aladdin: Depends on svgalib1 (>= 1.210-1) which does not allow svgalib-dummy to fulfill the dependency
Well, OK, I can see *somebody* wants this. But still I'm not convinced this warrants inclusion in stable. Are there other people that would like the dependancy change - Depends: svgalib1 (>= 1:1.2.10-2) + Depends: svgalib1 (>= 1:1.2.10-2)|svgadummy to go into stable? > >> Sorry but this is stable bug. And its significant for people running Bo as > >> a webserver etc which usually does not have a display or even a video > >> board. I have a series of those machine that I maintain. > > > >You mean, they have gs installed, but no video card? Should there also > >be a dummy xlib package then? > > xlib does not use a video card. Sure enough I have xlib installed on those > systems but no X-Server. gs is mainly of use to convert between / to > different graphics formats. > > >I see no reason why this would be significant for people running Bo > >as webservers, as they will probably not have gs installed eighter. > >Or if they have serious reasons not to install svgalib, why do they > >install xlib? > > Because they want to run remote X Sessions. So it will at least not just be a web-server. But anyway, I get your point. -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Possible Xaw{3d,95} bug / Re: Debian freeciv bugs
> [EMAIL PROTECTED] (joost witteveen) writes: > > > One possible solution is to link Xaw statically in the freeciv binary. > > That's what I do with aXe. > > Or you can just use -rpath when you compile to force it to use a > particular dynamically linked libXa*. I think that was the solution > used in gv. Yeah, sorry. There goes another release of aXe! Thanks, -- joost witteveen, [EMAIL PROTECTED] #!/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: S-Lang for use with libc6 uploaded (source, i386)
> I'm replying to this on debian-devel since many developers are > probably still not clear on the issues that come up when converting to > libc6. Thanks, it's good to read this! > > On Jun 4, J.H.M. Dassen wrote > >* Non-maintainer release (OK-ed by Chris); slang should now be usable > > with libc6. [...] > Ray, converting a library to libc6 is not this simple. Only the most > trivial of libraries can actually be built to work both libc5 and > libc6 at the same time. Because of this, we need to provide separate > slang libraries for libc5 and libc6. > > Because the current slang0.99.34 and slang0.99.34-dev packages are > implicitly for libc5, we can't "re-use" them and therefore need to use > new package names for the new libc6 versions. I've been recommending > people simply append a "g" to the package names in these cases to > identify them as being for glibc/libc6. The new packages might then > be slang0.99.34g and slang0.99.34g-dev. With libg++, I noticed that the upstream, version, patched by HJ Lu for glibc, had a new soname (it's 272 now, was 27). So, I called the glibc compiled libg++ package "libg++272" (libc5: libg++27). Do you think this was a good idea? If not, should I change it to libg++272g? (even though some packages already may depend on libg++272, I don't know). > Making separate packages for libc5 and libc6 creates two problems > because both libraries will use the same file names and sonames. > > First, the libraries can't be in the same directory as each other. To > solve this problem, the current libc5 package provides two new > directories, /lib/libc5-compat and /usr/lib/libc5-compat. These can > be used to put old libc5-based libraries which conflict with new > libc6-based ones. So, that means my libg++27 package (the old one) should be updated to put it's shared libs in /usr/libc5-compat, right? At the moment, it doesn't do so, but I don't have problems with that -- probably because of the different sonames I'm using. Should I still put the libc5-compat stuff in the right place? > Second, the dynamic linkers need to be able to determine which > libraries are for libc5 and which are for libc6. To facilitate this, > each library must contain a run-time dependency on at least one of > libc, libm and libdl. $ ldd /usr/lib/libg++.so.272.5.0 libstdc++.so.272 => /usr/lib/libg++-dbg/libstdc++.so.272 (0x4003c000) So, I'm wrong here too? Does that mean I didn't have the same libc6-dev version installed as libc6 version? If I recompile libg++272 now, will it be fixed (I've got it correct now, I *though* I had it correct at the time too). Did I do something else wrong? (And, why don't I notice any problems -- well never mind, that must be because ldso is so clever). $ dpkg -l libc6* ii libc6 2.0.3-4 The GNU C library version 2 (run-time files) ii libc6-dbg 2.0.3-4 The GNU C library version 2 (debugging/profi ii libc6-dev 2.0.3-4 The GNU C library version 2 (development fil ii libc6-doc 2.0.3-4 The GNU C library version 2 (documentation f In short, thanks for the clarification. I hope I didn't mess up too badly with libg++, and I havent had/seen any problems yet from my packages, but with your post, I'm not too sure any more. -- joost witteveen, [EMAIL PROTECTED] #!/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Possible Xaw{3d,95} bug / Re: Debian freeciv bugs
> After extensive testing, some code rewriting, etc., I finally have > determined that this problem only occurs when using Xaw3d or Xaw95. I > am CCing this message to the relevant maintainers. (Xaw maintainers: > package freeciv-1.0j that is in hamm causes coredump under Xaw3d and > Xaw95 but not the standard widget set). One possible solution is to link Xaw statically in the freeciv binary. That's what I do with aXe. -- joost witteveen, [EMAIL PROTECTED] #!/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Copyright question
> On 31 May 1997, John Goerzen wrote: > > > A program I am packaging has a copying policy as follows: > > > > Only NON-COMMERCIAL distribution allowed. > > This puts the package into non-free. However... > > > Redistribution of > > modified versions by other people than myself is not allowed. > > We need at least the possibility to distribute a modified binary version > of the package. If this isn't allowed by that sentence, than the package > can't be included in the archive at all. Or do I miss something? Yes, if a modifying the package isn't allowed, then it cannot go into the main archive, and has to go into non-free, even if you're allowed to make money distributing it. Non-free it is -- joost witteveen, [EMAIL PROTECTED] #!/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: kernel header files : problems (yes, again)\
> hy. > > ok, i have libc5-dev installed without changing anything with the header > files. and i have the current kernel source and headers installed. > > i'm kompiling a program, that needs to access current kernel headers > (isdnutils), so i compile it with -I/usr/src/linux/include . You mean that your isdnutils binary don't work on my system (assuming I use a different kernel)? Anyway: > > the problem : there is a /usr/src/linux/include/net directory, so i will > also get this directory. but only linux/ and asm/ shoud override > /usr/include, not net/ (because : net/ is buggy !). what shall i do ? How about reporting the bugs and get them fixed, if you are so sure you found kernel bugs? > ok, i know how to fix this, but with the next libc or kernel header > update i will have to fix it again... any good solution ? Fix the kernel. > (where can i find the reasons, why kernel headers are in libc ? i know > that nearly anybody sais, that this is the right way, but sometimes i > get frustrated and start to disbelief). /usr/doc/lib5/FAQ.gz -- where else? -- joost witteveen, [EMAIL PROTECTED] #!/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: official C library
> Is libc 6 (aka glibc) the official C library for hamm? If so when should we > start reporting bugs against incompatibilities? Well, please at least wait untill all libraries are compiled for libc6. At the moment, gs won't compile on my system cause I've had to remove svgalib (depends on libc5-dev), etc. I believe it's the same with X libs. -- joost witteveen, [EMAIL PROTECTED] #!/bin/perl -sp0777i
Re: stumped with source package problem
> Does anyone know what this error message indicates? > > [EMAIL PROTECTED] ~/debian/build/tmp>dpkg-source -x xkobo_1.9-3.dsc > dpkg-source: extracting xkobo in xkobo-1.9 > patch: .dpkg-orig is not a regular file--can't patch > dpkg-source: failure: patch gave error exit status 2 > > I can extract the sources fine by hand. I tried rebuilding the source > package with dpkg-buildpackage -tc -sa and I still get the error message. Didn't you already file a bug against dpkg/patch for this, noticing that it it was patch-2.2 that caused this? Anyway, to help you with something else (see debian-bugs), I also tried to unpack xkobo, and only succeded after downgrading my patch-2.2 (unstable) to patch-2.1 (from bo). Probably the real bug is in dpkg, though. (sending this to the mailinglist in case other people still want to know this). -- joost witteveen, [EMAIL PROTECTED] #!/bin/perl -sp0777i
Re: IMP: downgrade ldso to bo: no ldso left!
> On May 11, joost witteveen wrote > > I just downgraded my ldso from the one in unstable, to the one > > in bo, and I appear to be left with a system that doesn't have > > a dynamic linker! > > This is because of a change from a hard link to a symlink in one of > the 1.9.x versions. I'm not sure that I can do anything about it > except to not allow ldso to be downgraded. Well, as the problem is rather serious (very, very, very!), I think the least you can do is warn the user who wants to downgrade to the bo version, and offer him to quit the install if no statically linked version of "cp" or "ln" is available. Or, maybe provide a statically linked version of ln in the preinst (uuencoded) of the bo version of ldso, that the preisnt stores in /tmp/ln-static. Then you could use that /tmp/ln-static to: -maybe use to correct the damage yourself in the postinst, -or, simply "rm /tmp/ln-static" in the postinst: if the system still works, this will safely delete that ln. if the system is broken, the rm doesn't work, and the user at least has a statically linked "ln" available. then just an "echo" will suffice to tell the users what to do (well, it would have worked with me). $ ls -al ln -rwxr-xr-x 1 root root 172383 May 13 12:05 ln* $ ldd ln statically linked (ELF) Yes, it's big, I know. But the problem really is big to. BTW, it isn't unlikely people will want to downgrade to the bo version of ldso, as it's the only version that still allows us to build .deb packages: dpkg-shlib doesn't work with the new ld.so. Yes, I know there's an experimental dpkg out that does work with the new ld.so, but we've just been warned about the dangers of that experimental version. Also, we need to new ldso in order to run libc6 packages (loads already in unstable). So, I can well envisage the situation where people want to switch between the two ldso's -- joost witteveen, [EMAIL PROTECTED] #!/bin/perl -sp0777i
new package: nfsroot boot any client into Linux on network
30min after you installed this package on your server, you can: . Insert a nfsrootbootfloppy (create one with "mknfsrootboot") in any computer on your local network that has it's networkcard configured (running whatever OS), press "RESET", and hey presto, it's running LINUX! (and is configured to do just as much as your server, by default). . This package allows you to have most /etc files on the clients the same as the server, and some different. You'll need 30k disk space per potential client, and it's got a daemon that probes the network for hw adresses, and puts them in /etc/bootpd, and makes /tftpboot entries (excluding hosts in /etc/nfsroot/ignorehosts). It really works very well for me, hope it does so for you too. -BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Wed, 25 Sep 1996 21:59:58 +0200 Source: nfsroot Binary: nfsroot Architecture: source i386 Version: 0.0 Distribution: unstable Urgency: low Maintainer: joost witteveen <[EMAIL PROTECTED]> Description: nfsroot- Set up server to allow nfsroot clients to boot. Changes: nfsroot (0.0) unstable; urgency=low . * initial version. Files: f9c7ce1d75ea9d92824309458072817d 528 net optional nfsroot_0.0.dsc 8bc6d20354d5fce9ff321f983b41d256 27945 net optional nfsroot_0.0.tar.gz 9ea33dd3df295135c39d93016c0adf0d 521446 net optional nfsroot_0.0_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMk6khJNVaG8BiEBRAQGiTgP+Mq0jACIyLynvFA2DfiNdDmNEVAtJ1HNw nsRj/d+8WLpQ396VPYCe7+Y7qK17DUiU/T4dN2VRIzxcCvHizJDiJRiZLIB2VafD 8elA/4sY91h2NdS+zb/xdC2SDMzydnPpdYk067hk6pVahQYSIFsan2GX1QVQi/g8 w38E9nxGRGQ= =C9lx -----END PGP SIGNATURE- -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Bug#4574: gs -g flag does not work
> > Package: gs > Version: 4.01-4 > > The commands > > $ gs -g100x100 some_postscript_file.ps > $ gs -dDEVICEWIDTH=100 -dDEVICEHEIGHT=100 some_postscript_file.ps > $ gs some_postscript_file.ps > all produce the same results. OK in the second case, gs gets executed with: gs -dDEVICEHEIGHTPOINTS=842 -dDEVICEWIDTHPOINTS=595 -dDEVICEWIDTH=100 -dDEVICEHEIGHT=100 Q.ps and gs usually only uses the last defention on the commandline, but here it apparently uses the first one. So, I'll indeed have to change the wrapper. Thanks -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux!
where are guidelines?
I believe in the good old days, the guidelines were in dpgk. But I just installed dpkg-1.3-?, and they have gone. (So, I installed as many related packages as I could find from a search in the Packages file, but to no avail) $ find /usr -name "*guideli*" find: ./doc/examples/modules/GOODIES: Permission denied Could somebody please tell me what package I need to install to get them back? (Yes, I know of the dpkg -S option, but that doesn't help if the right package isn't installed to begin with) Also, I was hoping I could find the guidelines as to how to update old packages to the new source format -- but I must be overlooking something very obvious (I'm sure), as I cannot find this eighter. Thanks a lot, -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux!
Bug#4495: gs fonts should be in /usr/share/ghostscript/fonts
> > Package: gsfonts > Version: 4.01-2 > > Gs fonts are installed under usr/lib/ghostscript/4.01/fonts. There are two > problems with this: > > 1. Fonts are machine independent files that should be shared (in > /usr/share). Could you (or somebody else on this list) point me to some text that details this rule? My /usr/share is next to empty, while /usr/lib contains _lot's_ of system-independand files (pgp, samba, texmf, zoneinfo,...). I don't mean I don't like the idea of having arch indep stuff in /usr/share, it's just that if I do it, I would like to follow the guidelines any other standard. > 2. Gs fonts are regular PostScript fonts, not tied to a given version of > gs, so they should be under ghostscript/fonts, not > ghostscript/4.01/fonts. OK, I'll move this. I done it because gs-3.53 (by default) puts it in ghostscript/$VERSION/fonts, but if you (and someone else, too) prefers them in ghostscript/fonts, I'll move them. Thanks, -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux!
Bug#4384: gcc_2.7.2.1-1.deb & g77_0.5.18-2.deb incompatible
Alan (g77 maintainer) writes: > > I'm planning to do a new release of g77 which will include the gcc source to > try > and solve this problem. The idea was suggested to me by Joost. The > fundamental Probably you are right, but I don't quite understand what you mean. At the moment, gcc is g77 aware, but just not aware of the right g77 version. I think the best solution would, ofcource be to merge the g77 and gcc maintaining, so that new versions of g77 and gcc will always be released together. Failing that, probably the best way is to put a symlink from, say /usr/bin/f771 to /usr/lib/gcc/version/.. and to make the /usr/bin/gcc wrapper in the gcc package "/usr/bin/f771" aware, and not "/usr/lib/gcc/version/..." aware. What probably would not be a good solution is to put another /usr/bin/gcc wrapper in g77. This will then make g77 unable to work with other gcc versions (same problem as now, but other way around and therefore much more serious). Also, I don't really see a need for two /usr/bin/gcc wrappers to be provided by gcc and g77. If I ever gave the impression I favored this, I didn't get my opinion accross very well. So, basically I think this is a gcc problem, that gcc should solve (with a little assistance from g77, (the symlink) to tell gcc where to look for f771). But I don't know how David (gcc maintainer) think s about this, so I cc'd him on this. David? > Alan > > (g77 and f2c package maintainer) > -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux!
uploading gs-4.01-4
-BEGIN PGP SIGNED MESSAGE- Date: 29 Aug 96 21:19 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: joost witteveen <[EMAIL PROTECTED]> Source: gs Version: 4.01-4 Binary: gs Architecture: i386 source Description: gs: Postscript interpreter with X11 and svgalib preview support. Changes: * bjd paches from Yves Arrouye. (sorry Yves, I forgot to include them in gs_4.01-3). Files: 314a54bfe56ef2ba7461c51fc829f5e5 2186266 non-free - gs_4.01-4.tar.gz 37b4db5b1b3e1d85fc351a82d51a3572 30402 non-free - gs_4.01-4.diff.gz 33827c08f5e09c73f608e25e51c1a4ed 1079338 non-free Optional gs_4.01-4_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMiYJ2JNVaG8BiEBRAQHt6gP+Ng3OsgFNvx5TyIrbMgiwXr2VVLPGvp9s KzRwNXgYuPCuqiaKPZXlX5FdsRjz5pweyaujYttp4+zqp/FYr96qSDPIgP3XMX8D bbM2fsJyyypxswKOwWjeui2siRJZdqurtqcmv1b2gWGJn5P+0Z2yAGbowodNZGA+ yMak6au6uK0= =pnv2 -END PGP SIGNATURE-
gs-3.33 + gsfonts
Please blame me for all of this, and not the archive maintainer, but if you try to install gs-3.33 from the unstable tree, (the GNU version of gs), you'll notice it depends on gsfonts-4.01. Next you'll notice, gsfonts is in non-free and you cannot install it (as you're a "pure-gnu"). Fortunately, the location of gsfonts is incorrect, and you can safely download, sell, modify, whatever, gsfonts-4.01-2 from non-free, as it's GPL! I've already sent an email to Guy asking him to move gsfonts-4.01-2 from non-free to unstable/text. Thanks for your attention (and for the bug-reports those of you who didn't read this are going to send), -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux!
uploading gs_4.01-3
-BEGIN PGP SIGNED MESSAGE- Date: 28 Aug 96 21:19 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: joost witteveen <[EMAIL PROTECTED]> Source: gs Version: 4.01-3 Binary: gs Architecture: i386 source Description: gs: Postscript interpreter with X11 and svgalib preview support. Changes: * fixes: rounded-corners bug, patch provided by Thomas Koenig <[EMAIL PROTECTED]> * Applied a patch from Helmut Geyer <[EMAIL PROTECTED]> (Thanks, Helmut!), and gs now uses the shared libs for: png, jpeg, zlib. (as well as vga, X11, ...). * Gs still prints debugging info in xdvi (don't know why) Files: 6ae3475923b701639cf4ecd8eb9a7da9 2185258 non-free - gs_4.01-3.tar.gz eb24e408fdd3ab204b3f80657a55f93c 23493 non-free - gs_4.01-3.diff.gz 3b3d3f81d6070a6c54e9c506f0772688 1079668 non-free Optional gs_4.01-3_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMiS5NZNVaG8BiEBRAQHB7wQAmM0fh5rrP/mf5Oswz00CZS1gKx92De22 aFm0KMwn9ve66RrQB0G0zcEJ4MiLX5xo5fjTbiH5talo+VYZ2B4sJlcwVvNf6Dbk V+uWGxKGfWWOYqgrUZNpOzpBUIZS45RGiPUFDgZpVTuade/t/OZ2bSFbGzs5HaUn S2BZRHpgD/M= =z9oj -END PGP SIGNATURE-
uploading gs_3.33-1
-BEGIN PGP SIGNED MESSAGE- Date: 28 Aug 96 18:39 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: joost witteveen <[EMAIL PROTECTED]> Source: gs Version: 3.33-1 Binary: gs Architecture: i386 source Description: gs: Postscript interpreter with X11 and svgalib preview support. Changes: - New upstream version. - Following a patch I got from Helmut Geyer <[EMAIL PROTECTED]> for gs-4.01, I manually patched gs-3.33 to use the shared jpeg libs. (gs-4.01-3 will also use the shared zlib, and png libs). - Now uses libpaper to parse the /etc/papersize file. Files: a6974b4d80a5706aab919463c416c761 1659344 text - gs_3.33-1.tar.gz 70adf6563ea3bcd94f0ba01301fbec69 12499 text - gs_3.33-1.diff.gz 558aa7492f546118c20cdb76b3a1912b 793308 text Optional gs_3.33-1_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMiSTfpNVaG8BiEBRAQFNZwP+PvQ3sdqqUI8qV5He98IE7gPtuLIF+RhL TwwhVqj4zWZaZbpzey+5Hor3quoiCuU9IcGa2wkiEyhi4i6pGzfmyoUKtk3fNyR7 oC63rIHFxSPmnCyujkN8AVav+QpV3Yf5o8ktaU19T1lETGpCFA7Jy/E5LV6HUhlA ChMO5fvf2Jg= =Y5hM -END PGP SIGNATURE-
Bug#4317: xosview should display cached mem
> > Package: xosview > Version: 1.3.2-6 > > The mem bar only shows shared/shared/buf/free which is incorrect. > It should display: used/buffer/cached/free. Shared doesnt fit in that > summary chart, and cached is missing (for recent kernels of course). > The amount of shared isnt very easy to be displayed as bar, since its seatic > has changd (can be more than physical memory for multiple usage). Absolutely. I'm stopping maintaining xosview, with the previous flood of bug-reports that I cannot do anything about, and with the apearence of procmeter (it's very nice, all you prospective xosview buggers: try procmeter!) Although I guess the upstream maintainer would be interested to correct this one, I think, togehter with the other ones, I'll just try to move xosview to contrib. -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux!
Bug#4269: xosview has only XOSView as application resource file
> > Package: xosview > Version: 1.3.2-6 > > Xosview only reads the file XOSView (and ~/.Xdefaults) when evaluating > its X resources. It does this by doing all the reading by foot (calling > XrmGetFileDatabase() etc.). > This is IMO the wrong way to do it; the application should use > XtGetApplicationResources() (as xsysinfo does it). You're absolutely right. The upstream maintainer disagrees (well, he agrees, but doesn't want to change it, AFAIK). do you want me to 1 move xosview to 'contrib', and stop maintaining it 2 just go on maintaining a broken xosview? Sometimes, I really don't know what to do. -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux!
Bug#4267: xosview doesn't understand -geometry very well
> > Package: xosview > Version: 1.3.2-1 > > I ran xosview with this command: > > xosview -geometry 48x48+388+0 & xosview does not confirm to most X standards. It really isn't a very nice programme. The upstream maintainer says he will some time start using the standard Xt interface, but he didn't say when. Xosview-1.4.1 AFAIK doesn't use it. I'm closing this bug, as I cannot do anything about it, and the upstream maintainer doesn't care. Thanks anyway, -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux!
screen-3.7.1-8: utmp bug fixed (uploading)
-BEGIN PGP SIGNED MESSAGE- Date: 24 Aug 96 07:47 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: joost witteveen <[EMAIL PROTECTED]> Source: screen Version: 3.7.1-8 Binary: screen Architecture: i386 source Description: screen: A screen manager with VT100/ANSI terminal emulation. Changes: * Got a patch from upstream maintainer (my fault that it took so long), and now it will not mess up the utmp file. This means the dependancy on login(>=1.0-5) can be removed (as wel as the most recent shadow-login depenancy). Files: 959f9c2ddf945c3c58c0cb158ea956cd 394365 misc - screen_3.7.1-8.tar.gz e3d28813ad6f9bf54befae7cac892ead 18074 misc - screen_3.7.1-8.diff.gz 2f6714def8f8d16e1a3b529f94265ce6 192032 misc optional screen_3.7.1-8_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMh60AZNVaG8BiEBRAQFNeAP+MEK1ZWxCFDMVptwiCmsG6BAFAiNGQYgE lHMqXogScG+cauplXfEjRyZXz6ZXhfpPVFkBa9qxfvVpuVKld+fryEQO7hxX9iZ0 GnMFaQIb2SLKr/0NfjhUm7QHoRLTWzQRVaOUXmBSVyLMM547KDzZ2ZMrTiKmyqxg 4eEevnSCVVQ= =1asA -END PGP SIGNATURE-
uploading pixmap_pl2-1
-BEGIN PGP SIGNED MESSAGE- Date: 21 Aug 96 17:23 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: joost witteveen <[EMAIL PROTECTED]> Source: pixmap Version: 2.6pl2-1 Binary: pixmap Architecture: i386 source Description: pixmap: A pixmap editor. Changes: * upgraded upstream source. Although the debian-patches for pixmap_2.6pl1-5 are identical (for all intends and purposes) to the upstream patch2, changeing the version number makes it clear to outsiders that this debian package realy is the most recent release, which is good. * removed a debugging message. Files: 0d5b8eb84f5c1acaf0a43f32fba26398 126343 x11 - pixmap_2.6pl2-1.tar.gz 26856b5f5fb8b31f80148bf5b16e4c23 20567 x11 - pixmap_2.6pl2-1.diff.gz bad544b541b68a7e35f054d8e99c6d12 101898 x11 Optional pixmap_2.6pl2-1_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMhtGxZNVaG8BiEBRAQEYHAP9GcFR3i6ogueyQDuXIWIt9v70qtGlyCAf tmMSGdsX2QHaGhC/CV8QI59l1UK1eHv6mrM7DaxL4aqREE+wXVY8FUF2l7ZBuWFJ 5phKroQmzEqd3SCuVx3EY/wDskvt86oA2mx8YWhTcM/MkgCeSLOYauVFEBCujIPd fdOdNRkr07M= =q+Ij -END PGP SIGNATURE-
uploaded screen-3.7.1-7
-BEGIN PGP SIGNED MESSAGE- Date: 21 Aug 96 17:00 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: joost witteveen <[EMAIL PROTECTED]> Source: screen Version: 3.7.1-7 Binary: screen Architecture: i386 source Description: screen: A screen manager with VT100/ANSI terminal emulation. Changes: added "|shadow-login" to dependency list, to allow installation of shadow password. Files: b12aefd11ba2a657f6005d5769e344a7 389093 misc - screen_3.7.1-7.tar.gz 4930ef6edf74f19bd8e4a8af0716c2a8 13268 misc - screen_3.7.1-7.diff.gz 24262ce37c0ca7badb8a25de4e2abded 191988 misc optional screen_3.7.1-7_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMhtBHJNVaG8BiEBRAQF0rQQAq51MDMl7nrnywk0K44a5IxatcZdoucXs erAnHWI94Bfn2SGm20mMOSveslFB01KyuvusqBBz/GemDCnTrK0FFrg/iK0ugeqL K9hbLBvvNOcr0L7lr8U/xOy6giTspHpMBRbEkn44cNYXpAkWNfYvxSBjaIVB2Vqb nliCg9q3B4U= =2aq4 -END PGP SIGNATURE-
uploading gsfonts-4.01-2
-BEGIN PGP SIGNED MESSAGE- Date: 20 Aug 96 17:28 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: joost witteveen <[EMAIL PROTECTED]> Source: gsfonts Version: 4.01-2 Binary: gsfonts Architecture: all source Description: gsfonts: Fonts for the ghostscript interpreter Changes: - Really GNU-copyleft this time. (gs-4.01-1 still had a few fonts that were not copyable. Sorry). - This now contains the Fontmap file. It is currently also in the gs package. Files: ac3d817e4778116d1c4d830bd3adc91b 2287817 unstable - gsfonts_4.01-2.tar.gz 1234189b67e67b3d6faf03db541abb5a 1418 unstable - gsfonts_4.01-2.diff.gz 50b1e3bcb9df34cb6917855ef51bc98e 2297376 unstable Optional gsfonts_4.01-2_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMhn2F5NVaG8BiEBRAQEj7QP+O1WD+NXHytVRiMa9H3tsuNC1eVVFwCPg J9knqP21uSvHnDtX5UIaBf0DDHzfgV9l0jS7vxVEXIphxGpxqSKdaE8tv8XqStCR Jdqnh/SBAX2WzJQGY4dF8cWsJlbMuoTAI+HwKAXwC48Hq3nGIcI2U/p6coIdShm0 9XMYpS1I9eI= =WwvJ -END PGP SIGNATURE-
Re: Packaging questions (newbie)
> > I'd like to contribute some packages, but I'd like to ask some > questions first: > > 1. One of these packages is the replacement of `libX11.so'. Do I have to make > whole alternative version of appropriate standard X package or is there some > way to make small "one-file-replacement" package? One way of doing it is making your own directory, say, /usr/X11R6/lib/xczech put your czech version of libX11.so in that dir, and, in the postinst add the /usr/X11R6/lib/xczech to the front of /etc/ld.so.conf. (and remove it again in the postrm). This is the way it is done in Xaw3d, and seems to work reasonable well. > 2. Some of these packages (like X fonts) would be related to ISO-8859-2 only > and some of them (like Czech fonts and format files for TeX) are even > interesting only for Czech speaking users. It is probably not good idea to > place Czech-only packages to the main tree. Or it is? Well, I think it is. There are the german man pages, and I think a few non-english dictionaries in the main tree too. And, put it another way, most of the main-tree is only of interest to the english-speaking community -- why would we discriminate against czech? Then again, I come from Europe to, and my first language isn't English eighter. Good luck with your packages! -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux!
pixmap_2.6pl1-5 uploaded
-BEGIN PGP SIGNED MESSAGE- Date: 16 Aug 96 19:51 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: joost witteveen <[EMAIL PROTECTED]> Source: pixmap Version: 2.6pl1-5 Binary: pixmap Architecture: i386 source Description: pixmap: A pixmap editor. Changes: - Upstream maintainer now provided me with a propper patch for bug 4169, included in this version. - Bug 4100 may be due to a bug in XFree 3.1.2. My previous patch was a very buggy workaround for this, and my current patch for bug 4100 is a somewhat less (though still not good) workaround for this. Files: 627ba0d737d2ab206dfef06fd59a2261 228727 x11 - pixmap_2.6pl1-5.tar.gz 7aecf1b738640c482c33a73e2321f8d5 4010 x11 - pixmap_2.6pl1-5.diff.gz 8be83821f6b3407d5c8d37a70c427ea5 101912 x11 Optional pixmap_2.6pl1-5_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMhTShJNVaG8BiEBRAQHH5AQAg7LLzPZQ+2uY6+rAREmI0wxVT0U2W0TG VCWNwvrE65HaJyyOY7cZ8YUZ7ZUrS7wovuqzf/clv5LFvf8lD78fEGiyr/1Nc9R3 coX/2KS8HgqhfALWHBDJPzKL9wdMk2UGGbUfO8BVwfH+dxFJ5ha/4Xe0ssZe1npi UPTKxwRSs+I= =q8nY -END PGP SIGNATURE-
Bug#4169: pixmap dies
> > Package: pixmap > Version: 2.6pl1-2 > > Pixmap crashes when I try to save an icon (it works with > some icons). You've got a 8bpp display! (well, I just think you don't have a 16bpp display, as get pixmap dump core upon loading your file) Thanks for the bug-report, though. I've removed the hints/comment write support in pixmap (at least that's what I think it is), and your file seems to be saved more or less correctly now (I can re-load, and it looks the same. But the resuting file cannot anymore cause a cordump with the old pixmap). Because I am unsure I've done the right thing with the patch, I don't want to upload the new pixmap to master. I've put it on ftp://rulcmc.leidenuniv.nl/joost/pixmap_2.6pl1_4* for you (and other interested parties) to try out, and I've asked the pixmap mailinglist for more advice. -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux!
Re: libpaper 1.0 on master
> > >Shouldn't the "paper size" be an attribute of a print queue, and not an > >attribute of a machine? Well, it could be argued that Yvess libppaper could look at the current $PRINTER setting, and select the correct papersize depending on the /etc/papersize.printer file or something. But at the moment not very many programmes use libpaper or /etc/papersize, so it's better to have them at least get to recognise a global /etc/papersize than nothing. > > Paper size effect more that just printers. Previewers and tex tools > come to mind, there may be others... > > All I know is right now I've got to tweak quite a few things on a > standard debian 1.1 system so that dvips, xdvi, genscript, and a few > other programs work well and have the same idea of a default paper > size. Well, after you've done the tweaking, maybe it's worth the little extra efford of mailing the patches to the maintainer/bug-system and wait to see them included in the next release? If you don't want to do that, could you send your patches to me, so that try to handle it? Thanks, -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux!
uploading pixmap_2.6pl1-3
-BEGIN PGP SIGNED MESSAGE- Date: 15 Aug 96 21:21 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: joost witteveen <[EMAIL PROTECTED]> Source: pixmap Version: 2.6pl1-3 Binary: pixmap Architecture: i386 source Description: pixmap: A pixmap editor. Changes: - Fixed bug 4100, pixmap dumps core. (he says, while he bows deeply for the electric fence author (Bruce)) Files: 599930c5caffba7af29481cd1d904de2 192987 x11 - pixmap_2.6pl1-3.tar.gz ca8622d6f0d93e7f4619271812dde4c0 11769 x11 - pixmap_2.6pl1-3.diff.gz 987adbd583ba886e694d12f7579c4e04 101946 x11 Optional pixmap_2.6pl1-3_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMhOVlZNVaG8BiEBRAQEjvQQAlZQL4pxx5RlSaJBHF2NBkomfwCH4EV5q WhXy9dKh0B22JA8MRk8yDl7FtHoKFtEhhNW2ee/R+ftjBnc+NnnmG7K5AzCUewVk XGBrBw284PTtdmffbH8S5RdLdxHV2+obOX3MSY91h1CtrCpursjiRj7ZeCCaQa52 0wiiH4t0uEE= =Tt2m -END PGP SIGNATURE-
uploaded gs_4.01-2 (missing dep:libpaper)
-BEGIN PGP SIGNED MESSAGE- Date: 15 Aug 96 15:44 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: joost witteveen <[EMAIL PROTECTED]> Source: gs Version: 4.01-2 Binary: gs Architecture: i386 source Description: gs: Postscript interpreter with X11 and svgalib preview support. Changes: - OK, I messed it up big time. I don't know why, but for some reason libpaper wasn't listed in the "Depends" line. I'm _sure_ I put it in after I typed "./debian.rules binary" and the like, but... So, all that changes is the version number and the dependancy. Sorry. Files: f23a50cdcaeaf3aa1502495e0d0f4681 2941533 non-free - gs_4.01-2.tar.gz 11660778e30eeb7c1a692098c0277d4b 9746 non-free - gs_4.01-2.diff.gz 109d0e79370853fa2107292afa33b297 1123704 non-free Optional gs_4.01-2_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMhNGWJNVaG8BiEBRAQHDgAQAoQv+scflFFlkPyjgD6Xux+Sr7UiJmP7J X5UlQ5bI3vvugg10dKtSXN72iMXL0cW/YXC0+BOnwUy1EAuMRjLg+/tnmWUeU4RS 0TdpWarDMN8Gkj+uL1xeHqzllCmOOqDy5PePjnFMd7qR3jCP6zn7fSmmbeTfRydr JhqJL9pySnU= =ukTY -END PGP SIGNATURE-
gs+gsfonts 4.01 uploading (finally)
-BEGIN PGP SIGNED MESSAGE- Date: 15 Aug 96 11:53 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: joost witteveen <[EMAIL PROTECTED]> Source: gsfonts Version: 4.01-1 Binary: gsfonts Architecture: all source Description: gsfonts: Fonts for the ghostscript interpreter Changes: - upgraded upstream version (finally, sorry for the delay!). - added extended description. Files: 716699d836ec8ff6e62b68e46406794a 2278216 non-free - gsfonts_4.01-1.tar.gz c5c8da990077f89dbdc9826035731978 4196 non-free - gsfonts_4.01-1.diff.gz ad0686393f888eb49afa3baf0975b09b 2286836 non-free Optional gsfonts_4.01-1_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMhMQHpNVaG8BiEBRAQHQBwQAtrdpL0oYWZo+yOyH8ATgHahGVYtGF6uo kD8R5hk3t5u2PaRCzj3s5APUTTtFU4RuuVzWiHZPruln+xiT6o8LvkSJAEaOuJSj 4XAgoLBmhBX4sq+IiaR+fJkWGqpkKZ4c8QwxtT8gJp9siROj1u7JNyos+FHa/4N+ jqCKhECTw9Y= =4ZM2 -END PGP SIGNATURE- -BEGIN PGP SIGNED MESSAGE- Date: 15 Aug 96 09:54 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: joost witteveen <[EMAIL PROTECTED]> Source: gs Version: 4.01-1 Binary: gs Architecture: i386 source Description: gs: Postscript interpreter with X11 and svgalib preview support. Changes: - upgraded upstream version - now uses Yves's gs-wrapper-library "libpaper" (1.0-1). (If you're installing libpaper, be warned that it _will_ overwrite your /etc/papersize without asking). - gs patched so that it _can_ be installed setuid for people using svga a lot (not adviced though). If installed setuid, gs will always issue the message "using svga driver ...", whatever driver you are using. - the wrapper around gs will add "-sDEVICE=lvga256" if you're starting gs from the console, to the front of the argument-list (so that it's still overridable by the user). - GNU version gs-3.33 comming up soon (promise) Files: 7e5848edd7c60bc7f88ef55e5dc6ba5b 2941514 non-free - gs_4.01-1.tar.gz 775bd17b7f1ee1d2d008b76ec4ab8477 9733 non-free - gs_4.01-1.diff.gz 9dfb3e89d919abe25bc5f7488327218a 1123680 non-free optional gs_4.01-1_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMhMIdpNVaG8BiEBRAQGD4wP/UxYFSFs6w3pSprSW7EqnM6wxAec/Qpg9 pOhrnTnIlW7SQl7fEVd3GfYLDGzrNogZAIhZi6USLlXxSdkwyu0ViR0PWqdzC4mJ TVIielrpwG4HRRepA/GaV/or3tgttaK21N5BwOP5ukb4M/LyZs1G3cTaJR40P7r/ 7pD7bqbv+Fk= =ET6w -END PGP SIGNATURE-
Bug#4118: xosview doesn't use XUSERFILESEARCHPATH
> > Package: xosview > Version: 1.3.2-6 > > The program doesn't access the directories listed in > XUSERFILESEARCHPATH but it does read the default file > in /usr/lib/X11/app-defaults. I know, it's a horrible programme, isn't it. Any suggestions about what I can do about this -- it's really not just what paths it searches, it's also how it parses the appdefauls files (all manually). So if you've got any better ideas, I'd like to close this bug. But thanks for the bug-report anyway, it's nice to know people use xosview. -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux!
Package priority: Extra/Optional
Some time ago, 4th of June, Ian wrote a very clear message about what the package priorities like Extra/Optional/Required, e.d. should mean. I think Ian did a real good job with this message, finally makeing clear something to me that I've always felt unsure about. However, in this message, "Extra" is descirbed with: - - In order to get something into Extra it has to conflict with existing packages, or be very obscure, or very large, or be useable only in very specialised circumstances or for specialised applications, or have very complicated configuration requirements. Preferably several of those reasons would apply. While this seems very strict to me, and probably would only aply to one in 20 packages or so, I see on master's unstable/bin/Packages file: $ grep -i "Priority: Extra" Packages|wc -l 179 $ grep -i "Priority: Optional" Packages|wc -l 230 $ pwd /home/ftp/pub/Linux/Debian/unstable/binary-i386 Does this mean that the overrides file should be reworked a lot, or did I miss something on debian-devel changing the meaning of "Priority: Extra"? (maybe dchanges should be changed to have "Optional: as default, instead of the current "extra"). Thanks, -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux!
Bug#4081: xosview doesn't install a binary
> > > Package: xosview > Version: 1.3.2-4.1 > > It's in buzz-updates and > > # ls -l /usr/X11R6/bin/xosview > ls: /usr/X11R6/bin/xosview: No such file or directory > > After installing the package. Yes, that's Ians wish. I already corrected Ians error (he uploaded a known buggy xosview even without mailing me in advance of doing so). Thanks. BTW Ian also sent mail to debian-devel saying that this bug was in his uploaded version. xosview-1.3.2-6 doesn't contain this bug. -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux!
Bug#4058: etc/papersize doesn't allow spaces
> > > > > Oh, BTW, this has nothing to do with libpaper (I don't know why you > > think it does, gs doesn't depend on libpaper, and has been reading > > /etc/papersize before the existance of libpaper.) > > > > I do wonder if libpaper does a better job, > > Yes it does ;-) That's its big advantage: centralize such bugs in one > place so that we're sure all packages get fixed at once (who said I wanted > to share features too? ;-)) > > > and I do wonder if gs really should read "A4 ". Some people were really > > glad I added a wrapper to allow gs to read /etc/papersize. Some are > > angry it didn't read "A4 ". Well, you never please them all! > > Can you try my gsfrontend.c in libpaper 0.3? It would be nice if you > used it for these reasons: > > - people will benefit from new paper sizes immediately; That's not true, the gs wrapper I have reads _all_ papersizes gs understands. (it gets them at compile time from ps_init.ps or something) > > - I think if something else than me provides a working package using > libpaper, other package maintainers will start adopting it; > > - I won't have to overwrite your gs with my wrapper each time you > make a new package ;-). > > If you use my wrapper (please, please...), I suggest installing the real > gs as 'ghostscript' (a meaningfull name, no?) and the wrapper as 'gs' > of course. Apparently people were confused by your gs-papersize being > the gs that does not handle papersize despite its name. So, that's not the case any more (the real gs is gs.real, the wrapper is gs). What is causing me not to upgrade gs at the moment is this SVGA stuff: someone (svga maintainer) wanted a patch in that would make a setuid root gs "safe", but I'm still having problems with this. -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux!
Bug#4058: etc/papersize doesn't allow spaces
> > > Package: libpaper, gs > Version: 0.2-1, 3.53-4 > > Oef what do I hate these errors. The "<" char indicates the EOL char. > > # cat /etc/papersize > A4 < > # gs -h > Warning: unknown papersize in /etc/papersize > Aladdin Ghostscript 3.53 (1996-1-10) > [deleted] > > # cat /etc/papersize > A4< > # gs -h > Aladdin Ghostscript 3.53 (1996-1-10) > [deleted] > > Only one tiny little ugly space f*cked up printing on my system. Please > correct this ASAP. ASAP? #time echo "A4" > /etc/papersize 0.01user 0.00system 0:00.06elapsed 14%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (65major+17minor)pagefaults 0swaps There you go, in 0.06 second. If that isn't fast, then what is? Oh, BTW, this has nothing to do with libpaper (I don't know why you think it does, gs doesn't depend on libpaper, and has been reading /etc/papersize before the existance of libpaper.) I do wonder if libpaper does a better job, and I do wonder if gs really should read "A4 ". Some people were really glad I added a wrapper to allow gs to read /etc/papersize. Some are angry it didn't read "A4 ". Well, you never please them all! -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux!
Bug#3768: axe info files incorrectly installed
>
> Michael Meskes writes ("Bug#3768: axe info files incorrectly installed"):
> ...
> > 1) Change the source of axinfo (lots of work).
>
> This would be ideal, of course, but of course effort may be better
> spent elsewhere.
OK, I done that. The axe sources weren't that bad after all, and I
only needed to change axinfo in one place.
--
joost witteveen
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
Use Debian/GNU Linux!
axe_6.1.2-5 uploaded
-BEGIN PGP SIGNED MESSAGE- Date: 04 Aug 96 14:33 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: joost witteveen <[EMAIL PROTECTED]> Source: axe Version: 6.1.2-5 Binary: axe Architecture: i386 source Description: axe: An editor for X. Changes: * changed axinfo.c so that it now reads .gz files. (wasn't that much changes after all) Files: d93810377fe975ee622d6f8c37dc21a2 434741 editors - axe_6.1.2-5.tar.gz ad7d6914ed4f1ea31fa087a5aec3834e 30543 editors - axe_6.1.2-5.diff.gz da60b804a0ad3377261cd94dd97aaa18 197950 editors Optional axe_6.1.2-5_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMgS1BZNVaG8BiEBRAQEO8QP/b3+nrPm5yaJRJ1/zN6BYV5QAeDN/jHMV +9AME+yb8Vb2MnEiHjiauoaleK1oVdidQdZL8sOeHOf2HoVIzJ2XNW82jct5gfSp gHOgW9AxSERFa5kzUHjTONy4Qp2d/wcDczdwp7ADyMruwknIZNRIuGbSCjlalaLU 3GdP5Ie+HeY= =OWHz -END PGP SIGNATURE-
xosview_1.3.2-6 uploaded
-BEGIN PGP SIGNED MESSAGE-
Date: 22 Jul 96 12:02 UT
Format: 1.6
Distribution: unstable
Urgency: Low
Maintainer: joost witteveen <[EMAIL PROTECTED]>
Source: xosview
Version: 1.3.2-6
Binary: xosview
Architecture: i386 source
Description:
xosview: Fun to watch CPU/network usage programme
Changes:
* moved binary to /usr/X11R6/bin/xosview-1.3.2, and the post{inst,rm} now
setup/delete a symlink from xosview-1.3.2 to xosview. This way,
dpkg doesn't delete the binary after upgrading.
* applied patch from Philippe Troin <[EMAIL PROTECTED]>, correcting
bug 3873
Files:
4b7a58252b237f1fcbfebb717c3577ca 22934 x11 - xosview_1.3.2-6.tar.gz
535f1053c4fe5aee44f63b3eabea4a36 3745 x11 - xosview_1.3.2-6.diff.gz
083f714984ff69ca2e882cb22f3d9d2d 22400 x11 optional
xosview_1.3.2-6_i386.deb
-BEGIN PGP SIGNATURE-
Version: 2.6.2i
iQCVAwUBMfNuNZNVaG8BiEBRAQGCxQQAp1ekz/uHcjSTirt5/Z8WN0X9AluO0F7y
+ddm5G1hzn2filA8BOCBUAB50h4sbbJFMiRyh/HFMMC4+Iobr+XeRfnsTXAmf6Ix
wATOi4Xr4J2QDPWRsDVenIgLvBUOYQvkkNFIMbygCzEYFY5o+CTRQWj9pvTG7MHR
MUSgvWAVsgY=
=jdMH
-END PGP SIGNATURE-
axe_6.1.2-4 uploading
-BEGIN PGP SIGNED MESSAGE- Date: 16 Jul 96 21:17 UT Format: 1.5 Distribution: unstable Priority: Low Maintainer: joost witteveen <[EMAIL PROTECTED]> Source: axe Version: 6.1.2-4 Binary: axe Architecture: i386 source Description: axe: An editor for X. Changes: corrected info file modes, along with compressing them. Files: a9b416926378387cbd91156470479fdd 408637 editors - axe_6.1.2-4.tar.gz 69aee2e379b8b71a33dc66c5bba16447 4220 editors - axe_6.1.2-4.diff.gz e0cf497795e2ac33e5912123aa9ac454 197756 editors Optional axe_6.1.2-4_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMewHJ5NVaG8BiEBRAQEjqQQAtUdl6xZs2m/WFCuXErhMyroHZB6HMvMh QddCYo89V0sa6uBUmSSU5uSoKLqYwq3qtLbaHhJZI8XTvd1ofsPox9CvRfuvnaFf DpiTtJj6rlwc4QBkeQqjk3lbKKDixFP34+WTDRBsMQ0kqaZpS0cEDDh2Vzs5gsvU yUST5LJzohw= =jeRc -END PGP SIGNATURE-
transfig_3.1.2a-3 uploaded
-BEGIN PGP SIGNED MESSAGE- Date: 15 Jul 96 22:02 UT Format: 1.5 Distribution: unstable Priority: Low Maintainer: joost witteveen <[EMAIL PROTECTED]> Source: transfig Version: 3.1.2a-3 Binary: transfig Architecture: i386 source Description: transfig: Utilities for printing figures from xfig. Changes: *removed dependancy on libjpeg, as this isn't needed at all. Files: 9fb1c8500c191f6d959c1511f004b07c 194066 graphics - transfig_3.1.2a-3.tar.gz 3dee80c98c48c8a815195a7ad2f6320d 49456 graphics - transfig_3.1.2a-3.diff.gz 79326efdbf6d3e4fcb2a2336bc68e01b 83894 graphics Optional transfig_3.1.2a-3_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMerACpNVaG8BiEBRAQFZsgQAsRnnffiu7dxYbh68CXgL7tkn2DehkmO8 BvmFS70lwMUyna/n3LANy74sgX5tHGcjCqgNcrAEBdcvf9VQDTh3PPARvmLzMyxh SUofD+kIhBJwsxTNACcpd5ZuNGHfJxRUDiu0Amd+CGQ+unIUyVD3eecaiNSgdAYO tFC/GGZXobI= =AKHU -END PGP SIGNATURE-
xfig_3.1.4a-4 uploaded
-BEGIN PGP SIGNED MESSAGE- Date: 03 Jul 96 10:38 UT Format: 1.5 Distribution: unstable Priority: Low Maintainer: joost witteveen <[EMAIL PROTECTED]> Source: xfig Version: 3.1.4b-4 Binary: xfig Architecture: i386 source Description: xfig: Facility for Interactive Generation of figures under X11 Changes: * architecture indepentand debian.rules. Files: 4f67afb46fb6790f5f9f8ab47e908ef1 648722 graphics - xfig_3.1.4b-4.tar.gz 3280982e876bae8cd8ef21695b0dc092 6179 graphics - xfig_3.1.4b-4.diff.gz a602672d68c4a429c290c5daf08cd3db 239716 graphics Optional xfig_3.1.4b-4_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMdpN9ZNVaG8BiEBRAQEaDAP9GoqQZ/ENxkaXVWEzUMh9PJbXYyvxseGp Zv1uLMIkrz+favHsRIHBmOSkmUMBMwRwc4h4yAVsEwQ/Sp/FRDv6IVXY91uK+lXm CxVrHayHI/OnJvXq25Mc0egxlbYjZq43P3Qqv3TYjnx1NBccROa6J9FRcqTU+uVv meVBm896Qhc= =hHJE -END PGP SIGNATURE-
