Re: Notice with dbconfig-common

[sean finney]

Hi Nicolas,

On Sun, Nov 20, 2011 at 10:59:22PM +0100, Nicolas wrote:
>> The message is :  NOTICE: CREATE TABLE / PRIMARY KEY will create an
> implicit index ...
> 
> I understand the message but I don't know how to fix it. For postgreSQL
> point of view it doesn't seems to be a problem and tables are created.
> 
> Thanks in advance for any help.

I suggest you take this to the dbconfig-common-devel list on alioth.

It could be a bug in dbconfig-common, or in the packaging.  So I suggest
when you take it to the list, you include a link to the source pacakge,
as well as console output during installation, after you export dbc_debug=1.


sean


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2022091244.ga29...@cobija.connexer.com

Piklab

[Richard]

Hi
Can piklab be added to the distro, its stable and runs Ok on wheesy/sid.
The is no alternative except for trying to run MPLAB ina VC and windows.
Its a shame to see such a good package disappear.
TIA
-- 
Best wishes / 73
Richard Bown

e-mail: rich...@g8jvm.com   or   richard.b...@blueyonder.co.uk

nil carborundum a illegitemis
##
Ham Call G8JVM . OS Debian Wheezy/Sid amd64 on a Dual core AMD Athlon 5200, 4 
GB RAM
Maidenhead QRA: IO82SP38, LAT. 52 39.720' N LONG. 2 28.171 W ( degs mins )
QRV HF + VHF Microwave 23 cms:140W,13 cms:100W,6 cms:10W & 3 cms:5W
##
 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2022103119.3961b...@g8jvm.com

Re: Increasing minimum 'i386' processor

[Adam Borowski]

On Tue, Nov 22, 2011 at 06:41:47AM +0100, Stephen Kitt wrote:
> On Sun, 20 Nov 2011 23:31:43 +, Ben Hutchings  
> wrote:
> > 1. Find all ELF executable/library files.
> > 2. Either:
> >a. Work out which instructions should be excluded, depending on the
> >   directory.
> >b. Skip files in hwcap directories and exclude all instructions 
> >   missing from the minimum processor.
> > 3. 'objdump -d | grep' with appropriate instruction regexp; fail if
> >there's a match.
> 
> http://dev.gentoo.org/~dirtyepic/bin/analyze-x86 is very handy for this,
> although it's quite CPU-intensive.

OMGWTFBBQ...

real5m26.459s
user5m25.780s
sys 0m0.108s

How does one write Perl code that slow?  This just has to be intentional --
they used an elaborate construct when a single hash lookup per line of
disassembly is the obvious way.

A quick and dirty change reduces execution time to 5.981s (5.975s of that is
objdump -d).

I also fail to see how the vendor of CPU you happen to be running the script
on would matter -- there might be multiple "minimal" outputs but since the
trade name ("Pentium 4" as opposed to "sse2") is meant for humans only
anyway, there's no reason to be misleading.


Not releasing a fixed version (too ugly to live), but if someone wants it,
please say so, I can polish it for public consumption.

-- 
1KB // Yo momma uses IPv4!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2022112458.ga20...@angband.pl

Re: Piklab

[Salvo Tomaselli]

Il 22.11.2011 12:31 Richard ha scritto:

Hi
Can piklab be added to the distro, its stable and runs Ok on 
wheesy/sid.
The is no alternative except for trying to run MPLAB ina VC and 
windows.

Its a shame to see such a good package disappear.
TIA


Perhaps you could consider maintaining it?

--
Salvo Tomaselli


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/27065ec1c5e81249d146c2cd07a7f...@galileo.dmi.unict.it

Re: Piklab

[Jonathan Nieder]

Salvo Tomaselli wrote:

> Perhaps you could consider maintaining it?

Unless you're suggesting that Richard maintain KDE3, too, that doesn't
seem like very practical advice.

Following the links from , I see
that piklab was removed because it unfortunately has no KDE4 port.  So
if you would like to see it back in Debian, a good strategy might be
to port it to KDE4[1] and then file a request for package[2].

Sincerely,
Jonathan

[1] 
http://techbase.kde.org/index.php?title=Development/Tutorials/KDE4_Porting_Guide
[2] http://www.debian.org/devel/wnpp/#l1


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2022115120.ga10...@elie.hsd1.il.comcast.net

