Re: Which 64 bit cpu assembler to use ?
thank you very much On Sun, Jun 22, 2008 at 12:51 PM, Jack T Mudge III [EMAIL PROTECTED] wrote: On Saturday 21 June 2008 09:14:31 pm Star Liu wrote: Greetings! I'm a newbie in assembly language programming, for I worked as a C# programmer on microsoft platform in the past years, but now I want to know clearly how operating system and softwares are executed, so I begin to learn assembly language programming, I have learned some 32 bit asm coding, and want to move to 64 bit coding. Is there any good toturial to follow? and which assembler should I use? (I have a amd64 etch installed for this task) Thanks! This is a bit off-topic for this board -- this board is for debian package sponsorship, and discussion related to maintaining debian packages. http://linuxquestions.org has a forum about programming. Maybe ask there for anything else you want to know (instead of being off-topic here) However, I'll give you a couple pointers to get you started: - nasm and yasm seem to be the assemblers available in Debian right now. - get an emulator (I use Bochs), you won't have to reboot and you'll be able to use a debugger. - Look up http://www.linuxassembly.org/ (assembly programming in linux) and http://www.osdever.net/ (all about writing operating systems) - Jack Mudge [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- - Buddha Debian GNU/Linux MSN/aMSN: [EMAIL PROTECTED] -
Re: RFS: gvb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Holger Levsen ha scritto: Hi Pietro, Unfortunatly I dont have time to sponsor it (as this also needs continous involvement), You mean every package does or this package particularly does? (If it's the second: why?) but I had time to briefly look at it and here are some comments: On Sunday 22 June 2008 10:31, Pietro Battiston wrote: This seems to me the right place to look if there is someone interested in sponsoring a package I made. still, you should probably crosspost to debian-mentors, too... Posting do debian-mentors is the first thing I did, some days ago... Anyway, I'm cross-posting this reply too. The package is gvb (http://mentors.debian.net/debian/pool/main/g/gvb/gvb_1.1.2-1.dsc) It is completely GPL v.3. I am the upstream developer. in debian/copyright you say it's GPL2+, while the file COPYING says GPL3+ - please make up your mind ;) (And then debian/copyrights refers to /usr/share/common-licences/GPL, which is the GPL3, so that's another (normal) bug.) Another minor bug in debian/copyright: The icons of the program are screenshots of the program itself and also are covered by GLP license. - GLP? :) Please also remove the word nice from the short description (debian/control), all software is nice, isn't it? :) No, I think Linux Kernel is a nice piece piece of software in a geek sense, gvb is (I hope) in a more literal sense. I just wanted to spot the fact that some attention is given to aestethical appearance of the GUI. Anyway, I understand there is risk of misunderstanding, so I removed it. Also I think you can completly drop the last paragraph of the description: It is written in Python and based on Pygtk and Cairo for the interface. It relies on scipy for calculations. - this information is provided by the (build-)depends and can also be represented with debtags. Thank you for spotting those errors. Actually, I did remove references to Python, Pygtk and Cairo because they are indeed informations targeted basically to developers, but I think it is better to keep the one to scipy, because it is a library targeted even to non developers (e.g. as replacement for matlab), and for instance someone using Synaptic (where you don't see immediately dependences) could find it interesting. Obviously, all this has been fixed in version 1.1.2-2: http://mentors.debian.net/debian/pool/main/g/gvb/gvb_1.1.2-2.dsc Thank you for your attention Pietro Battiston -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIXh9+cZVtR82bmAYRAoRxAKClRBncHZIdIPR3ELHuWwJTkbHr2QCeLzAf EDd2WrMOamjnqNOy2VUa+TA= =FEf9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gvb
Hi, On Sunday 22 June 2008 11:46, Pietro Battiston wrote: Unfortunatly I dont have time to sponsor it (as this also needs continous involvement), You mean every package does or this package particularly does? (If it's the second: why?) Every package does. If someone sponsors something, (s)he is requiered to subscribe to the PTS and to react to bugs submitted. Posting do debian-mentors is the first thing I did, some days ago... Anyway, I'm cross-posting this reply too. Ok, cool. Obviously, all this has been fixed in version 1.1.2-2: http://mentors.debian.net/debian/pool/main/g/gvb/gvb_1.1.2-2.dsc Cheers, thanks. Now someone with upload rights just needs to pick it up :) regards, Holger pgpiWzbZU6v1N.pgp Description: PGP signature
RFS: arping (updated package - ITA)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for the new version 2.07pre1-1 of my package arping. It builds these binary packages: arping - sends IP and/or ARP pings (to the MAC address) The package appears to be lintian clean. The upload would fix these bugs: 210992, 436472, 487334 The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/a/arping - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/a/arping/arping_2.07pre1-1.dsc I would be glad if someone uploaded this package for me. Kind regards Giuseppe Iuculano -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIXjN7Nxpp46476aoRArapAJ4/JqT00pFyxMPEL8IFPxfoCQHYBQCdEYrq ThAXUiBf78z9LPWiPM6CYKA= =WLgr -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: atmailopen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for my package atmailopen. * Package name: atmailopen Version : 1.01-1 Upstream Author : @Mail [EMAIL PROTECTED] * URL : http://www.atmail.org/ * License : Apache License Version 2.0 Section : web Description: An Open Source Webmail Client AtMail is an open source webmail client written in PHP. It aim to provide an elegant Ajax webmail client for existing IMAP mailservers, with less bloat and a focus on an intuitive, simple user interface. . The open source version of AtMail provides users with a lightweight, yet powerful webmail client. The software can be installed on a variety of platforms with ease and without the hassles that most webmail platforms impart. . Features of AtMail Open include: * Lightweight Ajax Webmail Interface * Video Mail * PHP source code * IMAP support * Live Spell Check * Address Book It builds these binary packages: atmailopen - An Open Source Webmail Client The package appears to be lintian clean. The upload would fix these bugs: 487263 (ITP) The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/a/atmailopen - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/a/atmailopen/atmailopen_1.01-1.dsc I would be glad if someone uploaded this package for me. Kind regards Giuseppe Iuculano -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIXjTnNxpp46476aoRAkO3AJ9xygmZ4Vm1fiP/U6V0KvGxFfSyGQCeMqzt 6Z8+CWna3s+e0QV4MPYricY= =T7KC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: arping (updated package - ITA)
Giuseppe Iuculano [EMAIL PROTECTED] (22/06/2008): -BEGIN PGP SIGNED MESSAGE- Maybe you want to use PGP/MIME? Mails then become readable. ;-) I am looking for a sponsor for the new version 2.07pre1-1 of my package arping. Shouldn't it be 2.07~pre1-1, so that you can version the real release as 2.07-1? You may want to check for an appropriate versioning with dpkg: “dpkg --compare-versions 2.07pre1-1 lt 2.07-1 echo ok” vs “dpkg --compare-versions 2.07~pre1-1 lt 2.07-1 echo ok” I would be glad if someone uploaded this package for me. I have a package of mine to take care of, your package is the next in my queue. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: arping (updated package - ITA)
Cyril Brulebois ha scritto: Maybe you want to use PGP/MIME? Mails then become readable. ;-) Ok :) Shouldn't it be 2.07~pre1-1, so that you can version the real release as 2.07-1? You may want to check for an appropriate versioning with dpkg: “dpkg --compare-versions 2.07pre1-1 lt 2.07-1 echo ok” vs “dpkg --compare-versions 2.07~pre1-1 lt 2.07-1 echo ok” Fixed, thanks. I have a package of mine to take care of, your package is the next in my queue. Thanks a lot. Giuseppe. signature.asc Description: PGP signature signature.asc Description: OpenPGP digital signature
Re: RFS: scim-python: python bindings and input methods for scim
On Sun, Jun 22, 2008 at 10:43:18AM +0800, LI Daobing (李道兵) wrote: Hi, Would u mind tell me how to use it? after I built the packge with your source tarball(built with updated sid sbuild), and installed those binary packages, except the dbg one, re-login, I could not have it in skim. so is there anything wrong? or it can not work with skim? Hello, On Sun, Jun 22, 2008 at 9:05 AM, Ming Hua [EMAIL PROTECTED] wrote: On Sun, Jun 22, 2008 at 12:00:04AM +0800, LI Daobing (李道兵) wrote: On Sat, Jun 21, 2008 at 11:48 PM, Zhengpeng Hou [EMAIL PROTECTED] wrote: what's the license of the pinyin table data in scim-pinyin? not declared, I will ask the upstream authors. and this file is not required. we can prepare a dfsg version. The Pinyin data in scim-python are not DFSG-free as far as I know. there are two pinyin table: 1. http://code.google.com/p/scim-python/source/browse/trunk/data/pinyin_table.txt 2. http://code.google.com/p/scim-python/downloads/detail?name=pinyin-database-0.1.10.5.tar.bz2can=2q= you mean which one is non-free, or both? -- Best Regards, LI Daobing -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: RFS: arping (updated package - ITA)
Giuseppe Iuculano [EMAIL PROTECTED] (22/06/2008): Ok :) Thanks. :) Shouldn't it be 2.07~pre1-1, so that you can version the real release as Fixed, thanks. You then need to use version mangling in your debian/watch file. Check for dversionmangle in uscan(1). BTW, you're still using “version=2” while current version is 3. Thanks a lot. No need to thank before you get the review. Here it goes: debian/changelog: - You close #210992 in the “New upstream release” entry. While this is strictly speaking correct, it might be nice to specify that this isn't just closing a “please package new upstream release” bug, but a “real” bug. You might use something like: | * New upstream release. libnet is now initialized correctly, which fixes |the segmentation fault on imbecile user input (Closes: #210992). - You might want to thank the previous maintainer for his former contribution in your “closing ITA” entry, but that's really your call. :) - You rewrote debian/rules. OK. But that'd be nice to say why it fixes #436472 (e.g. “now handles nostrip build option”). - When you added the debhelper compat level, did you make sure that nothing had to be adapted from the previous behaviour, as it's documented in “Debhelper compatibility levels” from debhelper(7)? I know arping is quite a tiny package, but still, there could be some surprizes. - Did you forward the manpage fix upstream? While you're at it, there's another one to fix (with some occurrences), namely: I: arping: hyphen-used-as-minus-sign usr/share/man/man8/arping.8.gz You have to run lintian with e.g. -iI to have it displayed, as it's only an I:, not a W: or E:. - You could add your address in debian/copyright, 3rd line. You could also use © instead of (C). The following would be sufficient: “Copyright: © 2000-2003 Thomas Habets [EMAIL PROTECTED]” You could ask upstream to add license headers to *.h, and probably to update the copyright years in arping-2/arping.c at least. And while we're at it, the FSF address is outdated. (licensecheck -r . is your friend, by the way.) Ah, and you may also want to specify a license for the Debian packaging. Usually, “The Debian packaging is licensed under the same terms and is: © $years $you” is seen. - During the build, I've noticed the -I targeting /usr/local. I guess it could possibly break the build under some circumstances (when having incompatible versions of the libraries under /usr/local), so you may want to strip those locations from the -I/-L flags. I think that's all for now. :) Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: windowlab (QA upload, fixes RC bug)
On Saturday 21 June 2008, Ansgar Burchardt wrote:
Hi!
Hi,
--cut--
Your changes seems to bring improvements..., yet could you please also
fix debian/rules so that both the binary-arch (buildd's call
`/usr/bin/fakeroot debian/rules binary-arch') and binary-indep targets
exist (see Policy 4.9) and so that `fakeroot debian/rules binary' works
as well.
Done. Thanks for noticing.
Uploaded.
I also changed the packaging to use debhelper and quilt instead of
cdbs, and updated the package to conform to the latest version of
Debian policy.
Did you check with
/usr/share/doc/debian-policy/upgrading-checklist.txt.gz since
debian/changelog only reads Bump Standards Version to 3.8.0, but
doesn't list the exact changes done to align the package with 3.8.0, or
there were no changes needed to comply with 3.8.0; if any please say so,
probably by means of sub-bullets ;-)
There are several changes: the Homepage field in debian/control, the
README.source, and the get-orig-source target. These changes are listed in
the changelog. As two of them are already sub-bullets of other changes, I
think it isn't a good idea to move them.
Fine.
By the way, if you need a more expressive get-orig-source you can borrow
some bits from the stealth package for instance.
I added an md5sum check in the get-orig-source target for windowlab.
The get-orig-source from stealth seems to require to be started in the
package directory in order to inspect debian/changelog and doesn't leave
the generated tarball in the current directory, which doesn't seem policy
compliant, so I did not do this in windowlab.
Yes, it was created after svn-buildpackage default layout
(package/{trunk,tags,branches,tarballs}), but it is probably a good idea not
to occupy the get-orig-source target for that, but use another one instead.
Thanks for the good catch.
I uploaded an updated package to mentors:
http://mentors.debian.net/debian/pool/main/w/windowlab/windowlab_1.34-1.dsc
Thanks for the review!
At least the updated package is better than the one currently found in the
archive ;-) As a further improvement you can use something like ucf for
instance to gracefully handle configuration files in /etc/X11/windowlab/.
--
pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: scim-python: python bindings and input methods for scim
Hello, 2008/6/22 ZhengPeng Hou [EMAIL PROTECTED]: On Sun, Jun 22, 2008 at 10:43:18AM +0800, LI Daobing (李道兵) wrote: Hi, Would u mind tell me how to use it? after I built the packge with your source tarball(built with updated sid sbuild), and installed those binary packages, except the dbg one, re-login, I could not have it in skim. so is there anything wrong? or it can not work with skim? I does not test with skim, and it should does NOT work, please test with scim. thanks. -- Best Regards, LI Daobing -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: randtype (updated package)
Vincent Bernat [EMAIL PROTECTED] writes: OoO En ce début d'après-midi nuageux du samedi 21 juin 2008, vers 14:08, Eugene V. Lyubimkin [EMAIL PROTECTED] disait : Moreover, you might want to fix the manpage for the hyphen used as minus sign lintian warning. Probably, lintian is right. But, upstream ships man page gzipped... So, patching man page will require unpack it, make several sed expressions (or duplicate right man in debian/ dir), say dh_installman explicitly use patched man page instead of original one... IMHO, this minor warning doesn't cost these manipulations... Though, If you claim that this is a significant, I'll fix it (may be, you know less expensive way to patch it?). You can use some shell magic: gunzip blah.1.gz sed -i 's/\B-/\\-/g' blah.1 [...] dh_installman blah.1 You should of course check that sed is really doing its job. Wouldn't it be better to generate an uncompressed manpage as part of the appropriate debian/rules rule, and then use a standard debian/patches utility (e.g. quilt) to escape only those hyphens that need it? Something like (completely untested): ## Upstream ships compressed files within their tarball; boy are ## they silly. clean:: rm -f foo.1 build:: foo.1 foo.1:: foo.1.gz gunzip -c $ $@ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: randtype (updated package)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Trent W. Buck wrote: Probably, lintian is right. But, upstream ships man page gzipped... So, patching man page will require unpack it, make several sed expressions (or duplicate right man in debian/ dir), say dh_installman explicitly use patched man page instead of original one... IMHO, this minor warning doesn't cost these manipulations... Though, If you claim that this is a significant, I'll fix it (may be, you know less expensive way to patch it?). You can use some shell magic: gunzip blah.1.gz sed -i 's/\B-/\\-/g' blah.1 [...] dh_installman blah.1 You should of course check that sed is really doing its job. Wouldn't it be better to generate an uncompressed manpage as part of the appropriate debian/rules rule, and then use a standard debian/patches utility (e.g. quilt) to escape only those hyphens that need it? Something like (completely untested): ## Upstream ships compressed files within their tarball; boy are ## they silly. clean:: rm -f foo.1 build:: foo.1 foo.1:: foo.1.gz gunzip -c $ $@ Too complicated, as for me. For such a tiny package :) Moreover, mixing quilt (for one patch) and debian/rules methods would lead me to add build-dependency on quilt... And Vincent's method just works now :) But thanks for look. - -- Eugene V. Lyubimkin aka JackYF, Ukrainian C++ developer. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIXmTnchorMMFUmYwRAp5HAKDAHU6WiMsf4yYyPtJYdSQl6ePJSgCcD5xY DgNFPZ1Yy5q5QI0RBWY1Ja8= =43ul -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: arping (updated package - ITA)
Cyril Brulebois ha scritto: You then need to use version mangling in your debian/watch file. Check for dversionmangle in uscan(1). BTW, you're still using “version=2” while current version is 3. I modified debian/watch : version=3 opts=dversionmangle=s/\~// \ ftp://ftp.habets.pp.se/pub/synscan/arping-(.*)\.tar\.gz It seems to be correct now. debian/changelog: - You close #210992 in the “New upstream release” entry. While this is strictly speaking correct, it might be nice to specify that this isn't just closing a “please package new upstream release” bug, but a “real” bug. You might use something like: | * New upstream release. libnet is now initialized correctly, which fixes |the segmentation fault on imbecile user input (Closes: #210992). Done. - You might want to thank the previous maintainer for his former contribution in your “closing ITA” entry, but that's really your call. :) Done :) - You rewrote debian/rules. OK. But that'd be nice to say why it fixes #436472 (e.g. “now handles nostrip build option”). Done. - When you added the debhelper compat level, did you make sure that nothing had to be adapted from the previous behaviour, as it's documented in “Debhelper compatibility levels” from debhelper(7)? I know arping is quite a tiny package, but still, there could be some surprizes. I did it, I think nothing had to be adapted from the previous behaviour. - Did you forward the manpage fix upstream? Done. While you're at it, there's another one to fix (with some occurrences), namely: I: arping: hyphen-used-as-minus-sign usr/share/man/man8/arping.8.gz You have to run lintian with e.g. -iI to have it displayed, as it's only an I:, not a W: or E:. Done. - You could add your address in debian/copyright, 3rd line. You could also use © instead of (C). The following would be sufficient: “Copyright: © 2000-2003 Thomas Habets [EMAIL PROTECTED]” You could ask upstream to add license headers to *.h, and probably to update the copyright years in arping-2/arping.c at least. And while we're at it, the FSF address is outdated. (licensecheck -r . is your friend, by the way.) Done. Ah, and you may also want to specify a license for the Debian packaging. Usually, “The Debian packaging is licensed under the same terms and is: © $years $you” is seen. Done. - During the build, I've noticed the -I targeting /usr/local. I guess it could possibly break the build under some circumstances (when having incompatible versions of the libraries under /usr/local), so you may want to strip those locations from the -I/-L flags. I removed use of local/ in CFLAGS2 I think that's all for now. :) Mraw, KiBi. Giuseppe. signature.asc Description: OpenPGP digital signature
Re: RFS: gtkwhiteboard (now dfsg compatible)
On Sunday 22 June 2008, Thomas Knott wrote: Am Sonntag, 15. Juni 2008 19:32:50 schrieb George Danchev: Hi, Hi! Thanks for your suggestions. Hi, I am looking for a sponsor for my package gtkwhiteboard. It was uploaded before by José L. Redrejo Rodríguez [EMAIL PROTECTED] but got rejected because the upstream source contains a win32-dll without source. I stripped the dll now, added a README.debian-source and a (probably bad) get-orig-source.sh to create the dfsg-tarball from the upstream zip-file. Providing a watch file would be nice, as well as a machine-interpretable debian/copyright: see http://wiki.debian.org/Proposals/CopyrightFormat Added a watch file and changed the copyright file to the new format. Sure, these look good to me. Just a minor note about your rules:get-orig-source you might find useful. No need to call chmod on get-orig-source.sh to make it executable and then worry to chmod it back to a non-executable in your clean target (which you actually forgot to;-). Just a call like sh get-orig-source.sh would do the job. Also, you might want to delete the zip file within debian/ and put the dfsg tarball outside debian/, e.g.: rm -f WiimoteLib.dll gtkwhiteboard-1.3.zip tar -czf ../gtkwhiteboard_1.3+dfsg.orig.tar.gz * --exclude=\.dll I tried to implement your suggestions. It seems to work but I am not good at scripting stuff. there are some minor issues typos (baord vs. board), but the following should work better (btw, I also hate scripting and love ada;-). #!/bin/bash set -e VER=1.3 # change that whenever a newer version occurs NAME=gtkwhiteboard UPSTREAM=$NAME-$VER DEBIANED=$NAME\_$VER LOCATION=http://fuelnatchos.webng.com/gtkwhiteboard #Create temporary directory mkdir ./$UPSTREAM cd ./$UPSTREAM #Get upstream source wget $LOCATION/$UPSTREAM.zip unzip ./$UPSTREAM.zip #Remove downloaded zip, binary-only file and win32-icon rm -f $UPSTREAM.zip WiimoteLib.dll gtkwhiteboard.ico #Repack cd .. tar -czf $DEBIANED+dfsg.orig.tar.gz $UPSTREAM --exclude=\.dll #Move orig.tar.gz outside /debian mv $DEBIANED+dfsg.orig.tar.gz ../ #Clean up rm -rf ./$UPSTREAM -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[OT] : gpg fingerprint in mail's signature ? - Was: Re: RFS: gtkwhiteboard (now dfsg compatible)
Totally off-topic, sorry. Le dimanche 22 juin 2008 à 18:21 +0300, George Danchev a écrit : -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB Is there any use in adding your fingerprint to the signature ? ... It seems misleading at least, if users think they can trust that... and without the public key, it's useless anyway. My 2 cents, -- Olivier BERGER [EMAIL PROTECTED] http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC Ingénieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OT] : gpg fingerprint in mail's signature ? - Was: Re: RFS: gtkwhiteboard (now dfsg compatible)
On Sun, Jun 22, 2008 at 05:41:11PM +0200, Olivier Berger wrote:
Is there any use in adding your fingerprint to the signature ? ... It
seems misleading at least, if users think they can trust that... and
without the public key, it's useless anyway.
It's assumed that your public key can be commonly found on public
keyservers or by fingering your address. Putting your key
fingerprint in your .sig is *obviously* not equivalent to
cryptographically signing a particular message, but it does help
others identify that they've looked up the correct key for you if
they want to encrypt a response to you. It's only potentially
misleading if someone doesn't understand PKI in the first place, but
then what's the point of avoiding misleading someone about something
they don't know how to use in the first place? I don't know if the
extra 40 characters make my .sig obscenely larger, but if they did I
might shorten it to a key ID instead.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Fwknop and the install process
Hi, I have posted this message on debian-devel, but there is still no answer. So I give it a try on debian mentors in the hope I can get more audience :p! To make it short first, I would say I do not know how to handle the install process of the fwknop server (fwknopd) and I am looking for some suggestions. Here is a link to the fwknop description : http://www.cipherdyne.org/fwknop/index.html The context : Fwknop has a daemon : fwknopd, and it depends on configuration files, and cannot be started without updating them. The user can choose two setups : - the simple one : three variables to change (the ethernet interface, a key, and the machine hostname) - the second one requires much more work, since he has to deal with gpg key (create, sign, export) on both the client and the server sides, in addition to the ethernet interface, the key and the machine hostname. These settings are recommended. So, right now, I would choose to work this way : - not ask for any questions and not start fwknopd during the install process ; a variable would be set to no in /etc/default/fwknop-server. - let the user have a quick setup (the three simple questions), and start the fwknopd daemon, by use of dpkg-reconfigure. Add a note about the recommended settings. But what about starting the simple setup through the three questions, by default, and mentionning that the user might want to configure gpg and restart. What would you suggest ? Any idea is welcome. Thanks, -- Franck Joncourt http://debian.org - http://smhteam.info/wiki/ Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE signature.asc Description: OpenPGP digital signature
[DONE] Re: RFS: arping (updated package - ITA)
Giuseppe Iuculano [EMAIL PROTECTED] (22/06/2008): Done. […] Done. Further comments and further actions coordinated through IRC, package OK from my point of view, and uploaded. Thanks for your patience. Feel free to ping me directly for any later upload. Mraw, KiBi. signature.asc Description: Digital signature
Re: [OT] : gpg fingerprint in mail's signature ? - Was: Re: RFS: gtkwhiteboard (now dfsg compatible)
On Sunday 22 June 2008, The Fungi wrote: On Sun, Jun 22, 2008 at 05:41:11PM +0200, Olivier Berger wrote: Is there any use in adding your fingerprint to the signature ? ... It seems misleading at least, if users think they can trust that... and without the public key, it's useless anyway. It's assumed that your public key can be commonly found on public keyservers or by fingering your address. Putting your key fingerprint in your .sig is *obviously* not equivalent to cryptographically signing a particular message, but it does help others identify that they've looked up the correct key for you if they want to encrypt a response to you. It's only potentially misleading if someone doesn't understand PKI in the first place, but then what's the point of avoiding misleading someone about something they don't know how to use in the first place? ;-) Well yes, people who are unable to make the difference between a cryptographically signed message and such that merely contains a key fingerprint at the end could not be a factor with regard to the originator identification and verification process, since they don't know what to verify anyway and since it is a well known fact that everybody can write a message with any free-form text appended at the end ;-) I don't know if the extra 40 characters make my .sig obscenely larger, but if they did I might shorten it to a key ID instead. In order to shorten my appendix with one line I decided on key ID only instead, which is enough for public key diggers. -- pub key ID 0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: atmailopen
Hi Giuseppe, On Sun, 2008-06-22 at 13:17 +0200, Giuseppe Iuculano wrote: I am looking for a sponsor for my package atmailopen. * Package name: atmailopen Version : 1.01-1 Upstream Author : @Mail [EMAIL PROTECTED] * URL : http://www.atmail.org/ * License : Apache License Version 2.0 Section : web Just a quick checking: - You duplicate php-date, php-mail, php-net-smtp, php-net-ldap and php-net-socket packages inside your pacakge. This is a security nightmare. Can't you just depend on those packages? - Your depends line list sqlite, but why not sqlite3? php5-sqlite support both. - debian/rules contains some cp commands in the binary-indep target, maybe dh_install can handle them. - Why don't you remove empty dirs instead of making lintian override them? - debian/compat says debhelper level 5, but you build depend on debhelper (= 6) which is well, fine; just inconsistent. - Your diff.gz contains patch-stamp, what for? Regards, Laszlo/GCS signature.asc Description: This is a digitally signed message part
Re: Which 64 bit cpu assembler to use ?
Star Liu wrote:
Greetings!
I'm a newbie in assembly language programming, for I worked as a C#
programmer on microsoft platform in the past years, but now I want to
know clearly how operating system and softwares are executed, so I begin
to learn assembly language programming, I have learned some 32 bit asm
coding, and want to move to 64 bit coding. Is there any good toturial to
follow? and which assembler should I use?
I suggest avoiding coding in assembler. In 2008, this has no sense. If
you really need some strange machine instruction, use the asm statement
inside a GCC-compiled code.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OT] : gpg fingerprint in mail's signature ? - Was: Re: RFS: gtkwhiteboard (now dfsg compatible)
George Danchev [EMAIL PROTECTED] (22/06/2008): In order to shorten my appendix with one line I decided on key ID only instead, which is enough for public key diggers. Even shorter: Sign your mails. Mraw, KiBi. signature.asc Description: Digital signature
Re: [DONE] Re: RFS: arping (updated package - ITA)
Cyril Brulebois ha scritto: Further comments and further actions coordinated through IRC, package OK from my point of view, and uploaded. Thanks for your patience. Feel free to ping me directly for any later upload. Thanks! Giuseppe. signature.asc Description: OpenPGP digital signature
Re: [OT] : gpg fingerprint in mail's signature ? - Was: Re: RFS: gtkwhiteboard (now dfsg compatible)
On Sun, Jun 22, 2008 at 11:59:53PM +0200, Cyril Brulebois wrote:
Even shorter: Sign your mails.
While I won't debate the relative merits, it's definitely not
shorter. According to wc -c your attached PGP signature is 197
characters long.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OT] : gpg fingerprint in mail's signature ? - Was: Re: RFS: gtkwhiteboard (now dfsg compatible)
On Monday 23 June 2008, Cyril Brulebois wrote: George Danchev [EMAIL PROTECTED] (22/06/2008): In order to shorten my appendix with one line I decided on key ID only instead, which is enough for public key diggers. Even shorter: Sign your mails. Bleh 3 words 3 failures ;-) is it really so hard to realize that these hints are for people who don't have my public key at hand and want to dig it up somehow. I also disagree that signed mails are shorter, and you would probably that I don't have my secret key at hand any time I post to mailing lists. Can we move on please ... -- pub key ID 0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: atmailopen
Hi Laszlo,
Laszlo Boszormenyi ha scritto:
Just a quick checking:
- You duplicate php-date, php-mail, php-net-smtp, php-net-ldap and
php-net-socket packages inside your pacakge. This is a security
nightmare. Can't you just depend on those packages?
First I tried tu use debian pear linking /usr/share/php to
/usr/share/atmailopen/libs/PEAR, but
unfortunately atmail doesn't work, just a white page...
- Your depends line list sqlite, but why not sqlite3? php5-sqlite
support both.
Done
- debian/rules contains some cp commands in the binary-indep target,
maybe dh_install can handle them.
dh_install cannot rename files or directories, it can only install them with
the names they already
have into wherever you want in the package build tree.
So for example install/atmail.mysql will be installed as
usr/share/dbconfig-common/data/atmailopen/install/atmail.mysql, and not as
usr/share/dbconfig-common/data/atmailopen/install/mysql .
Is there a workaround?
- Why don't you remove empty dirs instead of making lintian override
them?
I think empty dir could be used, in the code I read for example:
$user['MailDir'] = {$pref['user_dir']}/users/$first/$second/$this-Account
- debian/compat says debhelper level 5, but you build depend on
debhelper (= 6) which is well, fine; just inconsistent.
Fixed, debhelper (= 5)
- Your diff.gz contains patch-stamp, what for?
Fixed.
Giuseppe.
signature.asc
Description: OpenPGP digital signature
Re: RFS: atmailopen
On Mon, 23 Jun 2008, Giuseppe Iuculano wrote: First I tried tu use debian pear linking /usr/share/php to /usr/share/atmailopen/libs/PEAR, but unfortunately atmail doesn't work, just a white page... Usually the PHP error log can show the problems here; perhaps you can turn up the debug level to get more output. I also like to turn on PHP's display_errors in php.ini. -- Asheesh. -- Protozoa are small, and bacteria are small, but viruses are smaller than the both put together. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: atmailopen
Giuseppe Iuculano ha scritto: First I tried tu use debian pear linking /usr/share/php to /usr/share/atmailopen/libs/PEAR, but unfortunately atmail doesn't work, just a white page... Ok, fix the issue, now atmailopen uses PEAR in /usr/share/php and depends also on php-date, php-mail, php-net-smtp, php-net-ldap, php-net-socket, php-mail-mime Giuseppe. signature.asc Description: PGP signature signature.asc Description: OpenPGP digital signature
Updating a package; ediquette and procedure questions
Hi, again. I'm the guy who builds RPMs trying to understand the Debian way. Still. In Ubuntu Hardy, the version of ggobi is not the most recent release. It is about 1 year out of date. Since I've been supplying RPM for ggobi for a couple of years, i thought it would be instructive to see if I could take the newer source code package and apply the existing Debian diff and dsc files to make a package. The new package from the ggobi team is: ggobi-2.1.7.tar.bz2 The Debian packaging process still seems awkward to me, but I think I'm starting to make it work. Here's how I went about it. 1. Get sources for ggobi-2.1.6 from Ubuntu site $ apt-get source ggobi I want that because I need to see how the previous package was built. I need to find out if there are patched under the debian directory that need to be eliminated or adjusted. 2. Change name of new package, open it up $ cp ggobi-2.1.7.tar.bz2 ggobi_2.1.7.orig.tar.bz2 $ tar xjvf ggobi_2.1.7.orig.tar.bz2 3. Go into the new source tree, manually copy over the debian directory from the previous version: $ cd ggobi-2.1.7 $ cp -R ../ggobi-2.1.6/debian . 4. Edit the debian/changelog to set the version number and put in my name so the gpg key signing process will succeed. I had not realized the package builder was detecting the version of the deb package from the changelog. Surprise! 5. Build the package $ debuild -r fakeroot That ends with a lot of warnings about the source code not being found, because it is looking for ggobi_2.1.7.orig.tar.gz, but i have the bz2 file instead. In the end, I could find no way to make that go away except for re-packaging the source code from a bz2 file to gz. After that I'm able to build both the deb package and the source pieces. Here are my questions, in no particular order. 1. Is this roughly how you would go about building a package for a new source tarball? 2. In Ubuntu, or Debian more generally, what happens when package maintainers don't stay up to date? It is a little tough to figure out who is responsible for a package sometimes, there is an OriginalMaintainer and other names in the changelog. If you email the person you think is in charge, and don't get an answer, what do you do? This reminds me, I noticed today that in Ubuntu, the supplied version of R is 2.6.2, but I need 2.7, the current version. Same problem as with ggobi, except I really need the Ubuntu team to update theirs, because there are subsidiary programs like ggobi that are going to look for the new R, as opposed to old R. And some R components cannot be built with the old version of R, such as the current package cairoDevice. 3. What do you do with code distributed in bz2 files? I searched pretty hard for some guidance from Mr. Google, got none, except for people agreeing that debian packaging should have a way to deal with bzip files more seamlessly. The bz2 compression is much better, the filesize is 2.5 megabytes, compared against 3.4 meg. 4. Suppose I succeed in building some packages and want to post them on a website. In RPM world, there was a simple program createrepo that would crawl over a directory structure and do all the work needed to index files and make them available to programs like yum. In Ubuntu, I'm looking for a similarly easy approach to creating a repository, but most of the tipsheets I find are designed for people who want to build a mirror repository of all distribution packages. Can you throw me a pointer? PJ -- Paul E. Johnson Professor, Political Science 1541 Lilac Lane, Room 504 University of Kansas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: Nana (updated package)
On Fri, Jun 20 2008, Vincent Bernat wrote: Seems fine to me. I have uploaded it. Thanks! Thanks very much for the upload! -- KBK -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Which 64 bit cpu assembler to use ?
Basile STARYNKEVITCH wrote: Star Liu wrote: Greetings! I'm a newbie in assembly language programming, for I worked as a C# programmer on microsoft platform in the past years, but now I want to know clearly how operating system and softwares are executed, so I begin to learn assembly language programming, I have learned some 32 bit asm coding, and want to move to 64 bit coding. Is there any good toturial to follow? and which assembler should I use? I suggest avoiding coding in assembler. In 2008, this has no sense. If you really need some strange machine instruction, use the asm statement inside a GCC-compiled code. After all, long ago we learned that 640K was enough memory for all our needs ;-) Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Updating a package; ediquette and procedure questions
Paul Johnson [EMAIL PROTECTED] writes: The Debian packaging process still seems awkward to me, but I think I'm starting to make it work. Congratulations on your persistence, and thank you for your efforts to understand the needs of those who package your software. I had not realized the package builder was detecting the version of the deb package from the changelog. Surprise! A pleasant surprise, I hope. (I see it as an excellent application of the Don't Repeat Yourself principle.) 1. Is this roughly how you would go about building a package for a new source tarball? I'd usually maintain an ongoing upstream source branch in the VCS, and merge the changes from a new version into that. Not try to build directly from the upstream source. Then, use the appropriate 'foovcs-buildpackage' tool (where 'foovcs' is the VCS in question) to automatically export and copy files to the appropraite places to generate Debian source and binary packages. 2. In Ubuntu, or Debian more generally, what happens when package maintainers don't stay up to date? Someone files a bug report against the package. Setting the bug report severity to wishlist and summary of New upstream version available are customary, but not immutable. That bug report is then the contact point for any discussion about packaging that new upstream version, regardless of whether the official package maintainer is responsive. It is a little tough to figure out who is responsible for a package sometimes, there is an OriginalMaintainer and other names in the changelog. The Debian source package format includes a mandatory control file with fields describing the package; look for foo_1.2-3.dsc. One of the mandatory fields in that file is 'Maintainer', giving the contact details for the maintainer of the Debian package. If you email the person you think is in charge, and don't get an answer, what do you do? Be patient, if possible. File the New upstream version available bug report yourself, definitely. If it's more urgent that a new version should be packaged (e.g. a security vulnerability), you could agitate for some other Debian developer to address the bug report, with a Non-Maintainer Upload of a new revision of the package. 3. What do you do with code distributed in bz2 files? Complain about the fact that the currently-supported Debian source package format doesn't allow them. Then, repackage them as gzip tarballs. There is a new source package format specification in the pipeline that does allow (among many new features) upstream source tarballs in bzip2 format, but cannot be recommended until the entire toolchain and infrastructure supports that specification. -- \ “Holy astringent plum-like fruit, Batman!” —Robin | `\ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Updating a package; ediquette and procedure questions
Le Sun, Jun 22, 2008 at 07:16:52PM -0500, Paul Johnson a écrit : Hi, again. I'm the guy who builds RPMs trying to understand the Debian way. Still. Hi again, $ cp ggobi-2.1.7.tar.bz2 ggobi_2.1.7.orig.tar.bz2 Debian provides many facilities in the `devscripts' package. One of them is the uscan/uupdate programs. They need a special file in the source package, `debian/watch', that is unfortunately not available for ggobi. Luckily, it is easy to write: cat debian/watch version=3 http://www.ggobi.org/downloads/ggobi-(.+)\.tar\.bz2 now if you type `uscan': ggobi: Newer version (2.1.7) available on remote site: http://www.ggobi.org/downloads/ggobi-2.1.7.tar.bz2 (local version is 2.1.6) ggobi: Successfully downloaded updated package ggobi-2.1.7.tar.bz2 and symlinked ggobi_2.1.7.orig.tar.bz2 to it 3. Go into the new source tree, manually copy over the debian directory from the previous version: And then, uupdate ../ggobi_2.1.7.orig.tar.bz2 New Release will be 2.1.7-1. -- Untarring the new sourcecode archive ../ggobi_2.1.7.orig.tar.bz2 Success! The diffs from version 2.1.6-2 worked fine. Remember: Your current directory is the OLD sourcearchive! Do a cd ../ggobi-2.1.7 to see the new package $ debuild -r fakeroot Latest versions use fakeroot automagically if available. That ends with a lot of warnings about the source code not being found, because it is looking for ggobi_2.1.7.orig.tar.gz, but i have the bz2 file instead. Maybe you do non have the latest version of our toolchain (dpkg-dev, ...)? Using bz2 works except that these packages are not yet accepted by our archive management system. In the end, I could find no way to make that go away except for re-packaging the source code from a bz2 file to gz. After that I'm able to build both the deb package and the source pieces. Here are my questions, in no particular order. 2. In Ubuntu, or Debian more generally, what happens when package maintainers don't stay up to date? It is a little tough to figure out who is responsible for a package sometimes, there is an OriginalMaintainer and other names in the changelog. If you email the person you think is in charge, and don't get an answer, what do you do? In Debian, the responsible persons are listed in the Uploaders and Maintainers field. Websites such as packages.debian.org display this information. Request for packaging a new upstream release can be adressed by mail or by bug, and if there is not answer within a month, one can enquire wether the package is unmaintained or not. If unmaintained, it will be adopted, orphaned or removed). This reminds me, I noticed today that in Ubuntu, the supplied version of R is 2.6.2, but I need 2.7, the current version. For Ubuntu, you have to contact Masters Of The Universe (MOTUs). They decide wether imorting the latest Debian package is appropriate given their release strategy. 3. What do you do with code distributed in bz2 files? For the moment we bunzip2 and gzip them :( 4. Suppose I succeed in building some packages and want to post them on a website. http://www.debian.org/doc/manuals/repository-howto/repository-howto.en.html ? Have a nice day, and thanks for your interest in Debian. PS: You may save some time by reading things in the followign section of our website: http://www.debian.org/doc In particular http://www.debian.org/doc/manuals/maint-guide/ PPS: for more complex packages, it is not always that easy. -- Charles Plessy Debian-Med packaging team Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: gnu-standards (updated package. no longer non-free)
Dear mentors, I am looking for a sponsor for the new version 2008.06.10-1 of my package gnu-standards. This contains the GNU Coding Standards, as well as 'Information For Maintainers of GNU Software', two useful documents even if you are not a GNU maintainer. I suggested to upstream a few months ago that they could relicense the latter under the GFDL (without invariant sections), and the Debian package can now be moved from non-free into main. I also added doc-base registration files, so this upload should fix all known bugs for the package. It builds these binary packages: gnu-standards - GNU coding and package maintenance standards The package appears to be lintian clean. The upload would fix these bugs: 283295, 357675, 434638, 451650, 462871, 487136 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gnu-standards - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gnu-standards/gnu-standards_2008.06.10-1.dsc I would be glad if someone uploaded this package for me. Kind regards, -- Tim Retout [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Which 64 bit cpu assembler to use ?
On Sunday 22 June 2008 03:08:08 am Basile STARYNKEVITCH wrote:
Star Liu wrote:
Greetings!
I'm a newbie in assembly language programming, for I worked as a C#
programmer on microsoft platform in the past years, but now I want to
know clearly how operating system and softwares are executed, so I
begin to learn assembly language programming, I have learned some 32
bit asm coding, and want to move to 64 bit coding. Is there any good
toturial to follow? and which assembler should I use?
I suggest avoiding coding in assembler. In 2008, this has no sense. If
you really need some strange machine instruction, use the asm statement
inside a GCC-compiled code.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
If you want to write an operating system, *some* assembly is absolutely
required -- getting the A20 gate open, getting into protected mode, and so
forth. Yes, you can use GCC's inline assembly to do that (and, indeed,
that's probably better). Logically, however, before you can use inline
assembly, you must know how to use assembly at all.
I agree that using assembly in any situation except the most extreme or
unusual is generally not a good idea. However, that is no reason not to
learn it. You can learn from it, at least, how the machine works -- so when
your C code does something you didn't expect, you can understand it a
little easier.
I'm not an expert, just a hobbyist. Don't take my word for it ;).
- Jack Mudge
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gnu-standards (updated package. no longer non-free)
Tim Retout [EMAIL PROTECTED] (23/06/2008):
This contains the GNU Coding Standards, as well as 'Information For
Maintainers of GNU Software', two useful documents even if you are not
a GNU maintainer. I suggested to upstream a few months ago that they
could relicense the latter under the GFDL (without invariant
sections), and the Debian package can now be moved from non-free into
main.
Nice!
I also added doc-base registration files, so this upload should fix
all known bugs for the package.
Looks like.
I would be glad if someone uploaded this package for me.
Before that, I'd like you to address the following points:
- Maybe the Homepage could move from https:// to http://?
- What about making doc-base files less “personal”? You don't really
need to point fingers at the reader and keep using “you” every
sentence. :) Not a high priority thing, but that'd be nice if it were
considered as some point.
- You surely don't need debian/dirs.
- Nor an empty debian/docs, but see below.
- Why are you setting SHELL=/bin/bash instead of just not using
bashisms? You could e.g. put the whole file list in debian/docs
instead of using (double) {} constructs in the dh_installdocs call.
- You could get rid of commented calls in debian/rules as well.
- Your configure/configure-stamp targets aren't doing anything, why not
deleting them completly?
- You could finish the “refresh:” target with an “exit 1” so that you
easily spot that it's getting called (by mistake) during a real
build, because buildds aren't supposed to have net access during the
build.
- Did you notice the following? (from lintian)
E: gnu-standards: doc-base-file-references-missing-file
gnu-maintainers-information:24 /usr/share/info/maintain.info.gz
E: gnu-standards: doc-base-file-references-missing-file
gnu-maintainers-information:25 /usr/share/info/maintain.info.gz
E: gnu-standards: doc-base-file-references-missing-file
gnu-coding-standards:24 /usr/share/info/standards.info.gz
E: gnu-standards: doc-base-file-references-missing-file
gnu-coding-standards:25 /usr/share/info/standards.info.gz
After the build, I got: [EMAIL PROTECTED]:/tmp/gnu-standards$ find -name
'*.info'
./standards.info
./maintain.info
- I had a very quick look at your git history, you may want to use “dch
-t” when modifying the history, so as to get rid of the (IMHO) noisy
trailer line change on every commit. That makes interactive rebase a
bit easier, as well as cherry-picking (although I'm not sure you will
ever need it on this particular package). Of course, if the timestamp
update is intended, feel free to keep doing so, that's just a mere
suggestion. (I'm BTW not using dch -t, but rather dch -a, or manual
modifications to debian/changelog, and only modifying the timestamp,
through dch -r, right before the upload.)
- You're welcome to target “unstable” if your next upload to mentors
addresses the above points.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Re: RFS: nvi [DONE] (Was Re: Multi-RFS: nvi, autofs5, mt-st)
Hello, On Thu, 12 Jun 2008, Jan Christoph Nordholz wrote: * nvi (1.79-26 = 1.81.6+debian-1) Switch from the stable branch (which has been dead for ages) to the development branch - it doesn't feel developmental though. Package has been thoroughly revised (the 1.79 series didn't even employ a patch system) at that opportunity. On Sun, 22 Jun 2008, Jan Christoph Nordholz wrote: [1]: http://www-pool.math.tu-berlin.de/~hesso/deb/nvi_1.81.6-2.dsc (again built with -sa -v1.79-26) Uploaded the most recent revision. Thanks for your work on Debian. Kapil. -- signature.asc Description: Digital signature
