Architecture Nomenclature
Greetings Everyone, I've been looking for a while, but no luck. Is there a table somewhere that summarizes the different architecture names like i386, i586, i686, amd64, ia64, and so on along with the criteria for hardware qualifying under that name? e.g. Does i686 mandate SSE2? PS I am not on the mailing list, so please remember to cc me. Thanks. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com signature.asc Description: This is a digitally signed message part
Re: Architecture Nomenclature
On Tue, 2010-04-27 at 22:16 +0200, Benjamin Drung wrote: > Am Dienstag, den 27.04.2010, 12:45 -0700 schrieb Kip Warner: > > Greetings Everyone, > > > > I've been looking for a while, but no luck. Is there a table somewhere > > that summarizes the different architecture names like i386, i586, i686, > > amd64, ia64, and so on along with the criteria for hardware qualifying > > under that name? > > I am not aware of a table. I would search for the names and see which is > the first architecture and check their features. > > > e.g. Does i686 mandate SSE2? > > i686 = Pentium Pro and later = only MMX > amd64 mandates SSE2 (and therefore MMX and SSE) > > > PS I am not on the mailing list, so please remember to cc me. Thanks. What would you suggest for a package's architecture for a 32-bit platform that supports SSE2, like the Pentium 4? -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com signature.asc Description: This is a digitally signed message part
Re: Architecture Nomenclature
On Tue, 2010-04-27 at 21:29 +, brian m. carlson wrote: > As far as uname, not all machines that output i686 will support SSE2. > Your assumption should be that i686 == Pentium Pro, with the caveat > that > not all i686 machines support cmov (some Via chips do not). Thanks. If I was writing something for a 32-bit machine with SSE2 instruction set, what would be the most appropriate architecture name? -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com signature.asc Description: This is a digitally signed message part
Re: Architecture Nomenclature
On Tue, 2010-04-27 at 21:43 +0100, Ben Hutchings wrote: > It must be 'i386'. But i386 includes machines like the 486 and the Pentium Pro that did not have SSE2 instruction set. If I was writing something for a 32-bit machine with SSE2 instruction set, what would be the most appropriate architecture name? -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com signature.asc Description: This is a digitally signed message part
Re: Architecture Nomenclature
On Wed, 2010-04-28 at 00:32 +0200, Benjamin Drung wrote: > > The best solution would be autodetection of SSE2 on runtime. That can > be > done with a few lines of code. You're right, that can indeed be done with a few lines of code. e.g. cpuid instruction. The problem is that you then have to perform a branch every time you could potentially use hardware acceleration: a condition for when, say, SSE2 is available, and another for a generic implementation. It isn't ideal performance wise. Perhaps for 32-bit x86 architectures where SIMD is required, I could build the package for i686 and have it detect at runtime before said is actually used, whether it is available or not. If it is not, raise a user visible error and terminate. This method assumes the user knows that it is only supported on P4 or later generation of x86. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com signature.asc Description: This is a digitally signed message part
Re: Architecture Nomenclature
On Wed, 2010-04-28 at 12:13 +0200, Josselin Mouette wrote: > The simplest solution is to put the routines in a shared library and > to > build two versions of the library. Put the i486 one in /usr/lib and > the > SSE2 one in /usr/lib/i686/sse2. That might be the way to go. Thanks. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com signature.asc Description: This is a digitally signed message part
Re: Roll call for porters of architectures in sid and testing
On Sun, 2013-09-01 at 20:18 -0400, Adam Holland wrote: > Hi, sorry I'm not a skilled programmer, I just have a historic SGI O2 to > play around with a bit. If the hardware dies, I won't really have any > reaspn to stay involved with this port. Still cool that you have one though! -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com signature.asc Description: This is a digitally signed message part
Testing init.d script
Hey list, I wasn't sure which other Debian mailing list might be more appropriate, but lsb-discuss appeared to be defunct since 2002. My package has an LSB friendly init.d script it distributes to manage the daemon it ships as a system service. I'd like to use it during unit testing so the daemon can be started, stopped, and various unit tests performed on it between starting and stopping. What is the best practice for this kind of scenario? There are some caveats, of course, because the init.d script cannot be run as root when my project's build environment runs its unit tests. Yours truly, -- Kip Warner | Senior Software Engineer OpenPGP signed/encrypted mail preferred https://www.thevertigo.com signature.asc Description: This is a digitally signed message part
Re: Testing init.d script
On Wed, 2018-12-26 at 12:09 +, Colin Watson wrote: > Unit tests can normally use some kind of temporary test harness > instead of the full-blown init script, and that's usually the best > first line of defence since it's typically simpler and faster. > > Of course it's also worth testing the init script itself, or other > behaviours of the package when it's in its installed state rather > than just running out of the build tree. For that purpose, have you > considered autopkgtest (https://ci.debian.net/doc/)? A test with the > "needs-root" restriction can start and stop services. Hey Colin. Thanks for the feedback. I think autopkgtest(1) is a good route to go if I wanted to test it after the package had been generated and installed. But this is really the kind of test I'd like to perform before all of that while still within the build tree. -- Kip Warner | Senior Software Engineer OpenPGP signed/encrypted mail preferred https://www.thevertigo.com signature.asc Description: This is a digitally signed message part
Packaging examples
Hey list, I would like to ship some example files with my package. My Makefile.am has something to the effect of... examplesdir=$(docdir)/examples examples_DATA = \ $(srcdir)/Data/Examples/some_example_file \ ... EXTRA_DIST = \ $(examples_DATA) \ ... This installs the example files as expected in /usr/share/doc/foo/examples/, but I was still left to wonder what the best practise was given that dh_installexamples(1) exists and seems to want to do the same based on the contents of debian/foo.examples? -- Kip Warner | Senior Software Engineer OpenPGP signed/encrypted mail preferred https://www.cartesiantheatre.com signature.asc Description: This is a digitally signed message part
Re: Packaging examples
On Mon, 2018-02-26 at 00:04 +, Craig Small wrote: > Not all upstream Makefiles are that good. My preference would be if > their Makefile is doing the right thing then use that and have no > debian/foo.examples file. Ah, that makes sense. Since the debianization is suppose to happen without having to change upstream's tarball (notwithstanding quilt patches), .examples would be the only way for debhelper to know what upstream intended to be example files. > The main thing is that the example files get put in the right spot > and it's clear to someone how those files arrive there. > > The only other catch is to ensure the install-examples or whatever > the Makefile target is called is actually run; either directly out of > debian/rules or as part of the Makefile install target. Mine is definitely called. The install target is placing everything as expected in $prefix/share/doc/mypackage/examples. If you have any suggestions, I'm all ears: https://github.com/cartesiantheatre/narayan-designer/blob/master/Makefile.am -- Kip Warner | Senior Software Engineer OpenPGP signed/encrypted mail preferred https://www.cartesiantheatre.com signature.asc Description: This is a digitally signed message part
Bug#820490: ITP: streflop -- STandalone REproducible FLOating-Point library
Package: wnpp Severity: wishlist Owner: Kip Warner * Package name: streflop Version : 0.3 Upstream Author : Nicolas Brodu * URL : http://nicolas.brodu.net/en/programmation/streflop/ * License : LGPL-2.1 Programming Lang: C++ Description : ITP: streflop -- STandalone REproducible FLOating-Point library A computer has a finite memory, and cannot represent an infinity of numbers. If you add 0.1 + 0.1 in C++ you will probably not get the mathematical result 0.2. The problem is that what you get depends on many parameters. On one configuration, you may get something like 0.1995, and on another 0.1999. For the vast majority of programs, these small differences do not matter. But if you want to reproduce the same results twice, for a scientific experiment for example, on different machines or even on the same machine but with different options, then you have to be more careful. Much more careful, because these small differences can occasionally accumulate quite fast. The STandalone REproducible FLOating-Point library allows you to control how the computations are done in C++. The goal is to make your programs give reliable and reproducible results.
