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
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
On Tue, 14 Jan 2014, Jakub Wilk wrote:
* Daniel Kahn Gillmor d...@fifthhorseman.net, 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
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 of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 14 Dec 2013 21:01:41 -0200
Source: iucode-tool
Binary: iucode-tool
Architecture: source amd64
Version: 1.0.1-1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed-By: Henrique de
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 pitfall.
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 to use - in the name,
the correct module name
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
This is broken. debhelper modules are not allowed to use
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 because of that -/_ mismatch.
Which I answered
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 commands thus
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
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
them
On Sun, 17 Nov 2013, Russ Allbery wrote:
Sune Vuorela nos...@vuorela.dk writes:
On 2013-11-16, Russ Allbery r...@debian.org 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
On Tue, 19 Nov 2013, Russ Allbery wrote:
Henrique de Moraes Holschuh h...@debian.org 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 point when I have
enough free
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 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 caching,
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 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 question
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
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
an
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
On Wed, 25 Sep 2013, Adam Borowski wrote:
On Wed, Sep 25, 2013 at 09:38:18AM -0700, Russ Allbery wrote:
Thorsten Glaser t...@mirbsd.de writes:
Russ Allbery rra at 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 21 Sep 2013 20:35:47 -0300
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 2.20130906.1
Distribution: unstable
Urgency: high
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
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 testers
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 07 Sep 2013 15:22:09 -0300
Source: amd64-microcode
Binary: amd64-microcode
Architecture: source amd64
Version: 2.20131007.1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 07 Sep 2013 22:22:00 -0300
Source: amd64-microcode
Binary: amd64-microcode
Architecture: source amd64
Version: 2.20131007.1+really20130710.1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h
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 as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 18 Aug 2013 16:19:42 -0300
Source: amd64-microcode
Binary: amd64-microcode
Architecture: source amd64
Version: 2.20120910-1
Distribution: unstable
Urgency: high
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 17 Aug 2013 10:56:45 -0300
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 2.20130808.1
Distribution: unstable
Urgency: high
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Fri, 16 Aug 2013 21:10:12 -0300
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 1.20130808.2
Distribution: unstable
Urgency: high
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 15 Aug 2013 20:18:32 -0300
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 1.20130808.1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 10 Aug 2013 09:23:55 -0300
Source: autotools-dev
Binary: autotools-dev
Architecture: source all
Version: 20130810.1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
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 that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 20 Jul 2013 10:46:59 -0300
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 1.20130222.6
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 20 Jul 2013 12:45:04 -0300
Source: amd64-microcode
Binary: amd64-microcode
Architecture: source amd64
Version: 1.20120910-3
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Wed, 03 Jul 2013 19:55:13 -0300
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 1.20130222.5
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Wed, 19 Jun 2013 22:15:46 -0300
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 1.20130222.3
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 20 Jun 2013 22:07:04 -0300
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 1.20130222.4
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
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.
2.
On Mon, 10 Jun 2013, Thomas Goirand wrote:
On 06/10/2013 03:21 AM, Michael Stapelberg wrote:
Thomas Goirand z...@debian.org 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*
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
packages that include a configuration script
On Sat, 01 Jun 2013, Jakub Wilk wrote:
* Henrique de Moraes Holschuh h...@hmh.eng.br, 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 may include
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 30 May 2013 20:28:51 -0300
Source: autotools-dev
Binary: autotools-dev
Architecture: source all
Version: 20130515.1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 25 May 2013 13:40:57 -0300
Source: iucode-tool
Binary: iucode-tool
Architecture: source amd64
Version: 1.0-1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed-By: Henrique de
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, you can get
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 updates
for Intel processors
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
On Sat, 20 Apr 2013, Eriberto wrote:
Os meus pacotes estão em
http://anonscm.debian.org/viewvc/debian-br-team/packages/. No entanto,
estou dando preferência ao Git ultimamente. Parece que a maioria está
preferindo ele.
A minha pergunta é: haveria a possibilidade de algum DD criar uma área
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 to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 28 Mar 2013 23:48:48 -0300
Source: iucode-tool
Binary: iucode-tool
Architecture: source amd64
Version: 0.9-1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed-By: Henrique de
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 03 Mar 2013 16:59:35 -0300
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 1.20130222.1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
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 kalnischk...@gmail.com [2013.01.25.0020
+1300]:
You can find much of the same discussion in the bugreport requesting
implementation of this feature in APT: #596097
On Thu, 03 Jan 2013, Alexey Eromenko wrote:
On Thu, Jan 3, 2013 at 8:05 PM, Didier 'OdyX' Raboud o...@debian.org 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
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 example
On Mon, 26 Nov 2012, Jakub Wilk wrote:
* Dmitrijs Ledkovs x...@debian.org, 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
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
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-only
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
henrich@hp:/tmp$ rm
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 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 dschep...@gmail.com 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
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 web application
Hi,
I cannot
. 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 arch.
The new wrinkle is that, because x32 uses the x86-64 instruction set,
it defines preprocessor
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 directories on tmpfs...
x32
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:
Yes, I know :) Our amavisd-box at work has 16GiB RAM
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. There's
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 further
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/Replaces combination way
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
failure to update microcode at package
On Thu, 08 Nov 2012, Christoph Egger wrote:
Peter Samuelson pe...@p12n.org 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?
On Wed, 07 Nov 2012, Nikolaus Rath wrote:
Henrique de Moraes Holschuh h...@debian.org writes:
# iucode_tool --scan-system -vv
iucode_tool: cpuid kernel driver unavailable, cannot scan system
processor signatures
Hmm, that should happen only if iucode-tool is installed/configured
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't
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
have to keep the packages installed
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 was recently added to [non
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
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
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 value
of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 09 Oct 2012 07:43:37 -0300
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 1.20120606.v2.2
Distribution: unstable
Urgency: medium
Maintainer: Henrique de Moraes Holschuh h...@debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 09 Oct 2012 08:18:01 -0300
Source: amd64-microcode
Binary: amd64-microcode
Architecture: source amd64
Version: 1.20120910-2
Distribution: unstable
Urgency: medium
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 08 Oct 2012 14:56:17 -0300
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 1.20120606.v2.1
Distribution: unstable
Urgency: medium
Maintainer: Henrique de Moraes Holschuh h...@debian.org
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 module because
Currently using microcode
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 add it to your system yourself
On Fri, 28 Sep 2012, Eric Valette wrote:
html
head
meta http-equiv=content-type content=text/html; charset=UTF-8
/head
body bgcolor=#CC text=#00
font size=-1Reading the thread about microcode, I wonder why
there is no more any /etc/init.d/microcode.ctl
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, Philipp
de Moraes Holschuh h...@debian.org
Description:
microcode.ctl - Intel IA32/IA64 CPU Microcode Utility (transitional package)
Closes: 687835
Changes:
microcode.ctl (1.18~0+nmu2) unstable; urgency=medium
.
* Non-maintainer upload.
* Add changelog entries for 1.17-13.2 and 1.17-13.1 (closes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Fri, 14 Sep 2012 15:39:37 -0300
Source: amd64-microcode
Binary: amd64-microcode
Architecture: source amd64
Version: 1.20120910-1
Distribution: unstable
Urgency: medium
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
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.
Could
On Thu, 13 Sep 2012, Nikolaus Rath wrote:
Henrique de Moraes Holschuh h...@debian.org 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 documentation?) that
non-free should
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 essential
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 should also happen
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.
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 a x86
arch (i386 or amd64
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 02 Sep 2012 17:46:39 -0300
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 1.20120606.6
Distribution: unstable
Urgency: medium
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 02 Sep 2012 16:14:26 -0300
Source: microcode.ctl
Binary: microcode.ctl
Architecture: source amd64
Version: 1.18~0+nmu1
Distribution: unstable
Urgency: low
Maintainer: Giacomo Catenazzi c...@debian.org
Changed-By: Henrique de
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 h...@debian.org wrote:
If 64-bit PC is too vague, the alternative designator
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 wants to
On Sun, 09 Sep 2012, Russell Coker wrote:
On Sat, 8 Sep 2012, Henrique de Moraes Holschuh h...@debian.org 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
i386, i486, i586, i686, amd64
301 - 400 of 1562 matches
Mail list logo
