On Fri, 21 Nov 2014, Vincent Bernat wrote:
❦ 21 novembre 2014 17:34 -0200, Henrique de Moraes Holschuh
h...@debian.org :
I thought there was a flag bit you could set on x86 that causes
unaligned access to trap there too.
1. CR0.AM must be set.
2. Ask For The Pain!
i386
On Tue, 18 Nov 2014, Daniel Pocock wrote:
How would people feel if dput was a wrapper around git?
dpkg --purge dput
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon
On Tue, 18 Nov 2014, Matthias Urlichs wrote:
trying to convert minidlna sysv init file to systemd, managed to have
a working unit file but failed to split the configuration mimicing
the ../default/minidlna content with the hability to make USER and
GROUP configurable.
On Mon, 17 Nov 2014, Ron wrote:
Anything that doesn't store the full debian version (be it a git tag or a
filename) will have a colision risk. Consider a package that has versions
1:2.3.5-1 and 5:2.3.5-1.
Right, that was one of the first cases I mentioned. When you upload
5:2.3.5-1,
On Mon, 17 Nov 2014, Anthony Towns wrote:
Having a single tool that does the basic stuff admins and maintainers need
independent of init system seems like the right approach to me. *-rc.d
is a terrible name for such a tool, though :(
Err, yes. There were complains about the -rc.d prefix way
On Mon, 17 Nov 2014, Anthony Towns wrote:
If deb-systemd-* were to get merged in, it might be worth doing a name
change at the same time, I guess. Changing either before jessie doesn't
seem remotely plausible.
I wonder if it would make sense to just merge it all into the service
command;
On Mon, 17 Nov 2014, Anthony Towns wrote:
On Mon, Nov 17, 2014 at 02:38:04PM -0200, Henrique de Moraes Holschuh wrote:
On Mon, 17 Nov 2014, Anthony Towns wrote:
If deb-systemd-* were to get merged in, it might be worth doing a name
change at the same time, I guess. Changing either before
On Mon, 17 Nov 2014, Anthony Towns wrote:
On Mon, Nov 17, 2014 at 09:22:39AM -0800, Russ Allbery wrote:
Anthony Towns a...@erisian.com.au writes:
BTW, it occured to me that it seems like a wart that update-rc.d doesn't
respect policy-rc.d -- as it stands, policy-rc.d can prevent a service
On Mon, 17 Nov 2014, Russ Allbery wrote:
Henrique de Moraes Holschuh h...@debian.org writes:
I think I heard of someone using them *once*. It is very rare, AFAIK.
However, if there is one thing I learned the hard way, is that people
who use the advanced features don't make themselves
On Sun, 16 Nov 2014, Ron wrote:
On Sat, Nov 15, 2014 at 03:49:56PM -0200, Henrique de Moraes Holschuh wrote:
On Sat, 15 Nov 2014, Raphael Hertzog wrote:
On Fri, 14 Nov 2014, Ian Jackson wrote:
What exactly is your use case you feel this is essential for?
I think this discussion
On Sun, 16 Nov 2014, Nikolaus Rath wrote:
Ignoring block request by freeze, due to unblock request by adsb
I'm a little confused by that. What is adsb? Do we have some mechanism
finger a...@db.debian.org :-)
that automatically unblocks packages? Or is this just the release team
monitoring
On Sat, 15 Nov 2014, Raphael Hertzog wrote:
On Fri, 14 Nov 2014, Ian Jackson wrote:
What exactly is your use case you feel this is essential for?
I think this discussion is in danger of going round in circles.
I'm going to leave it here and let Raphael get on with it.
I understand
On Sat, 15 Nov 2014, Ron wrote:
On Fri, Nov 14, 2014 at 03:39:05PM +, Ian Jackson wrote:
Ron writes (Re: RFC: DEP-14: Recommended layout for Git packaging
repositories):
Why include the epoch in tags at all?
Because we want to be able to tell not just which tag was which but
On Fri, 14 Nov 2014, Richard Hartmann wrote:
On Fri, Nov 14, 2014 at 11:56 AM, Raphael Hertzog hert...@debian.org wrote:
On Thu, 13 Nov 2014, Tobias Frost wrote:
One point came to my mind: NMUs
Can we maybe add some words what would be best practice to handle NMUs?
I think the current
Senhores(as),
Estamos organizando um encontro rápido em São Paulo para troca de
assinaturas de chaves gnupg. DDs que precisam de assinaturas em suas
novas chaves estão *especialmente* convidados :-)
O encontro será na hora do almoço, nas proximidades dos Shoppings
Morumbi e Market Place, em um
On Wed, 12 Nov 2014, Raphael Hertzog wrote:
On Tue, 11 Nov 2014, Henrique de Moraes Holschuh wrote:
In fact, I was quite non-amused by the initial versions of this idea, but
reading this latest version, I must say I *like* it. Well done! I am
especially happy about the way it respects
On Tue, 11 Nov 2014, Rogério Brito wrote:
On 2014-11-11 15:30, Henrique de Moraes Holschuh wrote:
However, candidate packages due to reason (c) above really are a problem,
IMHO they shouldn't be in stable in the first place.
Does this mean that I should ask for the removal of youtube-dl
On Wed, 12 Nov 2014, Daniel Pocock wrote:
It is very sad to see that contributors sometimes feel that the only
option for them is to resign.
Would it be worthwhile giving people another option, for example,
allowing a percentage of DDs to formally veto decisions? Would this be
better than
On Tue, 11 Nov 2014, Rebecca N. Palmer wrote:
Possible candidates:
a. Packages that work closely with hardware, where old versions
don't work with new hardware (example: beignet)
b. Packages that implement fast-evolving file formats or network
protocols, where you need the same version as the
On Tue, 11 Nov 2014, Ian Jackson wrote:
Simon McVittie writes (Re: r-base-core upload to unstable does not respect
freeze policy):
On 11/11/14 15:55, Ian Jackson wrote:
perhaps we should in general make more use of testing chroots for RC
bugfixes to testing during the freeze.
For
On Tue, 11 Nov 2014, Daniel Pocock wrote:
On 11/11/14 18:30, Henrique de Moraes Holschuh wrote:
On Tue, 11 Nov 2014, Rebecca N. Palmer wrote:
Possible candidates:
a. Packages that work closely with hardware, where old versions
don't work with new hardware (example: beignet)
b. Packages
On Tue, 11 Nov 2014, Luca Falavigna wrote:
2014-11-11 19:12 GMT+01:00 Andreas Tille andr...@an3as.eu:
Depends: libc6 (= 2.4), r-base-core (= 3.1.2-2)
Hmmm, this is what I missed. :-( I guess the only chance is to upload
to t-p-u, right?
That could be an option. You have to coordinate
On Tue, 11 Nov 2014, Raphael Hertzog wrote:
following the initial discussion we had in August
(https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have
written a first draft of the Debian Enhancement Proposal that I suggested.
It's now online at http://dep.debian.net/deps/dep14
On Tue, 11 Nov 2014, Iustin Pop wrote:
QUESTION: some people have argued to use debian/master as the latest
packaging targets sometimes sid and sometimes experimental. Should we
standardize on this? Or should we explicitly allow this as an alternative?
Interesting. Assuming a normal
On Wed, 29 Oct 2014, Jonas Smedegaard wrote:
Speaking of which: Is it Policy or just habit to use GCC over Clang?
gcc still generates better machine code than clang in the *general* case for
C source (I don't know about the rest). There is no policy to use gcc: if
your program builds better
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 28 Oct 2014 17:02:42 -0200
Source: iucode-tool
Binary: iucode-tool
Architecture: source amd64
Version: 1.1.1-1
Distribution: unstable
Urgency: medium
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed-By: Henrique
On Sun, 26 Oct 2014, Santiago Vila wrote:
So, dpkg-maintscripthelper seems to do Removing obsolete conffile
after dpkg tries to delete old directories, so dpkg fails.
I'd be surprised if I were the first to encounter this problem: what is
the appropriate and clean way to get rid of
On Sun, 26 Oct 2014, Pau Garcia i Quiles wrote:
Do you want to enable an external repository which will provide you with
the latest version of Wt?
That behaviour is discouraged in Debian.
We don't mind if you offer the PPAs, but the official packages should
*NEVER* enable PPAs or offer to do
On Sun, 26 Oct 2014, Jakub Wilk wrote:
* Henrique de Moraes Holschuh h...@debian.org, 2014-10-26, 10:57:
rmdir /etc/foo/bar/ /dev/null 21 || true is always a safe
operation...
Instead of ignoring (and hiding) all errors, it's better use
--ignore-fail-on-non-empty.
That's a GNU coreutils
On Wed, 22 Oct 2014, Thorsten Glaser wrote:
Jelmer Vernooij dixit:
Samba is unlikely to add such an exception.
So just make OpenSSL a system library finally.
It has always been a system library in Debian.
The problem is that Debian is the operating system distributing the system
libraries,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 19 Oct 2014 15:23:13 -0200
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 3.20140913.1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
On Mon, 13 Oct 2014, Matthias Urlichs wrote:
In any case, users _do_ have a say. They can force their systems to remain
on sys5 init, or switch to a different distro if that should also turn out
Which, I should add, is something we measure if the user installs
popularity-contest and opts-in to
On Mon, 13 Oct 2014, Miles Fidelman wrote:
Henrique de Moraes Holschuh wrote:
On Mon, 13 Oct 2014, Matthias Urlichs wrote:
In any case, users _do_ have a say. They can force their systems to remain
on sys5 init, or switch to a different distro if that should also turn out
Which, I should add
On Fri, 10 Oct 2014, Don Armstrong wrote:
We probably should be just using sane security to score the messages
instead of outright rejecting them... but the war on spam is hard.
Speaking as someone that was the postmaster of several sites that used the
Sanesecurity database for years. There is
On Wed, 08 Oct 2014, Paul Gevers wrote:
Thanks for the careful response. And no, as mentioned above, I didn't
mean to use dpkg-statoverride itself. dbconfig-common uses debconf and
ufc to manage the configuration files. However, dbconfig-common checks
with dpkg-statoverride if the
On Tue, 07 Oct 2014, Paul Gevers wrote:
I am trying to come up with a patch against dpkg-statoverride that sets
the ownership and permissions upon creation, but not upon updates.
This really doesn't look like a good idea. In fact, it may well introduce
very confusing and likely dangerous
On Fri, 03 Oct 2014, Russell Stuart wrote:
On Fri, 2014-10-03 at 00:04 +, brian m. carlson wrote:
The shell you're describing is posh. It implements exactly those
features, and nothing more.
You've got me to look at posh. Thanks for that.
So we do have a shell that developers can
On Tue, 30 Sep 2014, Thorsten Glaser wrote:
On Fri, 26 Sep 2014, Matthias Urlichs wrote:
In any case, adding -p to any #!/bin/bash shebang line looks like a very
good idea. Shall we add a Lintian check for this?
***ABSOLUTELY NOT***
The -p option is for the shell to *not* drop
On Mon, 29 Sep 2014, Christoph Anton Mitterer wrote:
Now to deal with your concern of larger outages:
2) Just because there are no valid [In]Release* files, it doesn't mean
that those mirrors and their repositories can't be used any longer. The
data is still there as it was before.
An
On Mon, 29 Sep 2014, Matthias Urlichs wrote:
So, can we get now some alternative proposals that address the fact that
some mirrors need 48H validity, and many leaf mirrors really want at least
a week?
How about Security updates are published on security.d.o, so _that_
archive's validity
On Thu, 25 Sep 2014, Riku Voipio wrote:
On Wed, Sep 24, 2014 at 03:18:02PM -0300, Henrique de Moraes Holschuh wrote:
OTOH, using -z9 on datasets smaller than the -z8 dictionary size *is* a
waste of memory (I don't know about cpu time, and xz(1) doesn't say anything
on that matter
On Thu, 25 Sep 2014, Simon McVittie wrote:
Approach 1, which is (IMO) better when the changes you are making in
experimental are truly experimental, like enabling features or patches
whose medium-term future you're not sure about:
2.2.5-5+exp1, ... or -6~exp1, ... or whatever to experimental
On Thu, 25 Sep 2014, Thomas Goirand wrote:
On 09/02/2014 09:39 PM, Henrique de Moraes Holschuh wrote:
For -z9, it is as bad as ~670MiB to
compress, and ~65MiB to decompress.
I'd say this really depends on what you do. For what I do (eg: OpenStack
packages), I don't see how 65MB could
On Tue, 16 Sep 2014, Andrey Rahmatullin wrote:
On Tue, Sep 16, 2014 at 12:02:24PM +0200, Matthias Urlichs wrote:
You might want to pop up a preinst debconf notice which tells the admin
that the package will not run here (with an option to fail the install
if it's an honest mistake).
This
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Fri, 12 Sep 2014 08:54:33 -0300
Source: iucode-tool
Binary: iucode-tool
Architecture: source amd64
Version: 1.1-1
Distribution: unstable
Urgency: medium
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed-By: Henrique
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Fri, 12 Sep 2014 16:07:31 -0300
Source: autotools-dev
Binary: autotools-dev
Architecture: source all
Version: 20140911.1
Distribution: unstable
Urgency: medium
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
On Wed, 03 Sep 2014, Ritesh Raj Sarraf wrote:
My inclination is to ship both, the systemd service files and the
init scripts, in their current form along with whatever
limitations each may have, and let the user choose.
I did not get any comment on this. How are others doing similar
stuff
On Tue, 02 Sep 2014, Jonathan Dowland wrote:
On Tue, Sep 02, 2014 at 01:45:30PM +0200, Adam Borowski wrote:
For any standardish font, taking any extra memory is a no-no. You might be
running in a chroot on a 256MB RAM phone, etc.
On the other hand, for a 400MB game, not using -z9 is a
On Tue, 26 Aug 2014, Henrique de Moraes Holschuh wrote:
I'd like to know whether the kernel microcode update is working well on some
of the older Intel 32-bit processors or not. These computers were sold
between years 2000 and 2010.
This information will be used to decide the level
On Thu, 28 Aug 2014, Andrea Bolognani wrote:
On Tue, Aug 26, 2014 at 03:49:06PM -0300, Henrique de Moraes Holschuh wrote:
I'd like to know whether the kernel microcode update is working well on some
of the older Intel 32-bit processors or not. These computers were sold
between years 2000
I am the maintainer of the intel-microcode and iucode-tool packages, used to
update the microcode[1] on Intel system processors (CPU chip).
I'd like to know whether the kernel microcode update is working well on some
of the older Intel 32-bit processors or not. These computers were sold
between
On Tue, 19 Aug 2014, Lars Wirzenius wrote:
On Mon, Aug 18, 2014 at 07:28:51PM -0400, Barry Warsaw wrote:
Also, it makes me somewhat uncomfortable to assume that a git tag in the
upstream repo will always be equivalent to their released tarball. In fact,
it's often not, as is the case with
On Tue, 19 Aug 2014, Hector Oron wrote:
2014-08-15 16:04 GMT+02:00 Ondřej Surý ond...@sury.org:
I have encountered a situation where the FTBFS bug was caused
by segfault in other package. This has forced me to split opendnssec-doc
to arch:all package (which was good thing anyway), so there
On Mon, 18 Aug 2014, Don Armstrong wrote:
On Mon, 18 Aug 2014, Thorsten Glaser wrote:
This does not work in Debian: you always need the .orig.tar.* file,
at least for the upload, for non-native packages.
You need it from somewhere, but the whole point of pristine-tar is that
you can
On Sun, 17 Aug 2014, Thomas Goirand wrote:
Obviously, when upstream are already doing everything correctly, creating
the upstream/version tag should not become some administrative chore but
it could be done automatically as part of a some gbp upstream-merge
upstream-tag command for
On Sun, 17 Aug 2014, Marc Haber wrote:
Please. The attitute of requiring Debian maintainers to modify
upstream software instead of having simple two-line extension to an
init script is really unfriendly. Why do only systemd friends keep
recommending this?
Using my sysvinit hat, I've always
On Sun, 17 Aug 2014, Thomas Goirand wrote:
On 08/17/2014 03:52 AM, Raphael Hertzog wrote:
On Fri, 15 Aug 2014, Henrique de Moraes Holschuh wrote:
- the above layout is for the traditional case of non-native packages,
what would be the layout for native packages? how can be differentiate
On Fri, 15 Aug 2014, Raphael Hertzog wrote:
On Fri, 15 Aug 2014, Hector Oron wrote:
Even building arch:all packages in one architecture might solve the
issue, I do not like that approach, as it holds other arches from
building until that primary arch has built arch:all packages.
I
On Fri, 15 Aug 2014, Ondřej Surý wrote:
On Fri, Aug 15, 2014, at 15:37, Henrique de Moraes Holschuh wrote:
And any package that cannot build arch:all on a released arch for which
it produces binary packages potentially has a FTBFS bug, anyway, which
can be reported by any interested parties
On Fri, 15 Aug 2014, Raphael Hertzog wrote:
- how do we tag the package releases?
- pkg/version
(note: git-buildpackage uses debian/version but I find this confusing
- shall we standardize the pristine-tar branch?
IMHO it should be reserved for pristine-tar usage (as in don't use it
On Fri, 15 Aug 2014, Christian Kastner wrote:
On 2014-08-15 16:16, Raphael Hertzog wrote:
- pkg/version
(note: git-buildpackage uses debian/version but I find this confusing
as we then also have the debian/ prefix for ubuntu or kali uploads, we
don't need the vendor prefix as the
On Fri, 15 Aug 2014, Michael Biebl wrote:
Am 15.08.2014 17:47, schrieb Gerrit Pape:
Package: rsyslog
Version: 8.2.2-3
Severity: serious
Justification: Policy 2.5
Hi, the current rsyslog package version in testing is priority important
and depends on packages with priority extra.
On Fri, 15 Aug 2014, Steve Langasek wrote:
The alternative is handwaving and ignoring the fact that your package
repository is not a complete representation of your package as it exists in
the archive.
What's wrong with storing the upstream tarballs themselves on a separate
branch, if you're
On Wed, 13 Aug 2014, Brian May wrote:
* Package name: cryptography
...
I imagine the binary package will be called python{,3}-cryptography.
Haven't got to this step yet.
Wouldn't it be better to also have the source package name in the python-
namespace? Its using a dictionary word for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 12 Aug 2014 08:22:07 -0300
Source: iucode-tool
Binary: iucode-tool
Architecture: source amd64
Version: 1.0.3-1
Distribution: unstable
Urgency: medium
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed-By: Henrique
On Sat, 09 Aug 2014, Bill Allombert wrote:
3. libjpeg8 adds new features to the JPEG image format. These have
however been rejected from the ISO standard, and their
contributions to image quality and compression appear to be widely
disputed.
This is not really relevant.
On Sat, 09 Aug 2014, Henrique de Moraes Holschuh wrote:
This is not really relevant. What is relevant, however, is that nobody is
disputing that libjpeg8 produce higher quality images than libjpeg62 when
decompressing standard JPEG images.
If this is true, it is a concern: at least
On Sat, 02 Aug 2014, Josh Triplett wrote:
How easily could you teach syslog-nagios-bridge to listen on a UNIX
domain socket, instead of or in addition to a TCP socket? You could
then have it listen on /run/syslog-nagios-bridge by default, and have
rsyslog automatically forward messages there.
On Mon, 28 Jul 2014, Norbert Preining wrote:
On Sun, 27 Jul 2014, Reinhard Tartler wrote:
In [1], Moritz from the security team clearly stated that he is more
than uncomfortable with having more than one copy of libavcodec in
debian/testing. In consequence this means that any package that
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 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 it. This will probably be just like
On Mon, 14 Jul 2014, Nathan Schulte wrote:
ASCII hex encodes 4 bits as 8 (or 7. but really 8.), as each ASCII
character is a nibble of the digest; that's a 100% increase (factor
of 2) over the bare digest (or a raw mapping of 8 bits of digest
to an 8 bit character set).
The figures given
On Mon, 14 Jul 2014, Jakub Wilk wrote:
* Peter Palfrader wea...@debian.org, 2014-07-14, 20:25:
The basic idea is that it's much harder to come up with a
simultaneoush hash collision with both SHA-1 and SHA-2 than
breaking either of them independently.
ISTR reading papers that put this much
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 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, 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 speak
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:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Fri, 27 Jun 2014 16:35:12 -0300
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 2.20140624.1
Distribution: unstable
Urgency: high
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
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
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 processor errata, not just due to user
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
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 option
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're not unheard
of.
Looking
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 will
On Sat, 24 May 2014, Jakub Wilk wrote:
* Marcio de Souza Olivera m.desouz...@gmail.com, 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 10 May 2014 18:35:36 -0300
Source: iucode-tool
Binary: iucode-tool
Architecture: source amd64
Version: 1.0.2-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: Sat, 10 May 2014 18:02:55 -0300
Source: autotools-dev
Binary: autotools-dev
Architecture: source all
Version: 20140510.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, 03 May 2014 14:21:27 -0300
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 2.20140430.1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
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 like it is working, but we don't properly support
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.
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, see
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
On Thu, 27 Mar 2014, Jakub Wilk wrote:
* Mathieu Malaterre ma...@debian.org, 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
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
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 the
On Tue, 18 Feb 2014, Russ Allbery wrote:
Henrique de Moraes Holschuh h...@debian.org 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.
If you look
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
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
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 Ubuntu), but with systemd we will have to get
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 01 Feb 2014 15:39:03 -0200
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 2.20140122.1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
201 - 300 of 1562 matches
Mail list logo
