Re: Defaulting to i686 for the Debian i386 architecture
On Mon, Sep 28, 2015 at 09:31:03PM -0700, Josh Triplett wrote: > [Please CC me; not subscribed to -devel.] > Ben Hutchings wrote: > > So far as I know, all current Quark processors have errata that make > > them unstable, not to mention totally insecure, when running ordinary > > i386 binaries. > News to me. Link please? Because I don't know what they'd run if *not* > ordinary x86 binaries, and everyone I know targeting them builds > ordinary x86 binaries. :) I don't have a quark, but apparently LOCK prefix is broken: https://sourceware.org/ml/libc-alpha/2015-05/msg00144.html and the related debian bug with link to actual errata: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738575 Riku
Re: Defaulting to i686 for the Debian i386 architecture
Ben Hutchings wrote: Since the 686-class, introduced with the Pentium Pro, is now almost 20 years old, we believe there are few Debian systems still running that have 586-class or hybrid processors. The only such processors apparently still available for sale are the DM&P Vortex86 family, Intel Quark and Xeon Phi, of which we currently only support the Vortex86. I don’t know whether we currently have the ability to run standard x86 binaries on the Xeon Phi coprocessors, but it definitely sounds like something we should try to obtain, not to prevent. Otherwise we’ll end up with yet another half-assed, unmaintainable way to build specific binaries for HPC. -- Joss
Bug#800437: ITP: python-sievelib -- Client-side Sieve and Managesieve library
Package: wnpp Severity: wishlist Owner: Michael Fladischer -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-sievelib Version : 0.8 Upstream Author : Antoine Nguyen * URL : https://pypi.python.org/pypi/sievelib * License : Expat Programming Lang: Python Description : Client-side Sieve and Managesieve library Client-side Sieve and Managesieve library written in Python. . Sieve: Currently, the provided parser supports most of the functionalities described in RFC 5228. The only exception concerns section 2.4.2.4. Encoding Characters using "encoded-character" which is not supported. The following Sieve extensions are also supported: * Date and Index (RFC 5260) * Vacation (RFC 5230) . ManageSieve: All mandatory commands are supported. The RENAME extension is supported, with a simulated behaviour for server that do not support it. For the AUTHENTICATE command, supported mechanisms are DIGEST-MD5, PLAIN and LOGIN. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJWCmSZAAoJEGlMre9Rx7W2zxgQAJFiF8aI2HleVK/v4bBgXYW/ +piXia+uP5o1k0H2fLrI/HNumSQGUryQTz1iYMRb3z3OtRv/qGTnPNTchx2qpLBw chQJHAs8Gv/SRILFy8J+vs0P66QCORYevbN846ZjPO06/QkowVIywnm3BXgxkr7r eTShIgNG3S5tv1dosOXgzifqEowIHIlP6Z9iI6FfwhhGfsE+cs4j8znwOHfWcVEG EMqDb79fKlk19IAHAtyOL4cW7k3hBkoWQqyGu+1kZmJw18Imi3bUasP/MmCwIPAm ZoXyeQpvkGo59VkRpE0swYZNrjztSbx54f0XMgT8g5SAbUXBMTc5PYuA3pp2ZBYh Zvku0joyzVZKGooX4yRZ8AHtCOMLG9Xj2aFi7/sP5U9+0MZI2I51TeyBoC5lIb1L vFhUVA82dNTGC7xSqxOQrsggSsJdWzc6dds1E2WWCHVqZimLTKyqNTSaJeSaFNKa ZDG+BvNMJXaa9cnZI9kr5jVNqK6GuFi79Tafx25y+JToE38xMDFallpcGoOOrD3Q xMVAiMYfITTXTu0Bv8PITkM8OGEgWfvZUxlJpPQWiwVt5zyPXCDqY4MuxgT0Yebk I5X3ukw/Ek318vU0ntBkS05PIwO+5Tkf/69Y4j7h87sD67XfplNZELrRXg7FcEud VpxwsooeCPOtmX7VE/Xh =OsAc -END PGP SIGNATURE-
Re: Defaulting to i686 for the Debian i386 architecture
2015-09-28 23:34 Josh Triplett: Ben Hutchings wrote: We propose to drop support for i386 processors older than 686-class in the current release cycle. This would include folding libc6-i686 into libc6, changing the default target for gcc, and changing the 586 kernel flavour to 686 (non-PAE). Since the 686-class, introduced with the Pentium Pro, is now almost 20 years old, we believe there are few Debian systems still running that have 586-class or hybrid processors. The only such processors apparently still available for sale are the DM&P Vortex86 family, Intel Quark and Xeon Phi, of which we currently only support the Vortex86. Debian i386 currently works just fine on Quark processors; the only special support required for Quark lives in the kernel (e.g. handling an MSR that the Pentium had but Quark doesn't), and the Linux kernel already has that support. Please don't break that. While people building a production system for Quark may well build a custom embedded installation image, it's extremely useful to be able to boot a "stock" Debian installation or live distribution on a Quark board. Many distributions have already dropped that support, making it all the more valuable that Debian hasn't. I can certainly understand dropping i386 and i486, but i586 remains useful today precisely because of Quark. Deprecating old systems that don't get built anymore would seem perfectly reasonable; however, people buy these systems new today, and will continue to do so in the future. Maybe it would be a good idea to split the architectures, and have one port for legacy-but-still-sold-or-useful i386 and move the current i386 to only support newer, common-use i686 hardware. If Xeon Phi can be accomodated in the legacy architecture as well, great. Maybe there are not enough volunteers for the port, or none at all; but at least getting machines shouldn't be a big problem compared to other arches if current i686/amd64 systems can be used to compile targetting those older instruction sets. (I am not volunteering by the way, I have no interest in these ports, just proposing it as a possible solution). In a way, most people using i386 in the desktop nowadays could use x32, but I seem to remember that in practice it still has many problems and out-of-date or missing packages (I don't know if just because of being understaffed, or deeper problems like many packages needing upstream support). Or these people also could move to amd64, but well... if they haven't moved yet... It also seems reasonable for certain classes of packages to not bother with i586 support, such as office suites, desktop environments, graphical web browsers, media libraries, and anything depending on a GUI. (Ideally, some obvious mechanism would exist to distinguish those packages, so that the package manager would prevent the installation of packages that will SIGILL.) This is probably easier to achive with a port as well, excluding undesided packages. Cheers. -- Manuel A. Fernandez Montecelo
Re: Defaulting to i686 for the Debian i386 architecture
On Tue, 2015-09-29 at 10:02 +0200, Josselin Mouette wrote: > Ben Hutchings wrote: > Since the 686-class, introduced with the Pentium Pro, is now almost 20 > years old, we believe there are few Debian systems still running that > have 586-class or hybrid processors. The only such processors > apparently still available for sale are the DM&P Vortex86 family, > Intel > Quark and Xeon Phi, of which we currently only support the Vortex86. > > I don’t know whether we currently have the ability to run standard x86 > binaries on the Xeon Phi coprocessors, but it definitely sounds like > something we should try to obtain, not to prevent. Otherwise we’ll end > up with yet another half-assed, unmaintainable way to build specific > binaries for HPC. Contrary to what I thought, the Xeon Phi processors are actually 64-bit . However I think they're a little too weird to support with the same binaries - no CMOV, no MMX and no SSE. Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part
Re: Defaulting to i686 for the Debian i386 architecture
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Enigmail -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWCnjpAAoJEMvmu05dmtOlhhAP/jrONPeihYKvvXYr34m6e47B aw3MoFNkhT3NOSMujd3mfqPIejrDwbuV3aC7puvS9DCLZDPpxqbXaUnEOj9fe/dW MJvTn9A1vNitJNKt7cJ+OYkl+EP+dV2BIXy29+C1mId3SozbBWbFRjWBgTfVpUjb pSnEM/h8jQM9TZC2tvvkab1BPrwpGRZBWJpSm7F8eNsqUASPcPA4KPTjOvbgcQRA DnVwTss85qdgMKBm6V/50yLgVeAv5wOTxtDmHT+Ejdqu47s4aFp/RpGSjAVkUK0x MkHYx1WjbTWkRs4vbd6dHn86+OM4JQGQ1rN6H1ffBtWBTMaIBLoz85o9koJhk+bs Mmuq7UCuOqImyqj/kDHHxOBwZ9c1dxbvnlGJxzewb5p9sjucPI2JGvILzgF5wA3r /G3KbkDg0sDnpmuxNgxbvcppfgcFh7oslfZYRE0d5Iz+rjfk7MgmVeaF7nIVdB6l MWxyYpLOn3yQ43BVgu5xg5eY/Ow4ogHbgBXWGtHAMRn35Huf6Hw3eZt6FnSgbVr3 PtMBnZp8/ZEt8018oSD/bZf8X2U49TrleLYHCYwcebhYxe5zF8Yd8f5eha5yPSQf +GrKkLb9qZU9zw4vTKRbTJ96PLJvmOjSWEwNRrz6hbL4qVOWnazj4xw93CiuaM9X PIkC8uBceqfJtAbSAv6V =9zdU -END PGP SIGNATURE-
Re: Defaulting to i686 for the Debian i386 architecture
On Tue, Sep 29, 2015 at 06:48:26AM +, Riku Voipio wrote: > On Mon, Sep 28, 2015 at 09:31:03PM -0700, Josh Triplett wrote: > > [Please CC me; not subscribed to -devel.] > > Ben Hutchings wrote: > > > So far as I know, all current Quark processors have errata that make > > > them unstable, not to mention totally insecure, when running ordinary > > > i386 binaries. > > > News to me. Link please? Because I don't know what they'd run if *not* > > ordinary x86 binaries, and everyone I know targeting them builds > > ordinary x86 binaries. :) > > I don't have a quark, but apparently LOCK prefix is broken: > > https://sourceware.org/ml/libc-alpha/2015-05/msg00144.html > > and the related debian bug with link to actual errata: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738575 Gah. Thanks for the info; that's all kinds of awful. I find myself rather astounded that stock Debian worked for me, then. And I retract the objection; go ahead and remove i586 support. - Josh Triplett
Re: Bug#800093: ITP: libdpkg-parse-perl -- module to parse various dpkg files into Perl Objects
Hi!
On Mon, 2015-09-28 at 12:37:22 +0100, Andrew Beverley wrote:
> On Mon, 2015-09-28 at 13:12 +0200, Guillem Jover wrote:
> > On Sat, 2015-09-26 at 21:12:57 +0300, Andy Beverley wrote:
> > > Package: wnpp
> > > Owner: Andy Beverley
> > > Severity: wishlist
> > > X-Debbugs-CC: debian-devel@lists.debian.org,
> > > debian-p...@lists.debian.org
> > >
> > > * Package name: libdpkg-parse-perl
> >
> > What's the advantage of this over the various modules in libdpkg-perl?
>
> I think it's the only way to retrieve version information. It's a long time
> since I wrote my original patch for dh-make-perl, but I seem to remember
> that DPKG::Parse was the only module that provided certain information I
> needed (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774074).
>
> I certainly tried to do it with other modules already packaged, but I
> couldn't gain all the required information.
The attached untested patch should in principle do it. In any case the
available file is only ever up-to-date when using dselect. If it's too
slow, this should be fixed in libdpkg-perl anyway as that would benefit
every caller.
Thanks,
Guillem
From 30408bf2dd2cd7da3a794a1a5869a4cdcf1c8332 Mon Sep 17 00:00:00 2001
From: Guillem Jover
Date: Tue, 29 Sep 2015 15:06:34 +0200
Subject: [PATCH] Switch from libdpkg-parse-perl to libdpkg-perl modules
---
Build.PL| 3 ++-
debian/control | 1 -
lib/Debian/Control/FromCPAN.pm | 18 --
lib/DhMakePerl/Command/Packaging.pm | 16 +---
4 files changed, 15 insertions(+), 23 deletions(-)
diff --git a/Build.PL b/Build.PL
index cc3ae8b..e2eaf31 100644
--- a/Build.PL
+++ b/Build.PL
@@ -7,7 +7,6 @@ my $builder = My::Builder->new(
module_name => 'DhMakePerl',
license => 'gpl',
recommends => {
-'DPKG::Parse' => 0.02,
'Git' => 0,
'IO::Dir' => 0,
},
@@ -24,6 +23,8 @@ my $builder = My::Builder->new(
'CPAN::Meta'=> 0,
'Cwd' => 0,
'Dpkg' => 0,
+'Dpkg::Index' => 0,
+'Dpkg::Control::Types' => 0,
'Dpkg::Source::Package' => 0,
'Email::Address'=> 0,
'Email::Date::Format' => 0,
diff --git a/debian/control b/debian/control
index f02f170..2de9da9 100644
--- a/debian/control
+++ b/debian/control
@@ -78,7 +78,6 @@ Depends: debhelper (>= 8),
${perl:Depends}
Recommends: apt-file (>= 2.5.0),
git,
-libdpkg-parse-perl,
pristine-tar
Description: helper for creating Debian packages from perl modules
dh-make-perl will create the files required to build a Debian source
diff --git a/lib/Debian/Control/FromCPAN.pm b/lib/Debian/Control/FromCPAN.pm
index b0895e1..f4d5d48 100644
--- a/lib/Debian/Control/FromCPAN.pm
+++ b/lib/Debian/Control/FromCPAN.pm
@@ -48,11 +48,12 @@ An instance of L to be used when locating to which package
a required module belongs.
=item dpkg_available
-An instance of L to be used when checking whether
+
+An instance of L to be used when checking whether
the locally available package is the required version. For example:
-my $available = DPKG::Parse::Available->new;
-$available->parse;
+my $available = Dpkg::Index->new(type => CTRL_INFO_PKG);
+$available->load("$Dpkg::ADMINDIR/available");
=item dir
@@ -272,7 +273,7 @@ L class) and a list of missing modules.
Perl core is searched first, then installed packages, then the APT contents.
-If a DPKG::Parse::Available object is passed, also check the available package version
+If a Dpkg::Index object is passed, also check the available package version.
=cut
@@ -307,12 +308,12 @@ sub find_debs_for_modules {
);
# Check the actual version available, if we've been passed
-# a DPKG::Parse::Available object
+# a Dpkg::Index object
if ( $dpkg_available ) {
my @available;
my @satisfied = grep {
-if ( my $pkg = $dpkg_available->get_package('name' => $_) ) {
-my $have_pkg = Debian::Dependency->new( $_, '=', $pkg->version );
+if ( my $pkg = $dpkg_available->get_by_key($_) ) {
+my $have_pkg = Debian::Dependency->new( $_, '=', $pkg->{Version} );
push @available, $have_pkg;
$have_pkg->satisfies($dep);
}
@@ -327,9 +328,6 @@ sub find_debs_for_modules {
push @missing, $module;
}
}
-else {
-warn "DPKG::Parse not available. Not checking version of $module.";
-}
}
if (!$dep && $apt_contents) {
diff --git a/lib/DhMakePerl/Command/Packaging.pm b/lib/DhMakePerl/Command/Packaging.pm
index
Re: Bug#800093: ITP: libdpkg-parse-perl -- module to parse various dpkg files into Perl Objects
On Tue, 2015-09-29 at 15:28 +0200, Guillem Jover wrote: > The attached untested patch should in principle do it. Thanks Guillem, will test that soon. Andy
Re: Defaulting to i686 for the Debian i386 architecture
Ben Hutchings wrote: Contrary to what I thought, the Xeon Phi processors are actually 64-bit . However I think they're a little too weird to support with the same binaries - no CMOV, no MMX and no SSE. I think we’ve both been mistaken by Intel documents describing Xeon Phi as being based on the P54C microarchitecture. But this was only for the early, mostly experimental designs. As of Knights Landing, it is based on Airmont Atom cores which indeed support x86_64. -- Joss
Re: Defaulting to i686 for the Debian i386 architecture
+++ Manuel A. Fernandez Montecelo [2015-09-29 12:27 +0100]: > 2015-09-28 23:34 Josh Triplett: > >Many distributions have already dropped that support, making it all the > >more valuable that Debian hasn't. I can certainly understand dropping > >i386 and i486, but i586 remains useful today precisely because of Quark. > >Deprecating old systems that don't get built anymore would seem > >perfectly reasonable; however, people buy these systems new today, and > >will continue to do so in the future. > > Maybe it would be a good idea to split the architectures, and have one > port for legacy-but-still-sold-or-useful i386 and move the current i386 > to only support newer, common-use i686 hardware. It seems to me that this relates to a similar issue with armel, and previous consideration of 'partial architectures' for mips (and arm). like '586-ISA i386', armel is now a port used only on low-end hardware, but that hardware can still be bought new, primarily as NAS boxes. Debian is one of the last distros supporting this, which makes dropping it quite hard on those still using it. However there is a large fraction of the archive that is not very useful on such machines, and a part of the archive that is starting to need major work to keep building for such hardware at all. The main disadvantage of keeping around old arches is the effort involved in keeping software building/working on it when the rest of the world no longer cares. Having a mechanism for 'partial architectures' to keep only the relevant subset of the archive available for these machines seems like a good plan, useful for at least i386 and armel, and probably others. Because a debian arch refers to an ABI, not an ISA-variant, you can't easily use our existing architectures mechanism to have both 'i386' and 'i686' without breaking some fairly fundamental assumptions. Being able to have 'partial achitectures' which are actually different baseline ISAs (586, 686) (armv6, armv7) for one ABI is something that has been discussed many times, but no-one has ever cared enough to actually implement it. This is particularly relevant on mips, where inconsistent ISA changes over the years mean that make picking one 'base ISA' is very unsatisfactory, and they would like a way of having alternative ISA (not ABI) builds of a significant set of packages (anthing where speed actually matters, so libc, some core things and anything codec-related, at least). (The rasbian port could have done things this way and stayed within Debian for example, but it was easier to derive). Some details of a proposal for implemnting this are covered in section 2 of https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results It would need fleshing out some more to actually be complete. Nevertheless, if we implemented that, the question of how the subsetting is done remains (i.e which packages are/are-not available in the other 'flavour'). I wonder if we could re-use sections or components for some kind of suitable classification? Such a mechanism could perhaps also be used for the 'set of things that won't build on 32-bit arches any more' for example, which is closely related to the 'set of stuff that is useless on a NAS box'. I hope that wasn't too rambling to be useful... Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Re: GitLab B.V. to host free-software GitLab for Debian project (was: debian github organization ?)
On Apr 22, 2015, at 01:25 PM, Ben Finney wrote: >Rather, this is the Debian project considering our own instance of a >first-class Git hosting platform. I guess this would mean being able to use the Debian GitLab instance for package development, rather than say Alioth? For straight-up hosting of packages already converted to git, with merge requests, I think this could be a big win. Once e.g. the Python team completes the move to git, I'd love to use features from GitLab to maintain our packages. (I'm a fan of GitLab, using it to host my own upstreams, as well as GNU Mailman 3.) What about some of the other GitLab features though? Presumably we wouldn't want issues to replace BTS. Also, how would we handle membership for things like team-maintained packages? Thanks Sytse for the generous offer. Cheers, -Barry pgpgCKkHk3SSL.pgp Description: OpenPGP digital signature
Re: Bug#799682: ITP: ruby-quiet_assets -- A gem that turns off Rails asset pipeline log.
Control: reassign -1 wnpp Control: severity -1 wishlist Control: owner -1 aditibhat...@gmail.com On Lu, 21 sep 15, 19:18:00, aditi bhatt wrote: > package: wnppSeverity: wishlistOwner: 'Aditi Bhatt' > *Package Name : quiet_assets Version : 1.1.0 > Upstream Author : Dmitry KODer Karpunun / Evrone.com.*URL : > 'http://github.com/evrone/quiet_assets'*License : Expat*Description : > Turns off Rails asset pipeline log. -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
partial architectures -- was: Re: Defaulting to i686 for the Debian i386 architecture
2015-09-29 17:38 Wookey:
+++ Manuel A. Fernandez Montecelo [2015-09-29 12:27 +0100]:
Maybe it would be a good idea to split the architectures, and have one
port for legacy-but-still-sold-or-useful i386 and move the current i386
to only support newer, common-use i686 hardware.
It seems to me that this relates to a similar issue with armel, and
previous consideration of 'partial architectures' for mips (and arm).
[...]
Having a mechanism for 'partial architectures' to keep only the
relevant subset of the archive available for these machines seems like
a good plan, useful for at least i386 and armel, and probably
others. Because a debian arch refers to an ABI, not an ISA-variant,
you can't easily use our existing architectures mechanism to have both
'i386' and 'i686' without breaking some fairly fundamental assumptions.
Being able to have 'partial achitectures' which are actually different
baseline ISAs (586, 686) (armv6, armv7) for one ABI is something that
has been discussed many times, but no-one has ever cared enough to
actually implement it.
This is particularly relevant on mips, where inconsistent ISA changes
over the years mean that make picking one 'base ISA' is very
unsatisfactory, and they would like a way of having alternative ISA
(not ABI) builds of a significant set of packages (anthing where speed
actually matters, so libc, some core things and anything
codec-related, at least). (The rasbian port could have done things
this way and stayed within Debian for example, but it was easier to
derive).
Some details of a proposal for implemnting this are covered in section
2 of https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results
It would need fleshing out some more to actually be complete.
(These ideas could also be applied for packages compiled with special
characteristics, like optimised for multimedia instructions; or
compiled with address sanitiser, undefined behaviour sanitiser, etc --
somebody was talking about this in DebConf, I think that it was
Bálint).
Honest question, not a snarky one; but after reading your e-mail and the
proposal it is still not very clear to me what's the fundamental
underlying difference (or the advantage, in terms of which problems
solves better, and how) between a partial architecture, a full
architecture which possibly doesn't build a [large?] subset of packages
(there are mechanisms like "not-for-us" and "package-arch-specific",
which you probably know better than me), and an "overlay"-like
repository such as experimental or security-updates (although I am aware
that overlays don't get packages to build in the same way as arches, one
has to target them).
If I understand correctly what I read from partial arches, there has to
be a common baseline and baseline has to be the lowest common
denominator, in the case of i386/i686 (or armel/armhf), the baseline has
to be i386 or armel (so you can boot in the baseline, and then enable
the "flavour"/partial-arch more suited to your hardware). And since in
the example of Intel it is widely used and capable hardware, people
could want almost every package. If armel cannot cope with some
packages (e.g. 32-bit arches already having real trouble
compiling/linking some packages), the packages would be put in some
"not-for-us", or simply let to fail, as it probably happens already.
In that case, the amount of compiled packages would be about the same,
the storage about the same, etc. The only thing that we would reuse is
a small set of packages that allow users to start the machine and enable
the "flavour". I don't think that there would be much difference with
having two full architectures?
In the case that it works like an overlay-like repository
("jessie+i686", "jessie/i686" or whatever the convention), one could pin
this repository to take precedence and so install packages from it. It
doesn't work very well if one thinks of unstable/experimental (packages
not being available at the same time), but it does if you imagine using
multiarch already today with stable releases -- you have all packages
there on both arches at the same time. (Ubuntu PPAs and Debian
I-hesitate-to-call-Bikesheds are also supposed to work in this way).
If the amount of packages available is again "almost all", it doesn't
gain much over full ports in terms of CPU usage and storage.
In all cases, I assume that humanpower needed to tend the ports is about
the same.
So, in summary, I don't see these mechanisms as very different in terms
of resources compared to what I learn from partial architectures so far.
The main difference that I see among them is that full ports and overlay
repositories already work and don't need modification to existing
tools/practices; multiarch with compatible ports in the same machine and
overlay repositories and apt-pinning already work today. (Overlays are
probably a less elegant solution for this, but also potentially less
problematic on a day-to-day basis than multiarch -- only one versio
Re: Defaulting to i686 for the Debian i386 architecture
On 2015-09-28 22:14:44, Ben Hutchings wrote: > We propose to drop support for i386 processors older than 686-class in > the current release cycle. This would include folding libc6-i686 into > libc6, changing the default target for gcc, and changing the 586 kernel > flavour to 686 (non-PAE). > > Since the 686-class, introduced with the Pentium Pro, is now almost 20 > years old, we believe there are few Debian systems still running that > have 586-class or hybrid processors. Not true! My trusty soekris 5501 has an AMD Geode LX, which (AFAIK) is still only i586. It seems it is missing one instruction (NOPL) from being a full 686 chip :) Anyway, what I mean to say: thanks for finally motivating me to upgrade. This move definitely makes sense, but I wouldn't be so sure that there are no actual production systems running on a 586-only CPU. And thanks for your work! iustin signature.asc Description: Digital signature
Re: Defaulting to i686 for the Debian i386 architecture
On 29 September 2015 at 17:24, Josselin Mouette wrote: > > As of Knights Landing, it is based on Airmont Atom cores which indeed support > x86_64. > Correct. -- Regards, Dimitri.
Re: GitLab B.V. to host free-software GitLab for Debian project
On Tuesday 29 September 2015 02:07 AM, IOhannes m zmölnig (Debian/GNU) wrote: > On 09/28/2015 08:41 PM, Balasankar C wrote: >> Hi, >> >>> indeed, that status page got my very excited. >> Maintainer of that status page here. :) >>> >>> however, i wonder whether that page is actually getting the status >>> live or if somebody forgot to update it in the last few months... >> >> I just updated it with the latest master branch of GitLab and am >> running a cron job checking the package status of each gems. May I >> know why you feel that it isn't updated? Some new gems entered the >> list recently and that's why the percentage declined. > > that was just a gut feeling. > i haven't actually remembered how many packages were still missing last > time i checked, but it didn't seem to make any noteable progress in the > last 2 months or so. > i might be totally mistaken (but i didn't find a quick way to assess the > progress *speed*, so i asked here) You can follow my work here https://poddery.com/tags/debian-gitlab-months > thanks for the clarification. > > fgmrds > IOhannes > signature.asc Description: OpenPGP digital signature