Re: Piklab

[Jonathan Nieder]

Salvo Tomaselli wrote:
> Il 22.11.2011 12:31 Richard ha scritto:

>> Can piklab be added to the distro, its stable and runs Ok on wheesy/sid.
[...]
> Perhaps you could consider maintaining it?

My last reply completely missed the point.  According to [1] the
program was already ported to Qt 4.

Sorry for the noise!  Salvo's advice is excellent --- preparing and
maintaining a package using the pointers from [2] would be greatly
appreciated.  (Otherwise, feel free to file a "request for package"
bug and help whoever responds to it in whatever way you can.)

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604320#29
[2] http://www.debian.org/devel/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2022115719.ga10...@elie.hsd1.il.comcast.net

Re: Piklab

[Richard]

On Tue, 22 Nov 2011 05:57:19 -0600
Jonathan Nieder  wrote:

> Salvo Tomaselli wrote:
> > Il 22.11.2011 12:31 Richard ha scritto:
> 
> >> Can piklab be added to the distro, its stable and runs Ok on wheesy/sid.
> [...]
> > Perhaps you could consider maintaining it?
> 
> My last reply completely missed the point.  According to [1] the
> program was already ported to Qt 4.
> 
> Sorry for the noise!  Salvo's advice is excellent --- preparing and
> maintaining a package using the pointers from [2] would be greatly
> appreciated.  (Otherwise, feel free to file a "request for package"
> bug and help whoever responds to it in whatever way you can.)
> 
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604320#29
> [2] http://www.debian.org/devel/

sorry my reply went to Jonathan and not to the list.
according to sid buglist on piklab the maintainer is
"Maintainers for piklab are Miriam Ruiz "
I'm prepared to help keep this app available if that would help..

-- 
Best wishes / 73
Richard Bown

e-mail: rich...@g8jvm.com   or   richard.b...@blueyonder.co.uk

nil carborundum a illegitemis
##
Ham Call G8JVM . OS Debian Wheezy/Sid amd64 on a Dual core AMD Athlon 5200, 4 
GB RAM
Maidenhead QRA: IO82SP38, LAT. 52 39.720' N LONG. 2 28.171 W ( degs mins )
QRV HF + VHF Microwave 23 cms:140W,13 cms:100W,6 cms:10W & 3 cms:5W
##
 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2022125653.34caa...@g8jvm.com

Bug#649589: ITP: cmigemo -- Japanse incremental search tool written in C

[Youhei SASAKI]

Package: wnpp
Owner: Youhei SASAKI 
Severity: wishlist

* Package name: cmigemo
  Version : 20110227
  Upstream Author : MURAOKA Taro (KoRoN) 
* URL or Web page : http://www.kaoriya.net/software/cmigemo
* License : MIT or Original License
  Description : Japanse incremental search tool written in C

Migemo is a tool that supports Japanese incremental search with Romaji.
Originally migemo is written in Ruby (in debian, migemo pacakge). 

C/Migemo provides search tool and library written in C, which provides
incremental search tool and library for many other tools, e.g. Vim, XUL.

---
Youhei SASAKI 
  
GPG fingerprint:
  4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762icqps6.wl%uwab...@gfd-dennou.org

Bug#649599: ITP: tpm-tools -- Management tools for the TPM hardware

[Pierre Chifflier]

Package: wnpp
Severity: wishlist
Owner: Pierre Chifflier 


* Package name: tpm-tools
  Version : 1.3.7
  Upstream Author : Kent Yoder 
