Re: Key management using a USB key
On Wednesday 09 March 2005 01:42, David Härdeman wrote: > So the revocation could even be stored in cleartext on the usb key, > unless I'm mistaken? Depending on the strength of the crypto/passphrase protecting your key, this could lead at least to a DOS if the revocation is publicised without compromising your keys. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Key management using a USB key
On Tue, 8 Mar 2005, sean finney wrote: you could easily extend the script i wrote to unencrypt/loop-mount a filesystem-in-a-file without too much effort. prod me enough and i might do it myself. Prodding. :) Moreover I'd suggest to send the result of it as patch to the gpg package for inclusion into /usr/share/doc/gpg/examples . Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#298685: ITP: sip-tester -- a performance testing tool for the SIP protocol
Package: wnpp Severity: wishlist Owner: ARAKI Yasuhiro <[EMAIL PROTECTED]> * Package name: sip-tester Version : 1.1rc1 Upstream Author : Richard GAYRAUD * URL : http://sourceforge.net/projects/sipp/ * License : GPL2 or any later Description : a performance testing tool for the SIP protocol This package is destributed as Sipp by author. . Its main features are basic SIPStone scenarios, TCP/UDP transport, customizable (xml based) scenarios, dynamic adjustement of call-rate and a comprehensive set of real-time statistics. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=ja_JP.eucJP, LC_CTYPE=ja_JP.eucJP (charmap=EUC-JP) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
* David Pashley | Ideally I want to keep the disk formatted as vfat so it is usable on | other operating systems and use an ext2 loopback filesystem. Getting the | system to mount that is the hard part. You could partition the usb key and have a small partition for GPG/SSH keys and the rest for normal data transfers and stuff. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NPTL and static linking
[Blunt Jackson] > I am familiar with the nss issue, although that's not really relevant > to this question. The nss issue, and the related question in the FAQ > is that when statically linking to libc, there are still dynamic > loads required -- but libc handles this for the application. > (Presumably by dlopen.) Yes, dlopen, but the problem is version skew. With a dynamic libc6, libc and the NSS modules will always be compatible. With a static libc6, NSS functions (gethostbyname, getpwuid, etc.) will only work if the target system has a very similar version of libc to the one the app was linked with. Or they'll be ABI-incompatible and your program will crash. Kind of defeats the purpose of static linking. I know this is not directly related your question, but you displayed what seemed to be a misunderstanding of the static + NSS problem, so. signature.asc Description: Digital signature
Re: Switchconf: Orphaning or removing?
also sprach Gunnar Wolf <[EMAIL PROTECTED]> [2005.03.08.0232 +0100]: > Well... It could get back into Debian for sure, but there must be > somebody responsable for it. You can take the package, even not being > a DD, uploading it through a sponsor. You are, besides, the second > person who asked me about this, the first one was Martin Krafft > <[EMAIL PROTECTED]>, who _is_ a DD... He might want to resurrect it > and take it over or sponsor your uploads. Yes; It is probably better if I don't spread my resources thinner and take this package on as well, but I would be happy to work with anyone wanting to maintain it. I think switchconf is nice because it ties in well with guessnet, and because it's lean and mean and does exactly what it should, no more and no less. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Switchconf: Orphaning or removing?
also sprach Jose Manuel dos Santos Calhariz <[EMAIL PROTECTED]> [2005.03.09.0124 +0100]: > If Martin Krafft don't try to put it back, I may try to find > a sponsor. I am searchinf for a good excuse to be a DD. I'll sponsor you. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Switchconf: Orphaning or removing?
On Mon, Mar 07, 2005 at 10:44:25AM +0200, Shaul Karl wrote: > 60 PCs with Debian and there exist 4 different configurations? > In case each PC has a nic, it sounds like the fai package suits your > situation. Or cfengine2 (optionally coupled with pkgsync). /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Descripack, I would prefer another name (Debscripack ? Debscription ?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Last summer, the LSM2004 took place in Bordeaux, organized by ABUL. The president of the ABUL, Pierre Jarillon asked me to contact debian about a documentation project. Well, why me ? because I'm using debian a lot :-P Pierre Jarillon and I have already spoken of this project with some DD. It would be great to see if this project interests debian and if it is integrated in the distrib. Let me explain further : The project consists on having documentation and translated documentation for all free software (or most part). This documentation would present the software (with a short and a long description, like in debian). I know that DDTP exists and that it is near that (for package description). But the project (named Descripack), has the avantage of beeing distrib independant. Another advantage, is that the project would be based on a DB and with a frontend to update it like wiki-engines. So it would be easy for people to modify description of package, translate it and other things. P. Jarillon insists on the fact that the description must be lambda-user adapted (not developper). But IMHO, it's already the fact for most package... But it's true that when I imagine a simple user who wants to listen to his mp3 files, he search for "mp3 and player". The list of result is very impressive, and it's difficult for him to choice which of package he has better to install. Lots of possibilities can be imagined for helping him / teach him how to choose a package. One of these possibility is, for sure, an adapted documentation (adapted to his language). One can imagine a way of getting translation/description and co. from the descripack database directly by apt or other possibilities (but I don't know really how to include this in apt... It seems difficult..). If you have some idea about it, and if you are interested in this project, don't be affraid of sending ideas, or why not injuries :-P. Mandrake seems to be interested by the project, and it could be a way of normalizing package description. And of course a way of showing that distribution can walk in the same (good) way (the way of Debian of course :P). With that, all the distrib could have the same description of package, which is an important point I think (but not fundamental). Others informations are available on http://pjarillon.free.fr/docs/descripack/ The description are from mdk and PLF. Well I hope that I won't be virtualy killed after this mail (for the english or for the content) :-) - -- Martin Braure de Calignon "Debian addict, active member of Amaya (Amayita)'s fan club (and fan of her tatoo)" "! Debian-women as DPL !" "I now live in a banana republic :-/ " -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCLuiecHEx8cor214RAtv1AJ9xD22OkprJ6f3iHxyHVu513l4/owCg0Rv1 onYJ3SndTpjcRjkwYl32xDY= =m9xB -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Not every package should enter Debian (was: Re: Who cares about NEW when there are bigger issues? (was Re: Is NEW processing on hold? (was: Question for candidate Towns)))
On Tue, Mar 08, 2005 at 06:50:05PM +, Andrew Suffield wrote: > > In that light, fully automatic NEW processing will not hurt at all (I agree > > that a delay of a few days is sensible to give us time to react to the > > worst problem cases.) > > Unfortunately reality isn't so simple. In practice, the ftp-masters > have also become the review point for new packages. We *need* new > packages reviewing just to filter out some of the worst of the stupid > from the archive; frankly we need more than just new packages > reviewing. However, splitting that task out would probably be a good > idea. Peer review would then be a good idea. A package .changes gets signed by as many as 3 ftp-masters of a group of 10 (read it as an example) and then the package enters. Other ideas could include a mechanism of votations, where of 4 needed votes for a package to enter (out of 10 F-M), negative votes also can be sent. -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 If you iz watching dis in da UK, you may remember me from da telly. If you iz in Belgium you iz living in a shit hole. --Ali G (Ali G indahouse) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Cron-standard package to replace current tasks in 'cron'
Hi there, A while back I did a little bit of hacking and put together a package with "standard" cron tasks. These tasks includes: - backup stuff the cron package currently backups - some other simple backups (the 'backup-simple' program and manpage are included) - common cron-related packages that most system administrators will like to have in a stock Debian system (through dependancies). This includes: - Basic system accounting (implement in sysstat) - Basic logfile reporting (implemented through logcheck) - Basic security checks (implemented through checksecurity and Tiger) - Integrity file monitoring (through tripwire, aide, integrit or samhain) - Check if the system is up-to-date (using cron-apt or apt-watch, this requires an Internet connection) Packages are available at http://people.debian.org/~jfs/cron-standard/ I'm currently considering a post-sarge change that would imply moving the cron tasks in the cron package to this cron-standard package and have 'cron' Depend (if this package is uploaded a >optional priority) or Recommend this. I'm looking at comments on what additional tasks do you think that should be included in such a package and wether or not this kind of package is needed. The package could later on be enhanced by providing: - Basic database backups (for both MySQL and PostgreSQL if they are installed) Following mechanisms similar to those described at http://www.redhat.com/docs/manuals/database/RHDB-2.1-Manual/admin_user/backup.ht ml - Basic process and service monitoring (dead processes, zombies...) Like in http://shelldorado.com/scripts/cmds/checkps.txt (which uses http://shelldorado.com/scripts/cmds/psold.txt) - Basic filesystem analysis (checksecurity implements this but it should probably be moved here) Like in: http://shelldorado.com/scripts/cmds/checkfs.txt - System's user accounting (maybe using sac?) - Review user's usage of the system Like in http://shelldorado.com/scripts/cmds/dusage.txt At least, based on the discussion at #257393, it would be best if the cron tasks were separated from the main program itself. But then again, this might be over-engineering. Comments welcome. Regards Javier signature.asc Description: Digital signature
Re: Cron-standard package to replace current tasks in 'cron'
On Wednesday 09 March 2005 15:20, Javier FernÃndez-Sanguino PeÃa wrote:
> - Basic system accounting (implement in sysstat)
> - Basic logfile reporting (implemented through logcheck)
> - Basic security checks (implemented through checksecurity and Tiger)
> - Integrity file monitoring (through tripwire, aide, integrit or samhain)
> - Check if the system is up-to-date (using cron-apt or apt-watch,
> this requires an Internet connection)
> - Basic database backups (for both MySQL and PostgreSQL if they are
> installed)
> Following mechanisms similar to those described at
> http://www.redhat.com/docs/manuals/database/RHDB-2.1-Manual/admin_user/back
>up.ht ml
> - Basic filesystem analysis (checksecurity implements this but it should
> probably be moved here)
> Like in: http://shelldorado.com/scripts/cmds/checkfs.txt
> - System's user accounting (maybe using sac?)
Why {c,sh}ouldn't they be implemented as cron.daily scripts in the respective
packages?
Regards, David
--
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir Ãber ein septisches medium ;)
-- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Cron-standard package to replace current tasks in 'cron'
hi,
On Wed, Mar 09, 2005 at 04:00:49PM +0100, David Schmitt wrote:
> Why {c,sh}ouldn't they be implemented as cron.daily scripts in the respective
> packages?
i'd like to ack that. however, if the non-arch specific stuff (generic
cron jobs, init scripts, etc) for cron is still sufficiently complicated
it might make sense to have an Arch: all cron-common type package.
sean
--
signature.asc
Description: Digital signature
Re: Cron-standard package to replace current tasks in 'cron'
[Please don't confuse my procmail with Cc's]
[http://www.debian.org/MailingLists/#codeofconduct]
On Wednesday 09 March 2005 16:16, sean finney wrote:
> On Wed, Mar 09, 2005 at 04:00:49PM +0100, David Schmitt wrote:
> > Why {c,sh}ouldn't they be implemented as cron.daily scripts in the
> > respective packages?
>
> i'd like to ack that. however, if the non-arch specific stuff (generic
> cron jobs, init scripts, etc) for cron is still sufficiently complicated
> it might make sense to have an Arch: all cron-common type package.
I am not against a cron-common-jobs package. Quite to the contrary.
Regards, David
--
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir Ãber ein septisches medium ;)
-- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Key management using a USB key
On Wed, 2005-03-09 at 11:34 +0100, Tollef Fog Heen wrote: > You could partition the usb key and have a small partition for GPG/SSH > keys and the rest for normal data transfers and stuff. I was going to do the same, but picked up a rediculously cheap tiny USB key, and only use it for this purpose. Then I protect it with my life... I have a larger vfat key that I use for transfers etc too.. -- [EMAIL PROTECTED] - www.seigan.org PGP Key fingerprint = 4309 1C58 5143 AFAC F69E 11CD 76FD 56D4 1223 E387 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NPTL and static linking
On Wed, 9 Mar 2005 05:00:52 -0600, Peter Samuelson <[EMAIL PROTECTED]> wrote: > > Yes, dlopen, but the problem is version skew. With a dynamic libc6, > libc and the NSS modules will always be compatible. With a static > libc6, NSS functions (gethostbyname, getpwuid, etc.) will only work if > the target system has a very similar version of libc to the one the app > was linked with. Or they'll be ABI-incompatible and your program will > crash. Kind of defeats the purpose of static linking. Ah. I understand. That makes sense. > I know this is not directly related your question, but you displayed > what seemed to be a misunderstanding of the static + NSS problem, so. I appreciate the clarification. What is desirable, then, is for the developer to be able to statically link his or her own libraries, and third party libraries, but to dynamically pick up "system" libraries, of which I would number libpthread. That would be adequate for my needs. I expect this is possible, as *everything* is possible, somehow. Perhaps it is something as trivial as a compiler or linker flag that I have missed? -Blunt -:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cron-standard package to replace current tasks in 'cron'
On Wed, Mar 09, 2005 at 04:00:49PM +0100, David Schmitt wrote:
> Why {c,sh}ouldn't they be implemented as cron.daily scripts in the respective
> packages?
They are already are, please review the (simple) package. For some of the
packages that provide them (like systat) the tasks are pulled in from the
depends:, for other packages there might be users that might not want an
active cron job. Take 'sac' for example, a user that installs sac,
installs a tool to do something, he doesn't necessarily want a cronjob to
send sac's output to him weekly, for example.
Regards
Javier
signature.asc
Description: Digital signature
Re: Switchconf: Orphaning or removing?
On Wed, 09 Mar 2005 12:40:15 +0100, martin f krafft wrote: > I think switchconf is nice because it ties in well with guessnet, > and because it's lean and mean and does exactly what it should, no > more and no less. I agree that switchconf should be kept around so long as there is nothing else in Debian that provides the same functionality. laptop-net also contains a configuration file switching mechanism. I believe that Chris Hanson (laptop-net's author) was once thinking of repackaging this separately from laptop-net. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
On Mon, 07 Mar 2005 00:10:12 +0100, Christoph Hellwig wrote: > It's not a depency in any way. I play sound just fine with OSS drivers > without the ALSA mess getting in my way anywhere. On Mon, 07 Mar 2005 13:50:10 +0100, Josselin Mouette wrote: > Without alsa-base installed, hotplug and discover will load both > modules, resulting in various disasters depending on the hardware. It's > not because things work with your setup that they are suitable for a > stable Debian release. In theory I guess there should be an oss package that was the homologue of the alsa-base package. It would include files that would blacklist ALSA modules, just as alsa-base blacklists OSS modules. These packages would Conflict with each other and 2.6 kernel-image packages would Depend on their disjunction. An alternative is to drop ALSA modules from the 2.6 kernel-image packages. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NPTL and static linking
[EMAIL PROTECTED] said: > I appreciate the clarification. What is desirable, then, is for the > developer to be able to statically link his or her own libraries, and > third party libraries, but to dynamically pick up "system" libraries, > of which I would number libpthread. That would be adequate for my > needs. I expect this is possible, as *everything* is possible, > somehow. Perhaps it is something as trivial as a compiler or linker > flag that I have missed? I just figured out a way to do this for the ssh binary. Maybe this would work for you? Here's what I did: $ apt-get source ssh $ cd openssh-3.8.1p1 $ debian/rules build At first, we just want to get everything built. I only want to tinker with the final linking step. Now, I'm interested in having a statically linked ssh, except for libc. So I rm ssh and remake it, to see how it's linked: $ cd build-deb $ rm ssh $ make ssh (cd openbsd-compat && make) make[1]: Entering directory `/home/lunz/openssh-3.8.1p1/build-deb/openbsd-compat' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/lunz/openssh-3.8.1p1/build-deb/openbsd-compat' gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o -L. -Lopenbsd-compat/ -lssh -lopenbsd-compat -lresolv -lcrypto -lutil -lz -lnsl -lcrypt running that gcc invocation with -v, and we get: $ gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o -L. -Lopenbsd-compat/ -lssh -lopenbsd-compat -lresolv -lcrypto -lutil -lz -lnsl -lcrypt -v Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.5 (Debian 1:3.3.5-8) /usr/lib/gcc-lib/i486-linux/3.3.5/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o ssh /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crt1.o /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crti.o /usr/lib/gcc-lib/i486-linux/3.3.5/crtbegin.o -L. -Lopenbsd-compat/ -L/usr/lib/gcc-lib/i486-linux/3.3.5 -L/usr/lib/gcc-lib/i486-linux/3.3.5/../../.. ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o -lssh -lopenbsd-compat -lresolv -lcrypto -lutil -lz -lnsl -lcrypt -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc-lib/i486-linux/3.3.5/crtend.o /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crtn.o So we see how gcc calls its collect2. Calling _that_ with -v shows the linker invocation: $ /usr/lib/gcc-lib/i486-linux/3.3.5/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o ssh /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crt1.o /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crti.o /usr/lib/gcc-lib/i486-linux/3.3.5/crtbegin.o -L. -Lopenbsd-compat/ -L/usr/lib/gcc-lib/i486-linux/3.3.5 -L/usr/lib/gcc-lib/i486-linux/3.3.5/../../.. ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o -lssh -lopenbsd-compat -lresolv -lcrypto -lutil -lz -lnsl -lcrypt -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc-lib/i486-linux/3.3.5/crtend.o /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crtn.o -v collect2 version 3.3.5 (Debian 1:3.3.5-8) (i386 Linux/ELF) /usr/bin/ld --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o ssh /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crt1.o /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crti.o /usr/lib/gcc-lib/i486-linux/3.3.5/crtbegin.o -L. -Lopenbsd-compat/ -L/usr/lib/gcc-lib/i486-linux/3.3.5 -L/usr/lib/gcc-lib/i486-linux/3.3.5/../../.. ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o -lssh -lopenbsd-compat -lresolv -lcrypto -lutil -lz -lnsl -lcrypt -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc-lib/i486-linux/3.3.5/crtend.o /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crtn.o -v OK, so we can see how ssh really gets linked. At this point, I want to split the link into two steps: An initial static link that pulls everything in, and a final link to create a dynamic elf executable linked against libc. The ld option for incremental linking is -r. So I try stripping out everything related to gcc, libc, the dynamic linker, and creating elf output, and add -static: ld -r -static -o static.o -L. -Lopenbsd-compat/ ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o -lssh -lopenbsd-compat -lresolv -lcrypto -lutil -lz -lnsl -lcrypt This gives a file, static.o, where hopefully everything's linked in, except glibc and whatever gcc stub stuff is
Re: NPTL and static linking
Le mercredi 09 mars 2005 Ã 11:23 -0800, Blunt Jackson a Ãcrit : > I appreciate the clarification. What is desirable, then, is for the developer > to be able to statically link his or her own libraries, and third > party libraries, > but to dynamically pick up "system" libraries, of which I would number > libpthread. That would be adequate for my needs. I expect this is possible, > as *everything* is possible, somehow. Perhaps it is something as trivial > as a compiler or linker flag that I have missed? Yup, just enclose the libraries you want to link statically against between -Wl,-Bstatic and -Wl,-Bdynamic: gcc -o something foo.o bar.o -lsystemlib -Wl,-Bstatic -lownlib -lthirdpartylib -Wl,-Bdynamic -lpthread -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Mass bug filing: non-free Truetype fonts
After stumbling upon the non-free Adventure font in python-gd, I systematically checked all other Truetype fonts included in Debian (except for packages that contain only fonts, I expect their maintainers have already made sure they're free). The result is this list of about twenty packages. I plan to file "serious" bugs against each of them tomorrow or so. During my search I also found many packages that contain a copy of one of the Freefont or Bitstream Vera fonts instead of depending on the Debian packages for them. While legal, this wastes archive space. I plan to make a list of these packages and file bugs (at a lower severity) later. afterstep afterstep-2.00.02/libAfterImage/apps/test.ttf "Converted from F:\WINDOWS\TTFONTS\BLACKCHA.TF1 by ALLTYPE" No copyright/license information atris usr/share/games/atris/graphics/NewMediumNormal.ttf "Copyright © 1998 by Matthew Welch. All Rights Reserved." Non-free, see http://www.squaregear.net/fonts/ bglibs-doc usr/share/doc/bglibs-doc/latex/Helvetica.ttf This is Arial, not Helvetica. Probably from an old version of Windows. caudium usr/lib/caudium/fonts/ttf/fontrstc.ttf "© 1998 utopiafonts. [EMAIL PROTECTED]" and non-free, see readme.txt in http://www.reflectingarea.com/styling/fonts/creators/UtopiaFonts/FontRedSuit.zip caudium usr/lib/caudium/fonts/ttf/lucida_unicode.ttf caudium usr/lib/caudium/fonts/ttf/verdana.ttf Two Microsoft fonts. enlightenment-data usr/share/enlightenment/E-docs/aircut3.ttf enlightenment-data usr/share/enlightenment/E-docs/rothwell.ttf enlightenment-data usr/share/enlightenment/themes/BrushedMetal-Tigert/ABOUT/aircut3.ttf Two of Ray Larabie's fonts, non-free. enlightenment-data usr/share/enlightenment/E-docs/Verah___.ttf "BX Fonts 1997. This font may be used and distributed for free, but not be sold." enlightenment-theme-bluesteel usr/share/enlightenment/themes/BlueSteel/ABOUT/vixar.ttf enlightenment-theme-bluesteel usr/share/enlightenment/themes/BlueSteel/ttfonts/vixar.ttf "Copyright (c) 1995 Microsoft Corporation. All rights reserved." enlightenment-theme-ganymede usr/share/enlightenment/themes/Ganymede/ABOUT/ganymede.ttf enlightenment-theme-ganymede usr/share/enlightenment/themes/Ganymede/ttfonts/ganymede.ttf enlightenment-theme-ganymede usr/share/enlightenment/themes/Ganymede/ttfonts/ganymede_italic.ttf "Copyright 1990-1993 Bitstream Inc. All rights reserved." enlightenment-theme-shinymetal usr/share/enlightenment/themes/ShinyMetal/ABOUT/aircut3.ttf enlightenment-theme-shinymetal usr/share/enlightenment/themes/ShinyMetal/ttfonts/rothwell.ttf Larabie fonts. enlightenment-theme-shinymetal usr/share/enlightenment/themes/ShinyMetal/ttfonts/zirkle.ttf Zirkle by Ingrimayne Type, http://ingrimayne.saintjoe.edu/fonts/display_fontsB2.htm epplets usr/share/enlightenment/epplet_data/aircut3.ttf Again that Larabie font... freewrl usr/share/perl5/VRML/fonts/Amrigobi.ttf freewrl usr/share/perl5/VRML/fonts/Amrigob.ttf freewrl usr/share/perl5/VRML/fonts/Amrigoi.ttf freewrl usr/share/perl5/VRML/fonts/Amrigon.ttf freewrl usr/share/perl5/VRML/fonts/Baubodbi.ttf freewrl usr/share/perl5/VRML/fonts/Baubodi.ttf freewrl usr/share/perl5/VRML/fonts/Baubodn.ttf freewrl usr/share/perl5/VRML/fonts/Futurabi.ttf freewrl usr/share/perl5/VRML/fonts/Futurab.ttf freewrl usr/share/perl5/VRML/fonts/Futuran.ttf "Copyright 1990-1999 Bitstream Inc. All rights reserved." etc. No license. According to the readme, these came from a Red Hat 7.2 installation. I downloaded this distribution, but could find no trace of the fonts. gem usr/lib/pd/doc/gem/examples/05.text/arial.ttf gem usr/lib/pd/doc/gem/examples/data/arial.ttf gem usr/lib/pd/doc/gem/examples/data/cour.ttf gem usr/lib/pd/doc/gem/examples/data/times.ttf Arial, Courier New, and Times New Roman... gnurobbousr/share/games/gnurobbo/robbo.ttf ZapfHumnst L2, "Copyright 1990-1996 Bitstream Inc. All rights reserved." golem usr/share/golem/themes/eBlueSteel/vixar.ttf "Copyright (c) 1995 Microsoft Corporation. All rights reserved." gozer usr/share/gozer/fonts/helmetr.ttf "© 1999 Sun Microsystems, Inc." This font was erroneously included in some version of OpenOffice. icewm-themesusr/share/icewm/themes/jim-mac/Chicago.ttf "© 1990-91 Apple Computer Inc. © 1990-91 Type Solutions Inc. © 1990-91 The Font Bureau Inc." langband-data langband-data-0.1.6/fonts/augie.ttf "1997, steven j. lundeen, seattle, wa" Non-free: http://www.speakeasy.org/~ecf/augie.txt langband-data langband-data-0.1.6/fonts/lettergo.ttf langband-data langband-data-0.1.6/fonts/nova.ttf Two anonymous fonts, no copyright/license information. langband-data langband-data-0.1.6/fonts/luximb.ttf Luxi Mono Bold, ttf-xfree86-nonfree luola-data usr/share/games/luola/font/bluebold.ttf "Copyright (c) Ray Larabie, 2000. All rights reserved. freeware" moodle usr/share/moodle/lang/cs/fonts/default.ttf moodle usr/share/moodle/lang/en/fonts/defa
Re: The Right Way to turn a native package in a non native package with a NMU
On 03/09/2005 03:35 AM, Christian Perrier wrote: The .dsc file contains: .../... Files: fb6549efbab887efea88a8fcc4b4319f 451517 gnome-find_1.0.2.orig.tar.gz 7ea07e4e9226648422fb7a83d066ffe8 3400 gnome-find_1.0.2-1.1.diff.gz And the .changes: .../... Files: 733af0b63b2a63ac5ec3df7e46a9633a 659 utils optional gnome-find_1.0.2-1.1.dsc 7ea07e4e9226648422fb7a83d066ffe8 3400 utils optional gnome-find_1.0.2-1.1.diff.gz afea158735d04857e728d50312e17f7c 161412 utils optional gnome-find_1.0.2-1.1_i386.deb As waldi pointed out use -sa. The orig file should appear in the changes file as well, not only the dsc. K. -- Lucas Wall <[EMAIL PROTECTED]> .''`. Buenos Aires, Argentina: :ø : Debian GNU/Linux http://www.kadath.com.ar `. `' http://www.debian.org PGP: 1024D/84FB46D6 `- 5D25 528A 83AB 489B 356Ahttp://people.debian.org/~lwall 4087 BC9B 4733 84FB 46D6mailto:[EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: NPTL and static linking
On Wed, 9 Mar 2005 19:57:00 + (UTC), Jason Lunz <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] said: > > I just figured out a way to do this for the ssh binary. Maybe this would > work for you? > > Here's what I did: > > $ apt-get source ssh > $ cd openssh-3.8.1p1 > $ debian/rules build I appreciate the thought, but actually building glibc (and the nptl add-on) is a dangerous and daunting task. I looked into it for about half an hour, but glibc is a different order of beast from ssh entirely: it requires considerable configuration which is not for the casual developer, and installing it is a *very* touchy business. Of course, I would really only need to install the libpthread.a archive, but even so, building the whole glibc package is an involved and intensive undertaking and moreover... > Is there anything wrong with doing this? I have by doubts that this is > completely foolproof. Any libc macros or inlines will come from the > build system's libc, for example. I don't know if that can cause > problems when a different glibc version is dynamically linked at > runtime. Exactly. So I decided against this course of action entirely. For just about any application or library *other* than glibc, this would be the right approach for my needs. -Blunt -:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NPTL and static linking
On Wed, 09 Mar 2005 21:35:56 +0100, Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le mercredi 09 mars 2005 à 11:23 -0800, Blunt Jackson a écrit : > > I appreciate the clarification. What is desirable, then, is for the > > developer > > to be able to statically link his or her own libraries, and third > > party libraries, > > but to dynamically pick up "system" libraries, of which I would number > > libpthread. That would be adequate for my needs. I expect this is possible, > > as *everything* is possible, somehow. Perhaps it is something as trivial > > as a compiler or linker flag that I have missed? > > Yup, just enclose the libraries you want to link statically against > between -Wl,-Bstatic and -Wl,-Bdynamic: > > gcc -o something foo.o bar.o -lsystemlib -Wl,-Bstatic -lownlib > -lthirdpartylib -Wl,-Bdynamic -lpthread This, of course, is the right workaround. Thank you! -:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
Re: The Right Way to turn a native package in a non native package with a NMU
On Wed, Mar 09, 2005 at 07:03:41PM -0300, Lucas Wall wrote: > On 03/09/2005 03:35 AM, Christian Perrier wrote: > > >The .dsc file contains: > >.../... > >Files: > > fb6549efbab887efea88a8fcc4b4319f 451517 gnome-find_1.0.2.orig.tar.gz > > 7ea07e4e9226648422fb7a83d066ffe8 3400 gnome-find_1.0.2-1.1.diff.gz > > > >And the .changes: > >.../... > >Files: > > 733af0b63b2a63ac5ec3df7e46a9633a 659 utils optional > > gnome-find_1.0.2-1.1.dsc > > 7ea07e4e9226648422fb7a83d066ffe8 3400 utils optional > > gnome-find_1.0.2-1.1.diff.gz > > afea158735d04857e728d50312e17f7c 161412 utils optional > > gnome-find_1.0.2-1.1_i386.deb > > As waldi pointed out use -sa. The orig file should appear in the changes > file as well, not only the dsc. Yep. I think I added -sa option hints to new maint-guide recently since I scratch my head several times too when I cleaned BTS :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#298354: ITP: gtk2-engines-clearlooks -- An attractive gtk engine with a focus on usability.
El mar, 08-03-2005 a las 16:50 +0100, Marc 'HE' Brockschmidt escribió: > David Moreno Garza <[EMAIL PROTECTED]> writes: > > On Mon, 2005-03-07 at 17:21 +0100, Marc 'HE' Brockschmidt wrote: > >> Marco Alfonso <[EMAIL PROTECTED]> writes: > >>> * Package name: gtk2-engines-clearlooks > >>> Version : 0.4 > >> [...] > >>> This is a GTK+ 2.x engine based on Bluecurve. It features a modern look > >>> without sacrificing (much) speed. > >> Please look at http://ftp-master.debian.org/new.html, it's already in > >> the NEW queue. And hey, Ross, what about an ITP of your own? > > What should Marco do then? > > Nothing, really. He could try to talk with Ross to find out if he can > adopt the package [I'm pretty sure that Ross doesn't need yet another > package]. > > > He is learning how to make official Debian packages, he is following > > the procedure[1] suggested to people starting like him, > > I *think* I know what to do when you want to package a new > application. But thanks, anyway. hahahaha :-D > > > Wasn't the meaning of ITP reports to avoid double-efforts? > > > > And the ITP was sent more than 18 hours ago (as NEW states right now). > > The first upload is from 2005-02-27: > [EMAIL PROTECTED]:~$ ls -l > /org/ftp.debian.org/queue/new/clearlooks_0.3-1_i386.changes > -rw-rw-r--1 katiedebadmin 977 Feb 27 10:32 > /org/ftp.debian.org/queue/new/clearlooks_0.3-1_i386.changes > > But instead of starting to be more than a little bit rude, you should > have tried to understand the meaning of the last sentence in my mail. I > think this is Ross' error, he should have used the usual procedure to > announce that he wants to package the clearlooks theme. > > Marc Hello! Well, i want to help debian project, that's all, no problem for me, i'd like to package clearlooks engine, if ross wanna give me the package good, if not, good =p Just remember send the ITP before upload packages =p I'll expect answer from ross to continue or not, with the package... regards... -- Marco Alfonso Ocampo Puente [MaoP] <[EMAIL PROTECTED]> debianméxico [www.debianmexico.org] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: mipsel binutils/gcc/glibc shared library breakage
Pjotr Kourzanov wrote: > Dear Debian developers, > > I gather there are some people out there with MIPS little-endian > machines (from mipsel drop discussion) and Debian on it. Do huge shared > libraries (containing >4 symbols) work for you? I am currently > investigating an issue I have with my MIPS32r4, binutils > 2.14.90, > gcc-3.3.5 and glibc 2.3.2 (all Debian sources), which prevents e.g. > Qt/Embedded to be used as shared library. The Debian binutils refuse to build multigot libraries with more than 16k external symbols. This is a workaround to prevent silent breakage, and most larger shared libraries can still be built by compiling with -Wa,-xgot. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
On Tue, Mar 08, 2005 at 03:11:02PM -0800, Steve Langasek wrote: > On Tue, Mar 08, 2005 at 04:54:34PM +0100, Sven Luther wrote: > > On Tue, Mar 08, 2005 at 06:12:03AM -0800, Anthony Towns wrote: > > > Sven Luther wrote: > > > >>It's hard to take this sort of discussion as anything but an attack on > > > >>ftpmaster, since there are plenty of teams in Debian that're even less > > > >>transparent and effective than us. But given how these sorts of > > > >But they are less a hindrance to the daily work of maintainers, and can > > > >thus > > > >more easily be avoided/worked around/whatever. > > > > If you think ftpmaster is a hindrance to your daily work, it's trivial > > > to avoid it -- upload to your own site instead, or to people.debian.org. > > > And hack debian-installer to by default get powerpc kernels out of a > > personal > > archive ? I almost did that when NEW processing disintegrated two years ago > > during the compromise, but i don't think this is compatible with the > > release-management work surrounding the d-i. > > > As a result of 1 and a half month waiting in processing the > > kernel-latest-powerpc metapackage for example, we will not have support for > > it > > in d-i rc3, for example, and thus future upgrades of kernels installed with > > it > > will be problematic. > > Here is the relevant section of the .changes file for the package in > question: > > Date: Wed, 12 Jan 2005 17:40:59 +0100 > Source: kernel-latest-powerpc > [...] > Changes: >kernel-latest-powerpc (101) unstable; urgency=low >. > * Typo in debian/control created kernel-headers-2.[46]-powerpc instead of >kernel-headers-2.[46]. Fixing this means another wait in the NEW queue > :( > > > This merely underscores the contrast between Anthony's recommendation -- > being resourceful enough to find a way to achieve the things you care about > when no one is interested in helping you -- and what you've done in this > case -- whine that a name change on *headers* metapackages that are used > nowhere in the installer prevented you from improving the quality of that > installer. It was a damn typo i oversighted in the 100 version. And the mention that itmeans a wait in the NEW queue was in no way a whining, but an informative mention to whoever would look in the svn archive for the package wondering why this problem (which marked kernel-latest-powerpc uninstallable for almost two month) was indeed solved and waiting in NEW. and notice that these packages are not used on powerpc because Kamion didn't modify base-installer to use them, while they are used (unless i am mistaken) in the x86 case, and in general are meant to be used, which makes changing kernel possible without rebuilding the base-installer .udeb, and thus allows more flexibility. Notice also that the metapackages in question where ones transfered from wheree Jens had put them, namely in the kernel-images themselves, which caused lot of breakage as you well know once we had more than one kernel version in the archive. I mentioned this fact to Kamion, and he told me he would not bother ftp-masters about this, since the packages name where to generic for his, and dismissing my argument that these where the names of the kernel-header metapackages previously used. I also wrote an email to ftp-masters explaining why it was important that this package got processed to the d-i release schedule, and also mentioning 2.6.10 whihc was a potential release candidate, that email was helpfull and nice, but i got nil reply to it. And i think that this is the real problem here, any mention of the NEW queue is seen by the ftp-masters and others involved like whining, and there is a knee-jerk reaction to fully dismiss the issue as far as possible then, while it may well be some half humorous attempt to get over the frustration of it or just be informative. > And with all that, the kernel-latest-powerpc package is still in an RC > broken state, because you chose to make a last-minute reorganization of > kernel-patch-powerpc-2.4.27 without updating kernel-latest-powerpc to match. > You can hardly blame the ftpmasters for this state of affairs. Nope, i uploaded the fix. it's in NEW again i think, let me check. Ah, no, they where accepted on march 5, please check your sources before making such aggressive claims. And you can't really take the argument both way, in one saying that the ftp-master are volunteers and work on things as their time allows, and on the other side imply that the rest of the developers are just slaves to be held to thight release schedules. > > And we will soon upload 2.6.11 kernels, which will mean handling of N+1 NEW > > packages, where N is the number of architectures supporting the 2.6 kernels. > > This could easily enough be automated, and i don't think the NEW reporting > > to > > the US agencies needs to go done to the level of renamed binary packages or > > new versions of basically the same thing. > > Fran
Re: grass and Packages-arch-specific
Wouter Verhelst wrote: > Op za, 05-03-2005 te 14:26 +0100, schreef Thiemo Seufer: > > Steve Halasz wrote: > > > Hi, > > > > > > I've sent a few emails over the last month to [EMAIL PROTECTED] and > > > [EMAIL PROTECTED] requesting that grass be removed from > > > packages-arch-specific. But my pleas have fallen on deaf ears, or > > > perhaps overzealous spam filters. Are you guys out there? Is there > > > anyone else who can make this change for me? > > > > File a bug against the ftp.debian.org pseudopackage. > > Packages-arch-specific has nothing to do with ftp.d.o But the resulting packages do, and there is no buildd pseudopackage, so ftp.d.o is the closest match in the BTS. Some P-a-s bugs are filed there. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
On Mon, 07 Mar 2005 20:40:40 +0100, Josselin Mouette wrote: > Actually, the proposed solution that raised some approval was to split > out the ALSA modules, just like the pcmcia modules. I raised this idea on #debian-kernel and it was shot down.[0] [0]http://lists.alioth.debian.org/pipermail/pkg-alsa-devel/2005-March/002039.html As one of the ALSA maintainers, I have done what I can about this problem. People who want to use ALSA can install alsa-base which blacklists OSS modules. If a fresh sarge/2.6 system lacks alsa-base then this would seem to be a problem because in that case nothing enforces the mutual exclusion of OSS and ALSA modules. If linux26 doesn't install alsa-base then perhaps it should do so. Even better, possibly, would be to give the user a choice between OSS and ALSA: if the user chooses ALSA then she gets alsa-base; if she chooses OSS then she gets the (currently nonexistent) "oss" package which blacklists ALSA modules. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
Le mercredi 09 mars 2005 Ã 20:33 +0100, Thomas Hood a Ãcrit : > In theory I guess there should be an oss package that was the homologue of > the alsa-base package. It would include files that would blacklist ALSA > modules, just as alsa-base blacklists OSS modules. These packages would > Conflict with each other and 2.6 kernel-image packages would Depend on > their disjunction. Doing that, you'll get the same criticisms from people who don't want sound. > An alternative is to drop ALSA modules from the 2.6 kernel-image packages. Yes, we agree that this is a good solution. The questions now are whether the kernel maintainers want to do this, and whether this is feasible before the release. Kernel maintainers, could you say a word about that issue? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
Le jeudi 10 mars 2005 Ã 00:12 +0100, Thomas Hood a Ãcrit : > On Mon, 07 Mar 2005 20:40:40 +0100, Josselin Mouette wrote: > > Actually, the proposed solution that raised some approval was to split > > out the ALSA modules, just like the pcmcia modules. > > > I raised this idea on #debian-kernel and it was shot down.[0] > > [0]http://lists.alioth.debian.org/pipermail/pkg-alsa-devel/2005-March/002039.html OK, so let's forgot this idea and try to find something else. > As one of the ALSA maintainers, I have done what I can about this problem. > People who want to use ALSA can install alsa-base which blacklists OSS > modules. > > If a fresh sarge/2.6 system lacks alsa-base then this would seem to be a > problem because in that case nothing enforces the mutual exclusion of OSS > and ALSA modules. If linux26 doesn't install alsa-base then perhaps it > should do so. Even better, possibly, would be to give the user a choice > between OSS and ALSA: if the user chooses ALSA then she gets alsa-base; > if she chooses OSS then she gets the (currently nonexistent) "oss" package > which blacklists ALSA modules. Yes, but some package has to depend on it. Some package installed in the default desktop install. I think gnome-media is a good candidate; however it is not maintained by the GNOME team, CCing the maintainer. Davide, would you agree with making gnome-media depend on something like "alsa-base | kernel-image-2.4", to ensure sound is working properly upon installation? I know some people will say this can give stupid results when both 2.4 and 2.6 kernel images are installed. However, it allows things to work, with OSS when the 2.4 kernel is installed, and with ALSA if this is a 2.6 installation. There won't be any clean solution until hotplug implements a per-kernel blacklist. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Key management using a USB key
On Tue, Mar 08, 2005 at 12:46:46AM +0100, David Härdeman wrote: I've been meaning for some time to get a USB key to manage private keys (such as gpg, ssh, etc), but it's not until recently that I tried to sit down and sketch on how to implement it (filesystem layout, functionality, which parts are encrypted and accessed at which points in time etc). It turns out that it was not as obious as I thought. [...] It would be very interesting to hear how others manage this... Ok, based on the script from Sean Finney and the feedback from the others (thanks all!). I've written a rough draft of how *I* would like things to work. It's divided into three parts, and also requires the keychain tool[1]. The first file, is a simple udev rule which creates a /dev/cryptdisk node when the appropriate usb key is inserted (proper as decided by the various conditions which one can list in a udev rule). It can be placed in /etc/udev/rules.d/cryptkey.rules. Then, a script which is run after the appropriate device node is created or removed. This script is plopped into /etc/dev.d/block/cryptdisk.dev. This script mounts the drive, checks who it belongs to (by reading the "keyowner" file in the root dir of the USB key), mounts it again with the proper permissions for that user and then calls the third piece. The third script, which is run as the user who "owns" the key, loads the ssh keys from the usb key and into ssh-agent. The advantage is that this script can also be called from eg. .xsession to load keys from usb devices which were already present during boot. It also allows one to load keys even if X isn't running. The scripts are a bit rough at the moment, I wrote them in a hurry, but I'll clean them up a bit more later, I wanted to get something through the door. They "work-for-me" right now (loading keys, with ssh-askpass dialogue, and removing them when the usb key is removed). I'll work more on the scripts during the weekend (adding some of the TODO's, documentation). Regards, David [1] http://www.gentoo.org/proj/en/keychain/index.xml [2] http://www.hardeman.nu/~david/keyload/ PS Right now, the scripts are licensed under a "david-owes-sean-a-pizza" license =) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
On Thu, Mar 10, 2005 at 12:12:37AM +0100, Thomas Hood wrote: > On Mon, 07 Mar 2005 20:40:40 +0100, Josselin Mouette wrote: > > Actually, the proposed solution that raised some approval was to split > > out the ALSA modules, just like the pcmcia modules. > I raised this idea on #debian-kernel and it was shot down.[0] > [0]http://lists.alioth.debian.org/pipermail/pkg-alsa-devel/2005-March/002039.html > As one of the ALSA maintainers, I have done what I can about this problem. > People who want to use ALSA can install alsa-base which blacklists OSS > modules. > If a fresh sarge/2.6 system lacks alsa-base then this would seem to be a > problem because in that case nothing enforces the mutual exclusion of OSS > and ALSA modules. If linux26 doesn't install alsa-base then perhaps it > should do so. Even better, possibly, would be to give the user a choice > between OSS and ALSA: if the user chooses ALSA then she gets alsa-base; > if she chooses OSS then she gets the (currently nonexistent) "oss" package > which blacklists ALSA modules. Considering you're talking about solutions that require updates to kernel-image packages *anyway*, why has no one suggested adding the necessary blacklist entries to these packages? Far better than removing a bunch of modules from the kernel-image at this late stage, IMHO. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
On Thu, Mar 10, 2005 at 12:20:36AM +0100, Sven Luther wrote: > On Tue, Mar 08, 2005 at 03:11:02PM -0800, Steve Langasek wrote: > > On Tue, Mar 08, 2005 at 04:54:34PM +0100, Sven Luther wrote: > > Here is the relevant section of the .changes file for the package in > > question: > > Date: Wed, 12 Jan 2005 17:40:59 +0100 > > Source: kernel-latest-powerpc > > [...] > > Changes: > >kernel-latest-powerpc (101) unstable; urgency=low > >. > > * Typo in debian/control created kernel-headers-2.[46]-powerpc instead > > of > >kernel-headers-2.[46]. Fixing this means another wait in the NEW > > queue :( > > This merely underscores the contrast between Anthony's recommendation -- > > being resourceful enough to find a way to achieve the things you care about > > when no one is interested in helping you -- and what you've done in this > > case -- whine that a name change on *headers* metapackages that are used > > nowhere in the installer prevented you from improving the quality of that > > installer. > It was a damn typo i oversighted in the 100 version. And the mention that > itmeans a wait in the NEW queue was in no way a whining, but an informative > mention to whoever would look in the svn archive for the package wondering why > this problem (which marked kernel-latest-powerpc uninstallable for almost two > month) was indeed solved and waiting in NEW. > and notice that these packages are not used on powerpc because Kamion didn't > modify base-installer to use them, while they are used (unless i am mistaken) > in the x86 case, and in general are meant to be used, which makes changing > kernel possible without rebuilding the base-installer .udeb, and thus allows > more flexibility. According to the changes file, the changes found in the version of kernel-latest-powerpc that was stuck in NEW were *completely orthogonal* to the use of these kernel-image metapackages could be used from within base-installer. NEW processing has *nothing* to do with why base-installer wasn't updated, and you are way off-base in blaming the ftpmasters for this. > Notice also that the metapackages in question where ones transfered from > wheree Jens had put them, namely in the kernel-images themselves, which caused > lot of breakage as you well know once we had more than one kernel version in > the archive. Off-hand, no, I can't think of any breakage that this caused; it's possible Colin took care of it before I noticed it, of course. > I mentioned this fact to Kamion, and he told me he would not bother > ftp-masters about this, since the packages name where to generic for his, and > dismissing my argument that these where the names of the kernel-header > metapackages previously used. Yes, because Colin has the good sense to know that kernel-header metapackages have no bearing on the installer. > I also wrote an email to ftp-masters explaining why it was important that this > package got processed to the d-i release schedule, and also mentioning 2.6.10 > whihc was a potential release candidate, that email was helpfull and nice, but > i got nil reply to it. Well, since you were wrong about it being important to the d-i release schedule, I can't fault them for expediting the package on your say-so, can I? > And i think that this is the real problem here, any mention of the NEW queue > is seen by the ftp-masters and others involved like whining, and there is a > knee-jerk reaction to fully dismiss the issue as far as possible then, while > it may well be some half humorous attempt to get over the frustration of it or > just be informative. No, it's really just absurd posts claiming that lack of NEW processing is preventing them from doing useful work that earn the label of "whining" here. > > And with all that, the kernel-latest-powerpc package is still in an RC > > broken state, because you chose to make a last-minute reorganization of > > kernel-patch-powerpc-2.4.27 without updating kernel-latest-powerpc to match. > > You can hardly blame the ftpmasters for this state of affairs. > Nope, i uploaded the fix. it's in NEW again i think, let me check. Ah, no, > they where accepted on march 5, please check your sources before making such > aggressive claims. Sorry, I missed the changelog on version 102; I didn't realize you'd changed the dependencies of the kernel-image-power[34] metapackages. Retracted. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Cron-standard package to replace current tasks in 'cron'
hi, On Wed, Mar 09, 2005 at 08:36:24PM +0100, Javier Fernández-Sanguino Peña wrote: > They are already are, please review the (simple) package. For some of the > packages that provide them (like systat) the tasks are pulled in from the > depends:, for other packages there might be users that might not want an > active cron job. Take 'sac' for example, a user that installs sac, > installs a tool to do something, he doesn't necessarily want a cronjob to > send sac's output to him weekly, for example. i would argue then that user should use a tool called "rm", or "mv" :) sean -- signature.asc Description: Digital signature
Re: The Right Way to turn a native package in a non native package with a NMU
> So use -sa. I forgot to ACK this : the suggestion was of course correct. Thanks for the "tip" (which indeed could have been a RTFM.:-)) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
Thomas Hood <[EMAIL PROTECTED]> writes: > On Mon, 07 Mar 2005 20:40:40 +0100, Josselin Mouette wrote: >> Actually, the proposed solution that raised some approval was to split >> out the ALSA modules, just like the pcmcia modules. > > > I raised this idea on #debian-kernel and it was shot down.[0] > > [0]http://lists.alioth.debian.org/pipermail/pkg-alsa-devel/2005-March/002039.html > > As one of the ALSA maintainers, I have done what I can about this problem. > People who want to use ALSA can install alsa-base which blacklists OSS > modules. > > If a fresh sarge/2.6 system lacks alsa-base then this would seem to be a > problem because in that case nothing enforces the mutual exclusion of OSS > and ALSA modules. If linux26 doesn't install alsa-base then perhaps it > should do so. Even better, possibly, would be to give the user a choice > between OSS and ALSA: if the user chooses ALSA then she gets alsa-base; > if she chooses OSS then she gets the (currently nonexistent) "oss" package > which blacklists ALSA modules. The kernel could blacklist alsa modules by default and the alsa-base would divert that to blacklist oss. That sounds the simplest. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
