On Mon, 14 Jul 2014, Kurt Roeckx wrote:
> On Mon, Jul 14, 2014 at 02:09:55PM -0300, Henrique de Moraes Holschuh wrote:
> > On Mon, 14 Jul 2014, Kurt Roeckx wrote:
> > > I plan to try and get them to use symbol versioning, at least on
> > > those platforms that support
On Mon, 14 Jul 2014, Kurt Roeckx wrote:
> I plan to try and get them to use symbol versioning, at least on
> those platforms that support it. This will probably be just like
Thank you.
> the patch currently in Debian. I don't plan to add multiple
> versions of a symbol to try and keep the same
On Sun, 13 Jul 2014, Juliusz Chroboczek wrote:
> > Meanwhile, we could try to get ever distro with a clue together, map the
> > versioned symbol diffs that already exist, and see if we can come up with a
> > plan to at least do downstream versioning in a compatible way.
>
> Please, please, please
On Sun, 13 Jul 2014, Matthias Urlichs wrote:
> I am, frankly, not at all concerned with binaries not compiled on Debian
> at this point. Data point: Fedora uses a different symbol versioning
> scheme for openssl, so openssl-linked binaries from there won't run on
> Debian anyway.
>
> It's far more
On Sun, 13 Jul 2014, Matthias Urlichs wrote:
> for that (i.e. make sure that _everything_ in libressl is only exported
> with properly versioned symbols), again IMHO the time and effort required
PLEASE PLEASE PLEASE PLEASE PLEASE take this to the portable libressl
upstream *and make it true* for
On Mon, 07 Jul 2014, Johannes Schauer wrote:
> MBF template email:
>
> --%<---
> Subject: Please consider removing the build dependencies on $foo, $bar and
> $baz
> Severity: wishlist
> Usertag: unusedbd
> User: bootst...@lis
On Wed, 18 Jun 2014, Thorsten Glaser wrote:
> Furthermore, with upstream *and* Debian maintainer hat on, I refuse to
> use a Debian-specific “special way” here. I will only fix this upstream
> (and there, there is no unicode-data package).
Make it generic, instead. You could just automatize the t
On Fri, 13 Jun 2014, Joey Hess wrote:
> Henrique de Moraes Holschuh wrote:
> > Now, the kernel can soft-blacklist RDRAND (and RDSEED) usage[2]. In that
> > case, the kernel won't use it and it disappears from /proc/cpuinfo, and we
> > could do that also to avoid process
On Wed, 11 Jun 2014, Joey Hess wrote:
> I don't have a stong opinion on the security of RDRAND, which is a
> contentious topic in a domain I am not expert in. However, I would much
> rather rely on linux developers to make the right decision on that,
> rather than libraries deciding on an ad-hoc ba
On Mon, 02 Jun 2014, Xavier Roche wrote:
> On Mon, Jun 02, 2014 at 10:36:01AM -0300, Henrique de Moraes Holschuh wrote:
> > As long as you have a way to regression-test. And I don't mean performance
> > regressions, either. Although issues with -O3 are rare, they&#
On Mon, 02 Jun 2014, Thomas Goirand wrote:
> On 06/02/2014 05:07 AM, Julien Cristau wrote:
> > For a lot of scientific packages, the upstream authors don't know what
> > they're doing. So I'm not sure that's much of an argument.
>
> [citation needed]
>
> Also, it's easy to just play with the -O o
On Sun, 01 Jun 2014, Tollef Fog Heen wrote:
> > FWIW, the recent port of Ubuntu to ppc64el uses -O3 as the default, because
> > IBM has broad experience in resolving performance issues for their own
> > hardware and have found that -O3 gives an overall better experience for
> > their customers. It
On Sat, 24 May 2014, Jakub Wilk wrote:
> * Marcio de Souza Olivera , 2014-05-23, 23:53:
> >* Package name: conv
>
> That's an awfully generic name...
Agreed. And for something rather limited.
> > Description : Simple ASCII,binary,decimal,hex converter
>
> How is it different/better tha
On Fri, 02 May 2014, Thorsten Glaser wrote:
> Henrique de Moraes Holschuh dixit:
> >On Wed, 30 Apr 2014, Pierre wrote:
> >> When /tmp is configured as noexec (for example /tmp in RAM), some
> >> scripts fail on package update.
>
> […]
> >It may look li
On Wed, 30 Apr 2014, Pierre wrote:
> When /tmp is configured as noexec (for example /tmp in RAM), some scripts
> fail on package update.
Don't Do It.
It will break the system in surprising ways.
It may look like it is working, but we don't properly support it, as it is
almost never tested. Neit
On Mon, 21 Apr 2014, Charles Plessy wrote:
> things are too slow or not happening is the lack of manpower. See for example
> the documentation of the Dpkg triggers: we miss only one single Debian
> Developer to review the discussion and the patch in #582109 (I even offered to
> go piece by piece,
On Thu, 10 Apr 2014, Shachar Shemesh wrote:
> I never did understand what people expect. gcc uses the undefined
Warn the hell out of any line of code with per-spec undefined behaviour, if
not by default, at least under -Wall.
THAT would be a good start. Too bad not even gcc knows every time it h
On Thu, 27 Mar 2014, Jakub Wilk wrote:
> * Mathieu Malaterre , 2014-03-27, 13:06:
> >I preferred not to mass bug everyone out there and instead:
> >
> >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742780
>
> But many packages don't regenerate autofoo at build-time. :-(
>
> >LFS is still a rel
On Wed, 05 Mar 2014, peter green wrote:
> Also ECDSA shares with DSA the serious disadvantage over RSA that
> making signatures on a system with a broken RNG can reveal the key.
I believe that we should avoid ECDSA gnupg keys and subkeys like the plague
for the time being.
You'd most likely get E
On Tue, 18 Feb 2014, Russ Allbery wrote:
> Henrique de Moraes Holschuh writes:
> > They *HAVE* to be provided by the active init system. They are an
> > impedance matching layer (aka stable API) used by maintainer scripts to
> > interface with the active init system.
&g
On Tue, 18 Feb 2014, Tollef Fog Heen wrote:
> > Once I consider OpenRC ready for it, would it be ok to just replace
> > sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
>
> No, update-rc.d and invoke-rc.d still need to be provided by something.
They *HAVE* to be provided by t
On Sat, 15 Feb 2014, Tollef Fog Heen wrote:
> ]] Henrique de Moraes Holschuh
> > Well, it is difficult to second-guess Shuttelworth, but the "tight coupling"
> > is likely to be part of it. This was a non-issue with sysvinit (for Debian)
> > and upstart (for Ub
On Fri, 14 Feb 2014, Noah Meyerhans wrote:
> I'm not sure I understand why. Debian and Ubuntu have been using
> different init systems for some time now, with Ubuntu on upstart and
> Debian on sysvinit. Why should our change of defaults really matter to
> them, when they weren't using our default a
On Sat, 15 Feb 2014, Philipp Kern wrote:
> That's why I was careful to publish the address nowhere. We do some
Unfortunately, that cat is out of the bag, now. Whether it will get spammed
or attacked, I don't know.
However, it is not like we ever could trust the logs anyway for any security
purpo
On Thu, 30 Jan 2014, Roberto C. Sánchez wrote:
> That said, I am curious if there would be any opposition to an upload of
> cyrus-sasl2 2.1.26 into unstable. Aside from opposition, are there any
> other comments that anyone would like to offer in regard to this?
Well, it has to go to unstable eve
On Thu, 23 Jan 2014, Zlatan Todoric wrote:
> Can now be a reason for becoming a DD - I want to get free Valve games? :)
Well, a lot of time ago we had to make sure people wanted to be a DD for a
reason other than the @debian.org email address...
I don't see how dealing with people who just want V
On Tue, 14 Jan 2014, Jakub Wilk wrote:
> * Daniel Kahn Gillmor , 2014-01-13, 23:03:
> >if the only axis we're measuring along is cryptographic security,
> >then protecting against passive attackers (eavesdroppers) is
> >clearly better than not doing so.
> >
> >but if people think that CUPS' TLS pro
On Fri, 03 Jan 2014, Roger Leigh wrote:
> If file-rc and/or the maintainer scripts somehow restored the links
> incorrectly, then insserv will ignore the header and preserve your
> customisations (not the link ordering, but the runlevels to start
> and stop in). This would certainly be the cause o
On Tue, 24 Dec 2013, Joey Hess wrote:
> Henrique de Moraes Holschuh wrote:
> > Hmm? That's interesting, given that bug report I was cc'd (and which I later
> > cc'd you asking about the -/_ thing) complaining that dh-autotools-dev-foo
> > was not working becaus
On Tue, 24 Dec 2013, Julien Cristau wrote:
> On Tue, Dec 24, 2013 at 15:15:13 -0200, Henrique de Moraes Holschuh wrote:
> > On Tue, 24 Dec 2013, Wookey wrote:
> > > 2) for dh packages:
> > > adding --with autotools-dev to the dh invocation
> >
> > Thi
On Tue, 24 Dec 2013, Joey Hess wrote:
> Henrique de Moraes Holschuh wrote:
> > On Tue, 24 Dec 2013, Wookey wrote:
> > > 2) for dh packages:
> > > adding --with autotools-dev to the dh invocation
> >
> > This is broken. debhelper modules are not allowed
On Tue, 24 Dec 2013, Wookey wrote:
> 2) for dh packages:
> adding --with autotools-dev to the dh invocation
This is broken. debhelper modules are not allowed to use "-" in the name,
the correct module name is "autotools_dev" as stated in the documentation.
Yeah, this is annoying, and a large pit
On Wed, 18 Dec 2013, Ian Jackson wrote:
> Bas Wijnen writes ("Re: Need some guide with LSB core"):
> > On Sat, Dec 14, 2013 at 08:27:45PM +0530, V.Krishn wrote:
> > > Conforming scripts shall not specify the "exit on error" option (i.e.
> > > set -e) when sourcing this file, or calling any of the c
On Sun, 24 Nov 2013, Thomas Goirand wrote:
> I haven't checked for these facts myself due to lack of time, which is
> why I just post here. I think this paper is interesting anyway, and
> worth sharing.
I read that paper sometime ago, and as far as I recall, it mostly deals with
C code that has un
On Fri, 22 Nov 2013, Russ Allbery wrote:
> positions complete. The only ones we haven't heard from are the sysvinit
> and OpenRC position statement maintainers.
Hmm, sysvinit as in "init" or as in "sysv-rc + insserv" ?
--
"One disk to rule them all, One disk to find them. One disk to bring
On Tue, 19 Nov 2013, Russ Allbery wrote:
> Henrique de Moraes Holschuh writes:
> > On Sun, 17 Nov 2013, Russ Allbery wrote:
>
> >> Yeah, I know, which is part of why I used it for an example. I looked
> >> at it yesterday and will probably adopt it at some poin
On Sun, 17 Nov 2013, Russ Allbery wrote:
> Sune Vuorela writes:
> > On 2013-11-16, Russ Allbery wrote:
> >> If someone proposed to remove nvi from the archive because vim is
> >> better, I would be quite annoyed. If it ever did get removed from the
> >> archive, I would probably adopt it and rei
On Tue, 22 Oct 2013, Russ Allbery wrote:
> > I would suggest: caching-name-server
>
> That's basically what a recursive-name-server is. I don't think the
> application should care whether it caches locally or not; that's up to the
> local administrator.
Almost every recursive resolver does cachi
On Tue, 22 Oct 2013, Ondřej Surý wrote:
> Also thanks for the *.maintscript, I have missed that the dh_installdeb
> can use it.
Yeah, it is pretty cool!
What I can't find is the information of the required versioned
build-dependency on debhelper itself (or debhelper compatibility level) to
ensure
On Sat, 19 Oct 2013, peter green wrote:
> If a release architecture is getting behind on building on a long
> term basis then IMO either more buildd hardware should be obtained
> or the port should lose it's release status.
>
> But that isn't what we are talking about here, we are talking about
>
On Fri, 18 Oct 2013, Thorsten Glaser wrote:
> One thing I think we *can* do is to have debports wanna-build lower the
> build priorities of some sections below what we currently have as “all
> others”, which would mean that e.g. bioinformatics would still be built
> but only after the rest (both ou
On Fri, 18 Oct 2013, Thorsten Glaser wrote:
> On Tue, 15 Oct 2013, Thijs Kinkhorst wrote:
> > I'm still not sure why the virus contained in the source could not be
> > replaced by the EICAR test signature.
>
> Because it’s not testing a virus scanner, but because the
> specific RFC822 message in q
On Fri, 18 Oct 2013, Guillem Jover wrote:
> For example on one of my 64-bit systems, with 220481 paths installed, I
> go from 62.8 MiB to 46.1 MiB max resident memory, a saving of 16.7 MiB.
> That should compensate a bit for the slight increase in memory usage
> from xz.
This is great, thank you!
On Tue, 08 Oct 2013, Geoffrey Thomas wrote:
> Would this be addressed by building some mechanism (making tombstone
> packages comes to mind, but there are many options) for apt to
> prompt to remove packages that were removed in the archive?
It is already addressed by the user-oriented package man
On Wed, 25 Sep 2013, Adam Borowski wrote:
> On Wed, Sep 25, 2013 at 09:38:18AM -0700, Russ Allbery wrote:
> > Thorsten Glaser writes:
> > > Russ Allbery debian.org> writes:
> > Programs that don't check the return status of functions that they think
> > won't ever fail are a bit of a pet peeve of
On Fri, 20 Sep 2013, Daniel Pocock wrote:
> On 20/09/13 22:09, Bastian Blank wrote:
> > I would call code that hits such clear definitions too buggy to be
> > supported.
>
> and what if many more existing packages are found to have similar issues?
IMHO: fix everything gcc, llvm and the static tes
On Fri, 20 Sep 2013, Faheem Mitha wrote:
> So, I suppose anyone using the software needs to download it. I'll
> provide a script to download the data, but if I want to build a
> Debian package containing that data, how should I do it?
Maybe studying other download-and-package packages, like "java-
On Fri, 23 Aug 2013, John Paul Adrian Glaubitz wrote:
> No, it's not. It's the only reasonable thing to do. Nothing is safer
> than a daemon which is *not* running. The fewer services are running,
A daemon which is not running but which can be made to run by an
unpriviledged connect() is as good a
On Sat, 03 Aug 2013, Ondřej Surý wrote:
> [IANACryptoguy] As far as I understand the MD5 attacks the length doesn't
> matter. You just need to pick the package big enough to hold your evil
> content and the "filling" which you use to compute the same MD5 (e.g.
> collision vulnerability). I think th
On Sun, 14 Jul 2013, Russ Allbery wrote:
> I've been administering UNIX systems professionally for 20 years, from
> SunOS and ULTRIX through AIX, HP-UX, IRIX, Solaris, and Linux. In my
> professional, *experienced* opinion, proper deployment of a modern init
> system will make Debian considerably
On Wed, 12 Jun 2013, Wouter Verhelst wrote:
> On 10-06-13 18:36, Ian Jackson wrote:
> > B. resolv.conf is not static and may change due to network
> >environment changes.
> > Implications:
> > 1. All existing DNS applications must be modified to notice
> >changes to resolv.conf.
On Mon, 10 Jun 2013, Thomas Goirand wrote:
> On 06/10/2013 03:21 AM, Michael Stapelberg wrote:
> > Thomas Goirand writes:
> >> In this blog post, you tell that it's possible not to use all the
> >> components of systemd. Then, the immediate question that pops to my
> >> mind: what are *your* inten
On Sat, 01 Jun 2013, Jakub Wilk wrote:
> * Henrique de Moraes Holschuh , 2013-05-31, 18:44:
> >As a special exception to the GNU General Public License, if you
> >distribute this file as part of a program that contains a
> >configuration script generated by Autoconf, you ma
On Fri, 31 May 2013, Josh Triplett wrote:
> On Fri, May 31, 2013 at 06:44:00PM -0300, Henrique de Moraes Holschuh wrote:
> > Upstream has changed the license to GPLv3. It has an additional
> > permission to negate any "viral effects", but it only applies to
&g
On Thu, 09 May 2013, Steve McIntyre wrote:
> In article <518b7cf6.3080...@debian.org> you write:
> >On 09/05/13 07:38, Raphael Hertzog wrote:
> >> bikeshed \o/
> >
> >You probably meant this to be a comment on the discussion rather than a
> >suggested name, but "until it gets uploaded to unstable,
On Tue, 23 Apr 2013, Julien Cristau wrote:
> On Mon, Apr 22, 2013 at 19:23:50 -0300, Henrique de Moraes Holschuh wrote:
> > As of Linux kernel 3.9, support for supplying early firmware data to the
> > kernel has been added. Currently, it is used for early microcode update
As of Linux kernel 3.9, support for supplying early firmware data to the
kernel has been added. Currently, it is used for early microcode updates
for Intel processors, and ACPI table overrides.
This is a very important feature, that we should support as soon as
practical. ACPI table overrides ca
On Sun, 07 Apr 2013, Ben Hutchings wrote:
> So it seems that this is only going to be an issue if users take the
> unusual step of changing /etc/fstab to refer to LVs by UUID. But maybe
> there are management tools that do that as a matter of course?
One should never use UUIDs in fstab to refer t
On Thu, 28 Feb 2013, Holger Levsen wrote:
> signed commits, so you can identify unwanted bits and clean up in the very
> care case that's actually needed?
Indeed. Secure git workflows are possible, although it is a relatively new
development. Signed commits and pull requests are a very big part
On Fri, 25 Jan 2013, Wookey wrote:
> +++ martin f krafft [2013-01-25 16:06 +1300]:
> > also sprach David Kalnischkies [2013.01.25.0020
> > +1300]:
> > > You can find much of the same discussion in the bugreport requesting
> > > implementation of this feature in APT: #596097
> >
> > Thanks for th
On Thu, 03 Jan 2013, Alexey Eromenko wrote:
> On Thu, Jan 3, 2013 at 8:05 PM, Didier 'OdyX' Raboud wrote:
> >
> > release and lsb-base being Architecture: foreign). Patches are welcome to
> > make
> > Wheezy+1 more suitable to your needs.
>
> How about changing it from a kernel bug to tasksel fe
On Mon, 26 Nov 2012, Jakub Wilk wrote:
> * Dmitrijs Ledkovs , 2012-11-26, 00:19:
> >If your e-mail processing machinery cannot handle duplicate
> >messages (due to cross-postings and CC's), maybe you should get an
> >a better email processing machinery. Receiving duplicate emails is
> >inevitable,
On Sun, 25 Nov 2012, John Paul Adrian Glaubitz wrote:
> On Sun, Nov 25, 2012 at 10:48:27PM +1300, Chris Bannister wrote:
> > https://lists.linuxaudio.org/mailarchive/lau/2012/11/21/194431
> >
> > There is a rather bad smell regarding all this.
>
> None of the systemd advocates ever mentioned for
On Sat, 24 Nov 2012, Christoph Anton Mitterer wrote:
> This however leads to irrecoverable data corruption, as the partial
> quoting of so called From_ lines cannot be undone anymore.
> An easy solution for that dilemma is known for years, namely the other
> mbox formats (either mboxrd, mboxcl or m
On Tue, 20 Nov 2012, Dmitrijs Ledkovs wrote:
> I am sorry, if I was not clear. I am aware of the "last iteration",
> but I am not enquiring about the default policy within debian as to
> how we should upload by default.
> I am asking why, when I had a reason to do so, was not able to do a
> source-
On Thu, 15 Nov 2012, Peter Samuelson wrote:
> [Hideki Yamane]
> > > henrich@hp:/tmp$ du -k Packages.*
> > > 6052 Packages.bz2
> > > 5812 Packages.xz
> > > henrich@hp:/tmp$ time bzip2 -d Packages.bz2
> > >
> > > real 0m0.999s
> > > user 0m0.956s
> > > sys 0m0.020s
> > >
On Thu, 15 Nov 2012, Guillem Jover wrote:
> On Thu, 2012-11-15 at 17:11:02 +0100, David Kalnischkies wrote:
> > 0.8.10.3+squeeze1 does as its changelog tells us.
> > Note through that it needs the 'xz' binary for that (as it did for bzip2,
> > that changed just yet with the usage of libbz2 now for
On Sun, 11 Nov 2012, Adam Borowski wrote:
> On Sat, Nov 10, 2012 at 08:30:06PM +, Wookey wrote:
> > +++ Steve McIntyre [2012-11-10 18:28 +]:
> > > *If* we want to include x32, it's worth describing it and
> > > understanding the potential benefits properly and getting some
> > > benchmarks.
On Sun, 11 Nov 2012, Ben Hutchings wrote:
> On Sat, 2012-11-10 at 20:14 -0200, Henrique de Moraes Holschuh wrote:
> > On Sat, 10 Nov 2012, Bastian Blank wrote:
> > > On Sat, Nov 10, 2012 at 02:15:14PM -0200, Henrique de Moraes Holschuh
> > > wrote:
> > > >
On Sat, 10 Nov 2012, Bastian Blank wrote:
> On Sat, Nov 10, 2012 at 02:15:14PM -0200, Henrique de Moraes Holschuh wrote:
> > Yes, I know :) Our amavisd-box at work has 16GiB RAM and 16 cores,
> > we need at least that much to be able to run 64 instances with the
> > scratch
quot;
> > > is somewhat suspicious. This is the main reason one may want to oppose
> > > the inclusion of x32 in Debian, IMHO.
>
> [Andrey Rahmatullin]
> > Can you elaborate?
>
> [Henrique de Moraes Holschuh]
> > This is no worse than any other new arc
On Sat, 10 Nov 2012, Thomas Goirand wrote:
> On 11/10/2012 08:15 PM, Henrique de Moraes Holschuh wrote:
> > 3) Memory usage of some common server workload. E.g. email with
> > amavisd-new+spamassassin (perl is a memory pig in amd64), or a LAMP stack
> > with some common
On Sat, 10 Nov 2012, Adam Borowski wrote:
> On Fri, Nov 09, 2012 at 11:27:20PM +0100, Marco d'Itri wrote:
> > On Nov 09, Daniel Schepler wrote:
> > > I've asked a couple people in private mail about this, and haven't
> > > gotten any answer, so I thought I'd ask here for ideas. Where would
> > >
Hi Josselin!
On Fri, 09 Nov 2012, Henrique de Moraes Holschuh wrote:
> On Fri, 09 Nov 2012, Josselin Mouette wrote:
> > It looks to me that we should strictly favor the transitional package
> > approach instead. Shouldn’t we entirely forbid the
> > Provides/Conflicts/Replac
On Fri, 09 Nov 2012, Josselin Mouette wrote:
> It looks to me that we should strictly favor the transitional package
> approach instead. Shouldn’t we entirely forbid the
> Provides/Conflicts/Replaces combination way of handling upgrades, except
> for virtual packages?
And instantly break even furt
On Thu, 08 Nov 2012, Christoph Egger wrote:
> Peter Samuelson writes:
> > ...But it does bring up the question of why intel-microcode and
> > amd64-microcode are not built on kFreeBSD or the Hurd. Maybe those
> > kernels lack a CPU microcode interface?
>
> http://www.freebsd.org/doc/faq/compatib
On Thu, 08 Nov 2012, Carlos Alberto Lopez Perez wrote:
> On 06/11/12 17:05, Henrique de Moraes Holschuh wrote:
> > Still, it did lead me to a possible cause: I am not trying to modprobe
> > "microcode" in the intel-microcode postinst. This can indeed cause the
> >
On Wed, 07 Nov 2012, Adrian Fita wrote:
> Fair enough, but how about having the linux-image packages recommend the
> *microcode packages for installation so users won't get confused by the
> message caused by the module trying to load the file with the microcode
> update and not finding it?
I don'
On Wed, 07 Nov 2012, Nikolaus Rath wrote:
> Henrique de Moraes Holschuh writes:
> >> > # iucode_tool --scan-system -vv
> >> > iucode_tool: cpuid kernel driver unavailable, cannot scan system
> >> > processor signatures
> >
> > Hmm, that should
On Wed, 07 Nov 2012, Adrian Fita wrote:
> My CPU is an AMD Turion(tm)X2 Dual Core Mobile RM-76, cpu family: 17, so
> it doesn't need the amd64-microcode package which contains microcode
> updates only for cpu families: 10h - 14h & 15h. But the microcode kernel
Family 17 (decimal) is family 11h (he
On Tue, 06 Nov 2012, Stephan Seitz wrote:
> On Mon, Nov 05, 2012 at 06:12:53PM -0200, Henrique de Moraes Holschuh wrote:
> >I would like to bring to your attention the improved support for system
> >processor (CPU) microcode updates, for x86/i686/x86-64/amd64 systems
> >that
On Tue, 06 Nov 2012, Jon Dowland wrote:
> On Mon, Nov 05, 2012 at 06:12:53PM -0200, Henrique de Moraes Holschuh wrote:
> > Microcode updates will be applied immediately when the microcode
> > packages are installed or updated: you don't have to reboot. You will
> >
Hello all,
I would like to bring to your attention the improved support for system
processor (CPU) microcode updates, for x86/i686/x86-64/amd64 systems
that was recently added to [non-free] Wheezy.
System Processors from Intel and AMD may need updates to their microcode
(sort of a control sequenc
On Thu, 18 Oct 2012, Arno Töll wrote:
> On 18.10.2012 04:29, Paul Wise wrote:
> > On Thu, Oct 18, 2012 at 10:20 AM, Russell Coker wrote:
> >> We could have a lintian warning for any occurance of the string "/home" in
> >> a
> >> packaged file and have error conditions for "/build" and the current
On Sat, 29 Sep 2012, Eric Valette wrote:
> On 29/09/2012 12:32, Henrique de Moraes Holschuh wrote:
> >If you want to use non-modular, built-in microcode, the documentation of
> >iucode-tool does explain how to trigger the microcode reload after boot. You
> >will have to
On Sat, 29 Sep 2012, Eric Valette wrote:
> On 29/09/2012 03:46, Henrique de Moraes Holschuh wrote:
> >1. No html, please.
> >
> >non-initrd is supported. Read the package documentation for the details.
>
> I did. I do not want to compile microcode tool as a modu
On Fri, 28 Sep 2012, Eric Valette wrote:
>
>
>
>
>
>
> Reading the thread about microcode, I wonder why
> there is no more any /etc/init.d/microcode.ctl equivalent for
> people like building their own kernel without initrd.
>
> -- eric
>
>
>
On Thu, 13 Sep 2012, Henrique de Moraes Holschuh wrote:
> On Mon, 10 Sep 2012, Jonathan Nieder wrote:
> > (replying to -devel and -boot only)
> (I am not subscribed to -boot. Please keep -devel on replies, or CC me
> directly).
>
> > Henrique de Moraes Holschuh wrote:
&
On Mon, 10 Sep 2012, Jonathan Nieder wrote:
> (replying to -devel and -boot only)
(I am not subscribed to -boot. Please keep -devel on replies, or CC me
directly).
> Henrique de Moraes Holschuh wrote:
> > On Mon, 10 Sep 2012, Philipp Kern wrote:
> >> If we do that the same s
On Thu, 13 Sep 2012, Andrei POPESCU wrote:
> On Jo, 13 sep 12, 11:29:39, Nikolaus Rath wrote:
> > I think this should be mentioned somewhere *much* more prominent. I
> > consider myself pretty tech-savy, but only stumbled upon this just now
> > on the this list. Can a non-free package be made essen
On Thu, 13 Sep 2012, Nikolaus Rath wrote:
> Henrique de Moraes Holschuh writes:
> > On Thu, 13 Sep 2012, Wolodja Wentland wrote:
> >> On Mon, Sep 10, 2012 at 11:44 +0200, Marco d'Itri wrote:
> >> > Also, we should mention somewhere (the install documentatio
On Thu, 13 Sep 2012, Wolodja Wentland wrote:
> On Mon, Sep 10, 2012 at 11:44 +0200, Marco d'Itri wrote:
> > Also, we should mention somewhere (the install documentation?) that
> > non-free should be enabled to install microcode fixes which may be
> > critical to maintain the system stability.
>
I am forwarding this as a remider that, should we ever get to the point of
moving around /lib or /usr/lib, /sbin or /usr/sbin, and /bin or /usr/sbin,
as well as any other such trunks, we really ought to consider whether we
should be using symlinks or bind mounts [where possible] for such moves.
Al
On Tue, 11 Sep 2012, Thomas Goirand wrote:
> On 09/10/2012 09:44 PM, Osamu Aoki wrote:
> >Why make things more complicated. What is the rationale to pick
> >i686 over others now. Why change to x86-64 which is AMD origin. If
> >slashed to listing are list of vender released names, it should be
> >(A
On Mon, 10 Sep 2012, Philipp Kern wrote:
> On Sun, Sep 09, 2012 at 08:38:38PM -0300, Henrique de Moraes Holschuh wrote:
> > I'd like to see it recommend the instalation of (or just install by default)
> > system processor microcode update packages when non-free is enabled on
On Mon, 10 Sep 2012, Cyril Brulebois wrote:
> Features expected to be merged:
> - UEFI support (Steve). Before anyone asks, and as far as I can tell:
>it's not about supporting secure boot.
> - IPv6 support in d-i (Philipp).
> - Possibly more xz-related unblocks (Ansgar).
>
> If anybody wan
On Sun, 09 Sep 2012, Ben Hutchings wrote:
> On Sat, 2012-09-08 at 22:46 -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 09 Sep 2012, Russell Coker wrote:
> > > On Sat, 8 Sep 2012, Henrique de Moraes Holschuh wrote:
> > > > If "64-bit PC" is too v
On Sun, 09 Sep 2012, Russell Coker wrote:
> On Sat, 8 Sep 2012, Henrique de Moraes Holschuh wrote:
> > If "64-bit PC" is too vague, the alternative designator for the amd64 arch
> > is the vendor neutral "x86-64". The vendor-neutral designator for all of
> &
On Fri, 07 Sep 2012, Lisandro Damián Nicanor Pérez Meyer wrote:
> On Fri 07 Sep 2012 21:45:54 Russ Allbery escribió:
> > Lisandro Damián Nicanor Pérez Meyer writes:
> > > If you go for changing the name, kerberos-wallet or krb-wallet seems
> > > quite right.
> >
> > It's a reasonable idea for the
On Fri, 07 Sep 2012, Francesca Ciceri wrote:
> On Wed, Sep 05, 2012 at 07:17:52PM +0100, Ben Hutchings wrote:
> > I've previously requested that various user-facing references to
> > 'i386' and 'amd64' should be changed to the hopefully more
> > understandable '32-bit PC' and '64-bit PC', with some
201 - 300 of 1206 matches
Mail list logo
