Bug#823663: RFS: tio/1.6-1 [ITP] -- The simple TTY terminal I/O application
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "tie": Package name: tio Version : 1.6-1 Upstream Author : Martin Lund URL : http://tio.github.io/ License : GPL-2+ Section : comm It builds those binary packages: tio - Simple TTY terminal I/O application To access further information about this package, please visit the following URL: https://mentors.debian.net/package/tio Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/t/tio/tio_1.6-1.dsc More information about tio can be obtained from http://tio.github.io/. Cheers, sur5r
Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction
]] Pierre Ynard > Please tell me, what do I do with it?? Personally, I'd get some more recent hardware. Or run stable. In CPU performance terms, a Pentium MMX (at 200MHz) is about half to a third of the speed of the first-generation raspberry pi (underclocked to 700MHz). There's a limit to how long we're going to support old hardware. The last of the Pentium MMX-es was released in 1999-01. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction
On Sat, May 07, 2016 at 02:42:37AM +0200, Pierre Ynard wrote: > That's not the idea I'd like to have about Debian. If I wanted > a distro where unstable is broken and unusable, I would have installed > long ago. I'm afraid there's not enough people who care about 586 enough to maintain it. And the bad decision of i386 to stick to a single arch during its whole life makes it hard to do so on debian-ports. Compare with ARM: there's arm armel armhf arm64 arm32(arm64ilp32) -- it frequently refreshes the ABI to make use of new CPU features, which also makes it easy to keep old compat without forcing new processors to stay with the lowest common denominator. > What do I do with my i586 system running unstable of last week? Drop it > into a tub of water, just like i586 support is getting dropped? That's > going to cause way more downtime than simply running unstable in > production. > > Please tell me, what do I do with it?? My recommendation would be going to jessie[1], it has whole four years of support left. Anything you need from unstable can be backported. After those four years you can reconsider, in the unlikely case your machine will be still alive. That's four more years than ia64 guys got. Unlike 586's half the speed of first-gen RasPi, ia64 machines can be pretty beefy -- new ones even are still being manufactured. > My "complaint" against unstable is valid. Typical Debian bugs don't > (or at least shouldn't) wait for the stable release to get fixed. I > don't see why you retitled this copy of the bug, since it described the > situation accurately. i586 users running unstable are getting their > system broken, with no obvious way to handle it. Maybe I'm the only such > user and you don't care, then at least have the decency to wontfix me. What kind of solution would you propose? We can't exactly add preinst guards to every single package. The only package that's depended on by (almost) all compiled code is libc6, but because of symbols handling the dependency is usually libc6 (>= 2.15) or such rather than (>= 2.22-7). Meow! [1]. Easiest way to downgrade: put into /etc/apt/preferences a pin for jessie with priority above 1000, then dist-upgrade. -- How to exploit the Bible for weight loss: Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat.
Re: Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction
(Dropping the bug report; replacing with CC to debian-devel)
Adam Borowski writes ("Bug#823465: dpkg: Won't run at all on i586 Pentium MMX
due to illegal instruction"):
> I'm afraid there's not enough people who care about 586 enough to maintain
> it. And the bad decision of i386 to stick to a single arch during its whole
> life makes it hard to do so on debian-ports. Compare with ARM: there's arm
> armel armhf arm64 arm32(arm64ilp32) -- it frequently refreshes the ABI to
> make use of new CPU features, which also makes it easy to keep old compat
> without forcing new processors to stay with the lowest common denominator.
Now that we have multiarch it might be possible to use it to solve
this problem. Suppose we arranged for everything to build
"Architecture: i686" or something, and provided a mapping table to
teach dependency resolvers that "any Architecture: i386 package
satisfies dependencies of Architecture: i686 packages". Or some
scheme along these lines.
But ... I think it's up to people who care about retaining support for
old instruction sets to develop and propose such an arrangement. And
it would only be worthwhile if there would be effort to make d-ports
contain "Architecture: i586" (or i386 or something).
I'm definitely a fan of keeping old hardware working but I certainly
don't have effort for fixing compiler bugs in code generators for
ancient sub-architectures or whatever. I wish those who do have such
effort the best of luck.
> My recommendation would be going to jessie[1], it has whole four years of
> support left. Anything you need from unstable can be backported. After
> those four years you can reconsider, in the unlikely case your machine
> will be still alive.
This is very good advice.
Ian.
Bug#823672: ITP: sse-support -- prevent installation on processors without required support
Package: wnpp
Severity: wishlist
Owner: Adam Borowski
> > It might be also good to make a "sse2-support" package as mentioned in
> > the thread Gert linked to to reduce duplication of such detection logic.
> > Please say so if you think this is a good idea.
>
> Saying "so". :-)
* Package name: sse-support
Upstream Author : me
Binaries: sse2-support, sse3-support, more?
Description : prevent installation on processors without required support
This is a mostly dummy package, whose only purpose is to detect the presence
of ${binary%%-support}. It refuses to install on inadequate processors, thus
allowing specifying such a requirement as a dependency.
Detection is done via a "boom instruction" rather than grep /proc/cpuinfo,
because of qemu and /proc-less chroots.
On failure, preinst complains via debconf and on stderr then dies.
I wonder which other extensions would be wanted -- sse4.2? More?
Note that in general you're not supposed to unconditionally use opcodes not
supported by the baseline ISA, but in some cases adding generic code paths
would be either too much work or outright useless. I for one just failed to
obtain access to a pre-sse2 machine despite raiding quite a few places; thus
it's understandable no one bothers to port scientific software to such
museal machines.
I'm afraid it's too late to use this for 686, though.
Re: Debian i386 architecture now requires a 686-class processor
Hi,
Ben Hutchings wrote:
> Last year it was decided to increase the minimum CPU features for the
> i386 architecture to 686-class in the stretch release cycle. This
> means dropping support for 586-class and hybrid 586/686
> processors[1].(Support for 486-class processors was dropped, somewhat
> accidentally, in squeeze.)
Is it possible that some 586-class processors support all the necessary
instructions to still run this kernel and/or userland?
I seem to remember last time this was discussed, GNU `as' avoids using a
particular 686-class instruction
To give an example, this Geode MX is not quite 686-class but has CMOV:
| cpu0: Geode(TM) IntegraTed Processor by National Semi ("Geode by NSC"
586-class) 333 MHz
| cpu0: FPU,DE,PSE,TSC,MSR,CX8,PGE,CMOV,MMX,MMXX,3DNOW2,3DNOW
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture
> * Package name: sse-support
> Upstream Author : me
> Binaries: sse2-support, sse3-support, more?
> Description : prevent installation on processors without required
> support
> This is a mostly dummy package, whose only purpose is to detect the presence
> of ${binary%%-support}. It refuses to install on inadequate processors, thus
> allowing specifying such a requirement as a dependency.
>
This e-mail is written with the awareness of PowerPC, ARM, MIPS and ARM64
architectures.
My gut feeling says that the package 'sse-support' is sabotage on architecture
"any".
After reading https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions I'm even
more sure that "sse-support" is about 'there is only one true processor
architecture'
I think that is wrong.
Groeten
Geert Stappers
--
Leven en laten leven
Re: Debian i386 architecture now requires a 686-class processor
Steven Chamberlain wrote: > I seem to remember last time this was discussed, GNU `as' avoids using a > particular 686-class instruction I found a reference for that: https://lists.debian.org/debian-devel/2015/09/msg00617.html So it seems the "nearly 686" Geode LX/NX may still work after this change; I will try to test this. I'm curious to know if there are other examples. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: Debian i386 architecture now requires a 686-class processor
On Sat, 2016-05-07 at 13:45 +0100, Steven Chamberlain wrote:
> Hi,
>
> Ben Hutchings wrote:
> >
> > Last year it was decided to increase the minimum CPU features for the
> > i386 architecture to 686-class in the stretch release cycle. This
> > means dropping support for 586-class and hybrid 586/686
> > processors[1].(Support for 486-class processors was dropped, somewhat
> > accidentally, in squeeze.)
> Is it possible that some 586-class processors support all the necessary
> instructions to still run this kernel and/or userland?
>
> I seem to remember last time this was discussed, GNU `as' avoids using a
> particular 686-class instruction
We're following the definition of 686-class that is implemented by gcc
and the kernel. This apparently differs in two ways from Intel's
original definition of 686-class (though I don't know where that is):
1. Intel specified NOPL (long NOP) as a required feature, but we don't
use it.
2. Intel specified CMOV as an optional feature, but we *do* use it.
I hoped that giving a list of the affected processors would clarify
this.
> To give an example, this Geode MX is not quite 686-class but has CMOV:
>
> >
> > cpu0: Geode(TM) IntegraTed Processor by National Semi ("Geode by NSC"
> > 586-class) 333 MHz
> > cpu0: FPU,DE,PSE,TSC,MSR,CX8,PGE,CMOV,MMX,MMXX,3DNOW2,3DNOW
That should still be supported.
Ben.
--
Ben Hutchings
Editing code like this is akin to sticking plasters on the bleeding stump
of a severed limb. - me, 29 June 1999
signature.asc
Description: This is a digitally signed message part
Re: Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture
On Sat, May 07, 2016 at 03:23:41PM +0200, Geert Stappers wrote: > > My gut feeling says that the package 'sse-support' is sabotage on > architecture "any". > This is from #823465 http://bugs.debian.org/823465 | I'm afraid there's not enough people who care about 586 enough to maintain | it. And the bad decision of i386 to stick to a single arch during its whole | life makes it hard to do so on debian-ports. Compare with ARM: there's arm | armel armhf arm64 arm32(arm64ilp32) -- it frequently refreshes the ABI to | make use of new CPU features, which also makes it easy to keep old compat | without forcing new processors to stay with the lowest common denominator. I now have a better idea _why_ a sse-suport package. My concern is how should look a Debian control file at source level ( arch all ). At arch Intel makes a 'Depends: sse-support' sense Having at arch ARM 'Depens: sse-support' also, will prevent install, but not `build`. Gee, what a can of worms is thirty years so called binary compatible. Groeten Geert Stappers -- Leven en laten leven signature.asc Description: Digital signature
Re: Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture
On 05/07/2016 03:59 PM, Geert Stappers wrote: > On Sat, May 07, 2016 at 03:23:41PM +0200, Geert Stappers wrote: >> >> My gut feeling says that the package 'sse-support' is sabotage on >> architecture "any". >> > > This is from #823465 http://bugs.debian.org/823465 > > | I'm afraid there's not enough people who care about 586 enough to maintain > | it. And the bad decision of i386 to stick to a single arch during its whole > | life makes it hard to do so on debian-ports. Compare with ARM: there's arm > | armel armhf arm64 arm32(arm64ilp32) -- it frequently refreshes the ABI to > | make use of new CPU features, which also makes it easy to keep old compat > | without forcing new processors to stay with the lowest common denominator. > > > I now have a better idea _why_ a sse-suport package. > > My concern is how should look a Debian control file at source level ( arch > all ). > At arch Intel makes a 'Depends: sse-support' sense > Having at arch ARM 'Depens: sse-support' also, will prevent install, but not > `build`. I really don't get what you are saying here. Of course one would NOT have an arch: any package in Debian that depends on sse-support on non-i386, you'd put in Depends: sse-support [i386] in debian/control and the package build would then add the dependency on i386, but not and anything on other platforms. (If the package in question even supports other platforms than x86 in the first place.) Why so critical? The current situation is that if there's a package in the archive that now only works with SSE extensions, and is not easily portable to non-SSE (for example, if it contains hand-written assembly code), then the only recourse that's available _now_ is to drop i386 from that package's architecture (because it will segfault without a good error message) - or to add detection in preinst... (Because porting is not always an option, especially if it's lots of code.) This does not, however, excuse packages to force SSE support if a package CAN support other hardware, and it wasn't meant to. It is meant to cover the cases where a package is either not available on i386 at all or available to at least some users. I fail to see why you would think this is a bad thing? @Adam: One suggestion though: since this might also come in handy in other places, I'd recommend you name the source package something more generic (such as cpu-support or so, assuming that's not taken already, I didn't check), and have it generate a binary package with the name sse-support. I'm pretty sure that other cases could come up with a similar requirement in the future, and that way they'd easily find a home. Regards, Christian signature.asc Description: OpenPGP digital signature
Re: Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture
On Sat, May 07, 2016 at 04:14:05PM +0200, Christian Seiler wrote: > On 05/07/2016 03:59 PM, Geert Stappers wrote: > > On Sat, May 07, 2016 at 03:23:41PM +0200, Geert Stappers wrote: > >> My gut feeling says that the package 'sse-support' is sabotage on > >> architecture "any". Obviously, it's arch specific. > > This is from #823465 http://bugs.debian.org/823465 Sadly, nope. We'd need to somehow add a (possibly indirect) dependency on 686-support to every single gcc-compiled package on i386. > > I now have a better idea _why_ a sse-suport package. > > > > My concern is how should look a Debian control file at source level ( arch > > all ). > > At arch Intel makes a 'Depends: sse-support' sense > > Having at arch ARM 'Depens: sse-support' also, will prevent install, but > > not `build`. > > I really don't get what you are saying here. Of course one would NOT > have an arch: any package in Debian that depends on sse-support on > non-i386, you'd put in Depends: sse-support [i386] in debian/control > and the package build would then add the dependency on i386, but not > and anything on other platforms. (If the package in question even > supports other platforms than x86 in the first place.) I'd guess a package that has generic code paths is unlikely to have such a strict dependency (although sse2 is so old that a number-crunching package probably won't bother with runtime detection). > Why so critical? The current situation is that if there's a package > in the archive that now only works with SSE extensions, and is not > easily portable to non-SSE (for example, if it contains hand-written > assembly code), then the only recourse that's available _now_ is to > drop i386 from that package's architecture (because it will segfault > without a good error message) - or to add detection in preinst... Detection in preinst is exactly what sse-detect is for, yeah. > @Adam: One suggestion though: since this might also come in handy > in other places, I'd recommend you name the source package something > more generic (such as cpu-support or so, assuming that's not taken > already, I didn't check), and have it generate a binary package with > the name sse-support. I'm pretty sure that other cases could come up > with a similar requirement in the future, and that way they'd easily > find a home. Good idea! The test harness is already templated, so there's no reason to make this x86 specific. I think I'll put the master list as an 822-formatted file like: .-- Name: sse2 Architecture: any-i386 Instruction: addpd %xmm0, %xmm1 Name: sse3 Architecture: any-i386 any-amd64 x32 Instruction: haddpd %xmm0, %xmm1 Name: fp11 Architecture: pdp11 Instruction: ldbt ` which on pdp11 will generate fp11-support which will do the right thing (assuming I read the docs correctly, I don't know PDP-11 assembly :þ). Meow! -- How to exploit the Bible for weight loss: Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat.
Re: Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture
On Sat, 07 May 2016 at 17:15:51 +0200, Adam Borowski wrote: > Good idea! The test harness is already templated, so there's no reason to > make this x86 specific. Altivec detection on 32-bit powerpc would also be useful, assuming 32-bit powerpc has a future in Debian at all. ioquake3:powerpc would depend on it. (If anyone reading this has a non-Altivec PowerPC capable of running a 1999 game engine and thinks ioquake3 needs to support it, there's a request for testing on #701561.) S
Bug#823693: ITP: asciiquarium -- Enjoy the mysteries of the sea from the safety of your own terminal!
Package: wnpp Severity: wishlist Owner: Niklas Sombert * Package name: asciiquarium Version : 1.1 Upstream Author : Kirk Baucom * URL : http://www.robobunny.com/projects/asciiquarium/html/ * License : GPL2 Programming Lang: Perl Description : Enjoy the mysteries of the sea from the safety of your own terminal! This is a simulation of an aquarium with ASCII art in a terminal. It it not very useful but I find it enjoyable - it'a a nice gimmick. KDE Plasma used to include a screensaver which looked similar. This is my first package for Debian - it would be nice if I could get a sponsor. - Niklas
Re: Bug#823693: ITP: asciiquarium -- Enjoy the mysteries of the sea from the safety of your own terminal!
On Sat, May 07, 2016 at 08:57:03PM +0200, Niklas Sombert wrote: > * Package name: asciiquarium > * URL : http://www.robobunny.com/projects/asciiquarium/html/ > * License : GPL2 > Programming Lang: Perl > Description : Enjoy the mysteries of the sea from the safety of your own > terminal! > > This is a simulation of an aquarium with ASCII art in a terminal. > > It it not very useful but I find it enjoyable - it'a a nice gimmick. > KDE Plasma used to include a screensaver which looked similar. One problem: it depends on Term::Animation, which isn't packaged in Debian yet. I heard that our Perl team have a tool to do the entirety of packaging of CPAN modules with a single command, but I don't know the details. And, this looks like an issue: "License: unknown". -- How to exploit the Bible for weight loss: Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat.
Fingerprint-GUI?
Hello all, Is there an effort to package fingerprint-GUI? Does anybody have a one-off .deb for Jessie for this that they may be using? http://www.ullrich-online.cc/fingerprint/ Cheers! -- Boyan Penkov http://www.boyanpenkov.com
Re: Bug#823693: ITP: asciiquarium -- Enjoy the mysteries of the sea from the safety of your own terminal!
On Sat, May 07, 2016 at 10:19:27PM +0200, Niklas Sombert wrote: > Adam Borowski wrote: > > > One problem: it depends on Term::Animation, which isn't packaged in > > Debian yet. I heard that our Perl team have a tool to do the entirety > > of packaging of CPAN modules with a single command, but I don't know the > > details. > > Yes, I've heard about dh-make-perl. It's very good! > In fact, I've built those packages already: > https://launchpad.net/~ytvwld/+archive/ubuntu/asciiquarium/+packages Cool! If you have already done this, there are no _technical_ reasons against inclusion -- on a "slow scroll"-level review, the code seems sound. People may complain against archive bloat but this package compares favourably to, eg, nyancat (2×arch:all vs 2×arch:any). > > And, this looks like an issue: "License: unknown". > > Yeah, that's a big issue. Perhaps I could try contacting the author? Right. -- How to exploit the Bible for weight loss: Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat.
Re: Bug#823693: ITP: asciiquarium -- Enjoy the mysteries of the sea from the safety of your own terminal!
Adam Borowski wrote: > One problem: it depends on Term::Animation, which isn't packaged in > Debian > yet. I heard that our Perl team have a tool to do the entirety of > packaging > of CPAN modules with a single command, but I don't know the details. Yes, I've heard about dh-make-perl. It's very good! In fact, I've built those packages already: https://launchpad.net/~ytvwld/+archive/ubuntu/asciiquarium/+packages > And, this looks like an issue: "License: unknown". Yeah, that's a big issue. Perhaps I could try contacting the author? - Niklas
Re: Fingerprint-GUI?
I could certainly see your point; also, all the relevant upstreams are pretty slowly developed. However, for some cases and with appropriate cautions, using fingerprint readers may be useful. This effort is not on the critical path, it seems. cheers! On Sat, May 07 2016, Andrew Shadura wrote: > On 7 May 2016 at 22:33, Boyan Penkov wrote: > > Is there an effort to package fingerprint-GUI? Does anybody have a one-off > > .deb for Jessie for this that they may be using? > > Fingerprint readers are insecure, and that's something that can't be > fixed. I'd prefer to see fewer fingerprint-related software packages > in Debian rather than more. -- Boyan Penkov http://www.boyanpenkov.com
Re: Bug#823693: ITP: asciiquarium -- Enjoy the mysteries of the sea from the safety of your own terminal!
On Sat, 07 May 2016 22:13:55 +0200, Adam Borowski wrote: > One problem: it depends on Term::Animation, which isn't packaged in Debian > yet. I heard that our Perl team have a tool to do the entirety of packaging > of CPAN modules with a single command, but I don't know the details. And, > this looks like an issue: "License: unknown". I guess you mean the "License: unknown" in the left column of https://metacpan.org/release/Term-Animation ? That just means that metacpan failed to automatically extract the license (probably because it's not mentioned in META.yml or META.json). Looking at the tarball [0], the license is clear and free in the README [1]: #v+ COPYRIGHT AND LICENCE Copyright (C) 2003 Kirk Baucom L This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself. #v- So that's, as very common for Perl modules, "License: Artistic or GPL-1+". No need to double-check with the author :) (Usual sales pitch: https://wiki.debian.org/Teams/DebianPerlGroup/Welcome ) Cheers, gregor [0] https://cpan.metacpan.org/authors/id/K/KB/KBAUCOM/Term-Animation-2.6.tar.gz [1] also online: https://metacpan.org/source/KBAUCOM/Term-Animation-2.6/README -- .''`. Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Wir sind Helden: Labyrinth signature.asc Description: Digital Signature
Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction
> My recommendation would be going to jessie[1], it has whole four years > of support left. Anything you need from unstable can be backported. Hopefully the downgrade path would be workable. > After those four years you can reconsider, in the unlikely case your > machine will be still alive. That's harsh. The hardware is almost 20 years old, and it's been running the same Debian install for 11 years already. I don't see 4 more years as too unlikely. > That's four more years than ia64 guys got. Unlike 586's half the speed > of first-gen RasPi, ia64 machines can be pretty beefy -- new ones even > are still being manufactured. I'm aware yes. > What kind of solution would you propose? We can't exactly add preinst > guards to every single package. The only package that's depended on by > (almost) all compiled code is libc6, but because of symbols handling > the dependency is usually libc6 (>= 2.15) or such rather than (>= > 2.22-7). I was thinking more along the lines of adding some central check in dpkg maybe, that detects the lack of i686 support and errors out on new, incompatible packages. Discriminating packages could be as simple as a by-passable check on the build/release date. But then this is a bit late to implement in advance. -- Pierre Ynard "Une âme dans un corps, c'est comme un dessin sur une feuille de papier."
Bug#823715: ITP: golang-github-franela-goblin -- minimal and beautiful Go testing framework
Package: wnpp Severity: wishlist Owner: Dmitry Smirnov X-Debbugs-CC: debian-devel@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package name: golang-github-franela-goblin Version: 0.0.1+git20160123 Upstream Author: Marcos Lilljedahl and Jonathan Leibiusky License: Expat URL: https://github.com/franela/goblin Description: minimal and beautiful Go testing framework Mocha (http://visionmedia.github.io/mocha/) like BDD testing framework for Golang. signature.asc Description: This is a digitally signed message part.
Bug#823718: ITP: golang-github-franela-goreq -- minimal and simple request library for Go language
Package: wnpp Severity: wishlist Owner: Dmitry Smirnov X-Debbugs-CC: debian-devel@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Control: block -1 by 823715 Control: affects -1 grafana Package name: golang-github-franela-goreq Version: 0.0~git20160121 Upstream Author: Jonathan Leibiusky and Marcos Lilljedahl License: Expat, BSD-3-Clause~Google URL: https://github.com/franela/goreq Description: minimal and simple request library for Go language GoReq Simple and sane HTTP request library for Go language. signature.asc Description: This is a digitally signed message part.
Re: Debian i386 architecture now requires a 686-class processor
On Sat, May 7, 2016 at 8:23 PM, Ben Hutchings wrote: > Last year it was decided to increase the minimum CPU features for the > i386 architecture to 686-class in the stretch release cycle. d-d-a is mostly for developers, you might like to reach our users via the Debian publicity team: https://wiki.debian.org/Teams/Publicity/DeveloperInformation -- bye, pabs https://wiki.debian.org/PaulWise
Re: Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture
On Sun, May 8, 2016 at 1:51 AM, Simon McVittie wrote: > Altivec detection on 32-bit powerpc would also be useful Probably also NEON on ARM? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Fingerprint-GUI?
On Sun, May 8, 2016 at 4:33 AM, Boyan Penkov wrote: > Is there an effort to package fingerprint-GUI? Generally you can answer this by looking at wnpp bugs: https://www.debian.org/devel/wnpp/ There is a search interface here: http://wnpp.debian.net/ Using that finds that there was someone interested in packaging it back in 2012 but their efforts never reached Debian: https://bugs.debian.org/666990 You may want to discuss this with the fingerforce team: https://wiki.debian.org/FingerForce https://wiki.debian.org/Teams/FingerForce -- bye, pabs https://wiki.debian.org/PaulWise