* URL : http://trousers.sourceforge.net/
* License : CPL (http://www.opensource.org/licenses/cpl1.0.php)
  Programming Lang: C
  Description : Management tools for the TPM hardware

 tpm-tools is a group of tools to manage and utilize the Trusted Computing
 Group's TPM hardware. TPM hardware can create, store and use RSA keys securely
 (without ever being exposed in memory), verify a platform's software state
 using cryptographic hashes and more.  .
 This package contains tools to allow the platform administrator the ability
 to manage and diagnose the platform's TPM. Additionally, the package contains
 commands to utilize some of the capabilities available in the TPM PKCS#11
 interface implemented in the openCryptoki project.

Note that this is not really a new package: it was part of main, but was
orphaned, and removed due to the lack of maintainer and low popcon [1].
Since I'm now using this tool, and that it is required to make a TPM
work, I'm adopting it.

Pierre

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543927



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2022141809.20149.40359.report...@ks26688.kimsufi.com

Re: Appreciation

[Andreas Tille]

On Mon, Nov 21, 2011 at 04:12:35PM +0100, martin f krafft wrote:
> There are still many old ones that think Ubuntu can do without
> Debian. Community "management" is not about writing webpages that
> are only read by "most of the new people".

I personally liked the Bow-Arrow comparison Mark did in 

   
http://raphaelhertzog.com/2011/11/17/people-behind-debian-mark-shuttleworth-ubuntus-founder/

and repeating old problems usually does not really help specifically if
the are that vague as above.

Kind regards

 Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2022142053.gc31...@an3as.eu

Re: Increasing minimum 'i386' processor

[Jakub Wilk]

* Ben Hutchings , 2011-11-20, 20:48:
Use of CPUID is probably safe in practice since most 486 models do 
implement it, though userland should really read /proc/cpuinfo.  The 
other uses may be conditional on a CPU feature test but may well be 
bugs.


Is format of /proc/cpuinfo documented anywhere?

Does /proc/cpuinfo with the exist on non-Linux architectures? If yes, 
do they use the same format?


Are the any ready-made libraries that can parse this file?

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2022154721.ga3...@jwilk.net

Re: Increasing minimum 'i386' processor

[Ian Jackson]

Ben Hutchings writes ("Increasing minimum 'i386' processor"):
> The 486-class processors that would no longer be supported are:
> 1. All x86 processors with names including '486'

I'm still running the machine below, and it would be irritating to
have to replace it.

Perhaps a better approach would be to suggest that people with shiny
new hardware should be running amd64 kernels with i386 userland, or
even amd64 (with multiarch i386 for proprietary crap that isn't
available for amd64) ?

Ian.

processor   : 0
vendor_id   : CentaurHauls
cpu family  : 6
model   : 7
model name  : VIA Samuel 2
stepping: 3
cpu MHz : 533.401
cache size  : 64 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu de tsc msr cx8 mtrr pge mmx 3dnow
bogomips: 1066.80
clflush size: 32
cache_alignment : 32
address sizes   : 32 bits physical, 32 bits virtual
power management:


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20171.53784.119523.574...@chiark.greenend.org.uk

Re: Is anyone using the Units program in a script?

[Ian Jackson]

John Hasler writes ("Is anyone using the Units program in a script?"):
> Ok, I;m sure someone is.   If you're that someone are you using the
> "--terse" option?  If not how much hassle would it be to have add it?
> Upstream is considering non-backward-compatible changes.

Honestly, this is not a very good way to go about asking this
question.  (Yes, I know of a script that uses "units" and which would
have to be modified.)

Upstream should (a) think hard about whether this is really necessary
(b) ask on info-gnu.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20171.54122.625533.284...@chiark.greenend.org.uk

Re: Increasing minimum 'i386' processor

[Bastian Blank]

On Tue, Nov 22, 2011 at 04:47:20PM +, Ian Jackson wrote:
> Ben Hutchings writes ("Increasing minimum 'i386' processor"):
> > The 486-class processors that would no longer be supported are:
> > 1. All x86 processors with names including '486'
> I'm still running the machine below, and it would be irritating to
> have to replace it.

> vendor_id : CentaurHauls
> model name: VIA Samuel 2

I don't see any 486 in this name.

Bastian

-- 
There's a way out of any cage.
-- Captain Christopher Pike, "The Menagerie" ("The Cage"),
   stardate unknown.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2022172828.ga31...@wavehammer.waldi.eu.org

Re: Is anyone using the Units program in a script?

[John Hasler]

Ian Jackson writes:
> Honestly, this is not a very good way to go about asking this
> question.

How do you suggest that I ask it?

> Yes, I know of a script that uses "units" and which would have to be
> modified.

Then my method of asking worked, didn't it?  I've also heard from
several others.  They gave me some useful details.

> Upstream should (a) think hard about whether this is really necessary
> (b) ask on info-gnu.

I assume that he did both, but I have no control over that.  In any
case, he asked me and so I asked here (and on debian-user).  It's the
best way I could think of to alert those members of the Debian community
who might be impacted by the change.  I have suggested that this
particular change be applied only in the interactive mode.

-- 
John Hasler


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8739dg12nv@thumper.dhh.gt.org

Re: Increasing minimum 'i386' processor

[Vincent Bernat]

OoO Lors de  la soirée naissante du mardi 22  novembre 2011, vers 18:28,
Bastian Blank  disait :

>> > The 486-class processors that would no longer be supported are:
>> > 1. All x86 processors with names including '486'
>> I'm still running the machine below, and it would be irritating to
>> have to replace it.

>> vendor_id: CentaurHauls
>> model name   : VIA Samuel 2

> I don't see any 486 in this name.

This processor  does not run with a  686 kernel and needs  a 486 kernel.
If   I  remember   correctly,   it   is  because   the   lack  of   CMOV
instruction. Therefore, no problem with 586.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Indent to show the logical structure of a program.
- The Elements of Programming Style (Kernighan & Plauger)


pgpVbq7hxHmAb.pgp
Description: PGP signature

Re: Increasing minimum 'i386' processor

[Ben Hutchings]

On Tue, Nov 22, 2011 at 04:47:20PM +, Ian Jackson wrote:
> Ben Hutchings writes ("Increasing minimum 'i386' processor"):
> > The 486-class processors that would no longer be supported are:
> > 1. All x86 processors with names including '486'
> 
> I'm still running the machine below, and it would be irritating to
> have to replace it.

As Bastian says, this does not look like a 486.  The flags include
tsc msr cx8.

> Perhaps a better approach would be to suggest that people with shiny
> new hardware should be running amd64 kernels with i386 userland, or
> even amd64 (with multiarch i386 for proprietary crap that isn't
> available for amd64) ?
[...]

I believe Debian should now treat amd64 as the default architecture
for PCs.  The i386 installer does provide it as an option in expert
mode (though it's not on CD 1) but I'm not sure we're quite at the
point where it should be automatically selected.

In any case this is irrelevant to the question of optimising userland.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2022183646.gr3...@decadent.org.uk

Re: Increasing minimum 'i386' processor

[John D. Hendrickson and Sara Darnell]

CMOV, quick comment.

Many apps don't reliably optimize -O3.  CMOV saves 1 clock + 1 dword.  There far lower branches to 
pick for debian to grow on (unless it's like req. to drive androids or real important).


(note CMOV is not Ben's agenda as far as I have read.  I say nothing there but 
good luck)

CMOV + IDEA: ignore /proc?  Do u debug trap invalid instr. reliably at which run-level?  Use /proc 
or ask torvalds is safe :)  Isn't there already debian utils up that ally?



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ecbf168.7080...@cox.net

Re: Is anyone using the Units program in a script?

[Bob Proulx]

Ian Jackson wrote:
> (b) ask on info-gnu.

Just fyi for the future but info-gnu isn't the place to ask questions.
It is for official GNU announcements only, no follow-ups, no
discussions.  Discussions should happen on other lists.

Bob

-- 
Wearing my info-gnu moderator hat.


signature.asc
Description: Digital signature

Re: Increasing minimum 'i386' processor

[Samuel Thibault]

John D. Hendrickson and Sara Darnell, le Tue 22 Nov 2011 14:00:56 -0500, a 
écrit :
> CMOV saves 1 clock + 1 dword.

Errr, and branch misprediction?

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2022201903.GF4113@type

Re: Increasing minimum 'i386' processor

[John D. Hendrickson and Sara Darnell]

Josselin Mouette is apparently easily amused.

He harasses me every time I use debian-devel mailing list, apparently automaticall (which is illegal 
in my country - though for now it's ok).



Josselin Mouette wrote:
> Or in legacy; I've read about wishes of their own patent problems,
> capice?  But ads a login can get out and having to be opensuse deeply
> compatible yet high unix efficient, Switching to all the road?  Grub and
> having to maintain and inodes would be my slice single project need
> change if MIS USED by I already prepared considering hardware and drive
> in his response; mail, btw i've read most filesystem blocking code for
> demanding offered proof that i've read about the right arch; the tomb of
> each of my guess.
> It's a good day all the origional bug is i'm almost unsure why is good
> new work because they insert many And drive installed correctly after I
> move hack a isn't a ramdisk for the linux; allows a new work because
> they now have Fun!
> Michael Biebl v.  If there's you sure if linux users anything
> they're hoping you'll make new problems they mount boot and
> privatizes gov.  Are you rolling debian on people's comments!
> And mixed partitions is invalidated maybe you want highly
> specialized caching write code.  Tftp boot disk and large disks,
> many drive large WD hardisks both have advice?  That's Funny!
> Thus I might say and complicated bsd my guess; I thinking of
> their own patent problems, ide And disperses what are Have Fun!
> Debian new bugsy, non obstructing, no spin maybe you try want
> highly specialized caching write code for demanding Tmpfs to
> allow processes to hear about wishes of the right arch; eat the
> partition tables headers And considering hardware and what are
> you are?
> But with thought using I hope and large WD hardisks both Have
> fun!  John I might say and ignores justice in his response;
> mail, btw i've read most filesystem Blocking caching code to
> kill any single user logins that i've read about wishes of delay
> of copying todos and not true, called?
> They prosecute you are you rolling debian bugs, I still don't
> share memory share memory why you should just dd, I And
> privatizes gov.  Where's the people who are not always new
> software do it the drives with the need special exception in lk
> series any EZ drive data and tfpt is for special exception in lk
> they are you i might say and risk data one will it.
> Have fun!  Whether is or way.  I was provided it processes to get their
> own patent problems, capice?  Why is blocking code to hack a backup
> directory is disagreeing with Just ignore them.



Josselin Mouette wrote:
I have a request for special exception in Wikipedia! 


Simple well knowns, non obstructing, no spin maybe not
construed to hear about wishes of delay of!  Is safe
promised permanent IPs.  I'm not survivable a bug is it
hard be my Christmas John i already.  It ignore mere talk
about wishes of bsd about the support of any single project
need to fix see like to me these problems capice?  They
promised permanent IPs. 


Or is of any EZ drive installed changing and
tfpt is a major maintenance will care which is
supporting optional no one block by checking
for and booting. 


> I have a request for special exception in Wikipedia!
>
> Simple well knowns, non obstructing, no spin maybe not
> construed to hear about wishes of delay of!  Is safe
> promised permanent IPs.  I'm not survivable a bug is it
> hard be my Christmas John i already.  It ignore mere talk
> about wishes of bsd about the support of any single project
> need to fix see like to me these problems capice?  They
> promised permanent IPs.
>
> Or is of any EZ drive installed changing and
> tfpt is a major maintenance will care which is
> supporting optional no one block by checking
> for and booting.
>


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ecc11c7.6080...@cox.net

Re: Increasing minimum 'i386' processor

[Samuel Thibault]

John D. Hendrickson and Sara Darnell, le Tue 22 Nov 2011 16:19:03 -0500, a 
écrit :
> Josselin Mouette is apparently easily amused.
> 
> He harasses me every time I use debian-devel mailing list, apparently
> automaticall (which is illegal in my country - though for now it's ok).
> 
> 
> Josselin Mouette wrote:
> > Or in legacy; I've read about wishes of their own patent problems,
> > capice?  But ads a login can get out and having to be opensuse deeply
> > compatible yet high unix efficient, Switching to all the road?  Grub and
> > having to maintain and inodes would be my slice single project need
> > change if MIS USED by I already prepared considering hardware and drive
> > in his response; mail, btw i've read most filesystem blocking code for
> > demanding offered proof that i've read about the right arch; the tomb of
> > each of my guess.

This looks random stuff to me. Not something that Josselin would write.
I'd rather bet on a spammer using random "From:".

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2022212438.GG4113@type

Re: Increasing minimum 'i386' processor

[Ben Hutchings]

On Tue, Nov 22, 2011 at 04:47:21PM +0100, Jakub Wilk wrote:
> * Ben Hutchings , 2011-11-20, 20:48:
> >Use of CPUID is probably safe in practice since most 486 models do
> >implement it, though userland should really read /proc/cpuinfo.
> >The other uses may be conditional on a CPU feature test but may
> >well be bugs.
> 
> Is format of /proc/cpuinfo documented anywhere?

Sadly, it is not documented explicitly.

> Does /proc/cpuinfo with the exist on non-Linux architectures? If
> yes, do they use the same format?

It is Linux-specific, but included in FreeBSD's Linux compatibility module.
I don't know whether Debian kFreeBSD loads that by default.

> Are the any ready-made libraries that can parse this file?
 
Not that I know of.

However, if you're looking for specific x86 feature flags (which is
almost certainly what you need) you can use:

bool x86_has_feature(const char *name)
{
FILE *cpuinfo;
char *line = NULL, *p;
size_t line_len = 0, name_len = strlen(name);
bool found = false;

cpuinfo = fopen("/proc/cpuinfo", "r");
if (!cpuinfo)
return false;

while (getline(&line, &line_len, cpuinfo) >= 0 && !found) {
if (strncmp(line, "flags\t", 6))
continue;
p = line;
while ((p = strchr(p, ' ')) != NULL) {
p++;
if (strncmp(p, name, name_len) == 0 &&
isspace((unsigned char)p[name_len])) {
found = true;
break;
}
}
}

fclose(cpuinfo);
return found;
}

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2022213747.gs3...@decadent.org.uk

Re: Increasing minimum 'i386' processor

[Ben Hutchings]

On Tue, Nov 22, 2011 at 10:24:38PM +0100, Samuel Thibault wrote:
> John D. Hendrickson and Sara Darnell, le Tue 22 Nov 2011 16:19:03 -0500, a 
> écrit :
> > Josselin Mouette is apparently easily amused.
> > 
> > He harasses me every time I use debian-devel mailing list, apparently
> > automaticall (which is illegal in my country - though for now it's ok).
> > 
> > 
> > Josselin Mouette wrote:
> > > Or in legacy; I've read about wishes of their own patent problems,
> > > capice?  But ads a login can get out and having to be opensuse deeply
> > > compatible yet high unix efficient, Switching to all the road?  Grub and
> > > having to maintain and inodes would be my slice single project need
> > > change if MIS USED by I already prepared considering hardware and drive
> > > in his response; mail, btw i've read most filesystem blocking code for
> > > demanding offered proof that i've read about the right arch; the tomb of
> > > each of my guess.
> 
> This looks random stuff to me. Not something that Josselin would write.
> I'd rather bet on a spammer using random "From:".
 
No, it's commentary on the rambling style and mostly irrelevant
content of messages from "John D. Hendrickson and Sara Darnell".
This entity claims to be required to send all its messages to the
same mailing list due to some interaction between its own mail
server and its ISP's outgoing spam filter.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2022214123.gt3...@decadent.org.uk

Re: Increasing minimum 'i386' processor

[Josselin Mouette]

Le mardi 22 novembre 2011 à 16:19 -0500, John D. Hendrickson and Sara
Darnell a écrit : 
> Josselin Mouette is apparently easily amused.

I am afraid that text cannot convey my feelings adequately, so please
find here a more appropriate reply: 
http://malsain.org/~joss/amused.jpg

Rest assured that my next contribution to a conversation you are part of
might not be for the list but for its masters.

Kthxbye,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1322001810.6897.8.camel@tomoyo

Re: Increasing minimum 'i386' processor

[Christoph Egger]

Ben Hutchings  writes:
>> Does /proc/cpuinfo with the exist on non-Linux architectures? If
>> yes, do they use the same format?
>
> It is Linux-specific, but included in FreeBSD's Linux compatibility module.
> I don't know whether Debian kFreeBSD loads that by default.

It is loaded. /proc/cpuinfo on field (kfreebsd-i386 buildd):

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 16
model name  : Intel(R) Xeon(TM) CPU 3.80GHz
stepping: 10
processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 16
model name  : Intel(R) Xeon(TM) CPU 3.80GHz
stepping: 10
processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model   : 16
model name  : Intel(R) Xeon(TM) CPU 3.80GHz
stepping: 10
processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model   : 16
model name  : Intel(R) Xeon(TM) CPU 3.80GHz
stepping: 10
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 b19 b21 mmxext mmx fxsr xmm sse2 b27 b28 b29 3dnow
cpu MHz : 3800.15
bogomips: 3800.15


  It's subjectively quite different from linux/x86 but the same is true
for e.g. s390

Regards

Christoph

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lir73gx4@hepworth.siccegge.de

Re: Increasing minimum 'i386' processor

[Matthias Klose]

On 11/19/2011 11:42 PM, Ben Hutchings wrote:
> The i386 architecture was the first in Linux and in Debian, but we have
> long since dropped support for the original i386-compatible processors
> and now require a minimum of a 486-class processor.
> 
> I think it is time to increase the minimum requirement to 586-class, if
> not for wheezy then immediately after.

note that squeeze is built this way, and single packages like openjdk only build
for 586.

> (Later it should be increased
> further, and eventually i386 should be reduced to a partial architecture
> that may be installed on amd64 systems.)  This would allow the use of
> optimisations and new instructions throughout userland that improve
> performance for the vast majority of users.

could you give numbers what kind of improvements you would expect?  The biggest
burden for i386 is the register pressure, which you won't fix with targeting a
newer processor.  The better approach would be a new port, the x32 architecture;
I don't know if anybody did look into building a distribution for this
architecture yet.  The next thing could be to default to sse2 math instead of
x87 (didn't look if this is already the default for x32).

  Matthias


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ecc33cd.7040...@debian.org

Re: Increasing minimum 'i386' processor

[Matthias Klose]

On 11/20/2011 01:08 AM, Guillem Jover wrote:
> Hi!
> 
> On Sat, 2011-11-19 at 22:42:11 +, Ben Hutchings wrote:
>> The i386 architecture was the first in Linux and in Debian, but we have
>> long since dropped support for the original i386-compatible processors
>> and now require a minimum of a 486-class processor.
>>
>> I think it is time to increase the minimum requirement to 586-class, if
>> not for wheezy then immediately after.  (Later it should be increased
>> further, and eventually i386 should be reduced to a partial architecture
>> that may be installed on amd64 systems.)  This would allow the use of
>> optimisations and new instructions throughout userland that improve
>> performance for the vast majority of users.
> 
> It seems gcc has been targetting i586 instruction set by default since
> gcc 4.4.0-1~exp1, although the triplet was not changed to match. On the
> discussion regarding multiarch tuples I proposed we should switch the
> triplet back to i386-linux-gnu to avoid this kind of confusion, fix the
> internal inconsistency and the one with other architectures (which do
> not track the base instruction set in the triplet) and so that we can
> use them directly as the multiarch tuples.
> 
> For more details please see:
> 
>   
>   

No, that's wrong. i386-linux-gnu has a different ABI for at least some libraries
(libstdc++) than i486-linux-gnu.  Unfortunately the proposal to use
ix86-linux-gnu for the i386 multiarch triplet didn't find a consensus.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ecc34e9.6090...@debian.org

Promoção Fim de Ano

[CM Balões e Decorações]

Pomoçao de fim de ano da CMBalões
BALÕES LOGOTIPADOS R$ 200,00 O MILHEIRO
Confira
 
Kit com 100 balões + gás hélio + fitilhos  + monitor  no local deixando tudo 
pronto.
De segunda a sexta: R$ 250,00
Sábado e domingo: R$ 280,00
Kit com 200 balões na mesma proporção 
De segunda a sexta: R$ 350,00
Sábado e domingo: R$ 480,00
E não para por ai, temos balões personalizados com foto ou logotipo com preços 
imbatíveis. Entrega rápida de 3 a 5 dias apenas, sem custo de entrega para 
região de São Paulo (Capital). Temos varetas, gás hélio, aluguel de compressor, 
decoração local, revoadas, mão de obra especializada.
Trabalhamos também com comunicação visual (Banner, faixas e decoração conforme 
o tema).
 
Ligue e faça uma cotação sem compromisso.
(11) 4107-5727
(11) 9219-1273
(11) 8357-7648
e-mail: ven...@cmbaloes.com.br
msn: ven...@camargobaloes.com
site: www.cmbaloes.com.br

Bug#649682: ITP: numm -- numerical arts library for Python

[Dafydd Harries]

Package: wnpp
Severity: wishlist
Owner: Dafydd Harries 

* Package name: numm
  Version : 0.1
  Upstream Author : Dafydd Harries 
* URL : http://numm.org/numm/
* License : GPL
  Programming Lang: Python
  Description : numerical arts library for Python

For programmers familiar with Python or Matlab who are interested in
toying with the sounds and images around them; for artists, designers,
and composers seeking a deeper understanding of the numerical systems
that underlie modern media production.

numm is a minimalist media library that translates popular sound,
image, and video formats to and from NumPy arrays.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2023050039.12894.8981.reportbug@localhost