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
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 perezme...@gmail.com writes:
If you go for changing the name, kerberos-wallet or krb-wallet seems
quite right.
It's a reasonable idea
On Wed, 29 Aug 2012, Ben Hutchings wrote:
On Wed, 2012-08-29 at 22:25 -0300, Henrique de Moraes Holschuh wrote:
On Thu, 30 Aug 2012, Marco d'Itri wrote:
On Aug 30, Michael Biebl bi...@debian.org wrote:
The obvious way is to not use a separate /usr anymore or simply mount
/usr via
On Thu, 30 Aug 2012, Marco d'Itri wrote:
On Aug 30, Michael Biebl bi...@debian.org wrote:
The obvious way is to not use a separate /usr anymore or simply mount
/usr via the initramfs.
Wasn't there a patch for initramfs-tools floating around doing that?
Yes, there is one but the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Wed, 29 Aug 2012 19:33:14 -0300
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 1.20120606.5
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
On Tue, 28 Aug 2012, Paul Tagliamonte wrote:
Clearly, some upstreams (such as GNU projects, I'm guessing) wouldn't be
receptive to such changes, and I don't think it's right to try to
enforce this on them.
Those quite often use automake for the build system. Automake is supposed
to be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 26 Aug 2012 18:38:54 -0300
Source: iucode-tool
Binary: iucode-tool
Architecture: source amd64
Version: 0.8.3-1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed-By: Henrique de
On Fri, 24 Aug 2012, Andreas Tille wrote:
do not create a subdirectory). When I write get-orig-source tarballs
I always create a pkg-version directory and unpack the content
to this. Should this be implemented as well or do you think it is
better to change as less as possible?
You can
On Sat, 18 Aug 2012, Marco d'Itri wrote:
But still, I agree that we should have a better way to signal to user
space when an interface is ready. Not just for IPv6, but also more
We need better userspace glue, then. Because the netlink interface to
the kernel network core and IP stack has
On Sun, 19 Aug 2012, Marco d'Itri wrote:
On Aug 19, Henrique de Moraes Holschuh h...@debian.org wrote:
But still, I agree that we should have a better way to signal to user
space when an interface is ready. Not just for IPv6, but also more
We need better userspace glue, then. Because
On Sun, 19 Aug 2012, Marco d'Itri wrote:
On Aug 19, Charles Plessy ple...@debian.org wrote:
- PHP scripts can be executed by Apache httpd through libapache2-mod-php5
or
php5-cgi. Debian recommends libapache2-mod-php5, but there are still
This is another issue which concerns me, since
On Sat, 18 Aug 2012, Marc Haber wrote:
This is not always easy. For example, IPv6 isn't ready when ifup
It is ready enough: it is activated on all interfaces where it should be
activated.
Anything that uses IPv6 and cannot deal with dynamic changes on the host
addresses is critically broken.
On Wed, 15 Aug 2012, Steve Langasek wrote:
On Wed, Aug 15, 2012 at 02:15:20PM +0100, Jon Dowland wrote:
On Tue, Aug 07, 2012 at 01:00:38PM +0100, Ian Jackson wrote:
/usr/games is a swamp for another time I think. I guess it contains
an awful lot of things with clashing names.
Last I
On Mon, 13 Aug 2012, Roger Leigh wrote:
Just to bring this back on topic, if the initial tests of OpenRC
show it to be viable and that it's possible to upgrade seamlessly
from sysv-rc, then I would propose to drop sysv-rc entirely, rather
than having a choice here. OpenRC would be a
Format: 1.8
Date: Sat, 11 Aug 2012 19:35:46 -0300
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 1.20120606.4
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed-By: Henrique de Moraes Holschuh h...@debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 29 Jul 2012 10:06:35 -0300
Source: iucode-tool
Binary: iucode-tool
Architecture: source amd64
Version: 0.8.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: Sun, 29 Jul 2012 11:09:44 -0300
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 1.20120606.3
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 24 Jul 2012 11:53:05 -0300
Source: iucode-tool
Binary: iucode-tool
Architecture: source amd64
Version: 0.8.1-1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed-By: Henrique de
On Mon, 23 Jul 2012, Vincent Lefevre wrote:
so that if you want to make things more consistent, you should
get rid of /etc/default entirely.
/etc/default is used for a lot more than just enabling/disabling services,
and it will not go away.
Now, if you just mean removing enable/disable
On Sun, 22 Jul 2012, lina wrote:
I am (seriously) thinking, is it possible to turn the apple light logo
to debian/linux logo?
Yes. Cover it entirely with a design that will let a swirl of light get
past. The challenge is to make it look _good_ :-)
--
One disk to rule them all, One disk to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 21 Jul 2012 18:10:47 -0300
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 1.20120606.2
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
On Fri, 20 Jul 2012, Steve McIntyre wrote:
Naming
==
Naming issues: ARM are calling the new 64-bit architecture
AArch64. Other people don't like that and various other names have
been proposed for use elsewhere. Debian/Ubuntu developers have already
picked the name arm64 in dpkg and
On Sat, 21 Jul 2012, Wookey wrote:
Arm64 everywhere would have been neater but unless someone is
volunteering for a massive argument and changing upstream gcc and
No way. it is difficult to do better at this kind of thing than Linus, and
he has already said his piece :-p It won't be aarch64
On Sun, 15 Jul 2012, Filipus Klutiero wrote:
Perl HTML::Tree 5 has backwards-incompatible interface changes.
Version 5.00-1 added a NEWS.Debian entry to warn about that. As the
...
migrated to testing and I upgraded my system. The operation was
interrupted with a prompt which requested my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Fri, 13 Jul 2012 15:23:23 -0300
Source: intel-microcode
Binary: intel-microcode
Architecture: source amd64
Version: 1.20120606.1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
On Tue, 10 Jul 2012, Andrei POPESCU wrote:
On Ma, 10 iul 12, 22:07:10, Eugene V. Lyubimkin wrote:
... And I disagree with that. No solution can override policy's all
Depends must be satisfied. If one choose to support the exclude from
metapackage one either has to change the policy, remove
On Wed, 11 Jul 2012, Jon Dowland wrote:
On Tue, Jul 10, 2012 at 04:39:10PM +, Sune Vuorela wrote:
On 2012-07-10, Gergely Nagy alger...@balabit.hu wrote:
No. Only if installing recommends is turned on, which cannot be
guaranteed.
There is many ways to break your system. turning
On Wed, 11 Jul 2012, Gergely Nagy wrote:
Henrique de Moraes Holschuh h...@debian.org writes:
IMO, metapackages should depend on the absolutely required stuff (and many
times that will be the empty set), recommend the rest, and maybe even
suggest fringe packages. This achieves maximum
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 09 Jul 2012 19:31:47 -0300
Source: amd64-microcode
Binary: amd64-microcode
Architecture: source amd64
Version: 1.20120117-1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 09 Jul 2012 21:50:35 -0300
Source: amd64-microcode
Binary: amd64-microcode
Architecture: source amd64
Version: 1.20120117-2
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 10 Jun 2012 12:22:01 -0300
Source: amd64-microcode
Binary: amd64-microcode
Architecture: source amd64
Version: 0.20120117-1
Distribution: unstable
Urgency: medium
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
On Sun, 24 Jun 2012, Goswin von Brederlow wrote:
Henrique de Moraes Holschuh h...@debian.org writes:
I've read that some SSDs really *dislike* the way Linux does TRIM
batching (or doesn't :p), so yes, it may well be that on most SSDs
regular fstrim will do much better.
I'm assuming
On Sat, 23 Jun 2012, Rudy Zijlstra wrote:
On 22-06-12 21:38, Henrique de Moraes Holschuh wrote:
On Fri, 22 Jun 2012, Rudy Zijlstra wrote:
let system run with IPv4 IPv6 routing for about 1 month
IPv6 routing will start to fail
IPv4 routing becomes slow and unpredictable
no obvious causes
On Sun, 24 Jun 2012, Osamu Aoki wrote:
On Sat, Jun 23, 2012 at 06:00:15PM +0300, Touko Korpela wrote:
Tollef Fog Heen wrote:
On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote:
On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote:
]] Stephan Seitz
Will
On Fri, 22 Jun 2012, Andrei POPESCU wrote:
On Mi, 20 iun 12, 15:18:55, Stephan Seitz wrote:
Fine let’s talk. Why can’t we find a compromise? Additional to our
disk /tmp we create a /ramtmp (so the name suggests that this tmp is
a ramdisk) with tmpfs. This should be doable in time for
On Fri, 22 Jun 2012, Rudy Zijlstra wrote:
let system run with IPv4 IPv6 routing for about 1 month
IPv6 routing will start to fail
IPv4 routing becomes slow and unpredictable
no obvious causes visible in the system. top and friends do not show a cpu hog
a reboot will bring the system
On Mon, 18 Jun 2012, Stephen Hemminger wrote:
I will be happy to get involved; upstream irqbalance is on my list
of things that are broken and needs to be fixed. Will try and get a hold
Could you elaborate on this?
of past contributors to figure out what is happening. I know there was
talk
On Sat, 16 Jun 2012, Aníbal Monsalve Salazar wrote:
On Fri, Jun 15, 2012 at 08:54:23AM -0700, Stephen Hemminger wrote:
Irqbalance project has moved to http://code.google.com/p/irqbalance/
The current Debian package is back at 0.56 (over 2yrs old)
and upstream is now at version 1.0.3
On Wed, 13 Jun 2012, Ben Hutchings wrote:
On Wed, 2012-06-13 at 09:22 +0200, Bjørn Mork wrote:
Since tmpfs+swap is mostly slower than regular filesystem
And the world is flat.
Well... if you actually do have to swap, the I/O pattern is currently
not very efficient. See
- There's no danger of a symlink attack or similar with things like
tmpreaper -- or indeed any need for tmpreaper anymore. You reboot the
system, and /tmp is clean again, no matter what was there before. This
is more than just a convenience.
We really ought to fix tmpreaper then, it
Package: wnpp
Severity: wishlist
Owner: Henrique de Moraes Holschuh h...@debian.org
* Package name: amd64-microcode
Version : 0.20120117
Upstream Author : AMD, Inc
* URL : http://www.amd64.org/support/microcode.html
* License : proprietary
Description
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 07 Jun 2012 12:57:37 -0300
Source: iucode-tool
Binary: iucode-tool
Architecture: source amd64
Version: 0.8-1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed-By: Henrique de
On Sat, 09 Jun 2012, Philipp Kern wrote:
On Sat, Jun 09, 2012 at 04:36:40AM +0800, Aron Xu wrote:
Does this mean M-A:same packages should be prevented from being
binNMUed, but only source upload can be accepted?
You cannot deprive the Release Team of this tool. Also multiarch bugs are IMHO
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Fri, 08 Jun 2012 12:48:45 -0300
Source: autotools-dev
Binary: autotools-dev
Architecture: source all
Version: 20120608.1
Distribution: unstable
Urgency: medium
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
-By: Henrique de Moraes Holschuh h...@debian.org
Description:
intel-microcode - Processor microcode data file for Intel CPUs
Changes:
intel-microcode (0.20120606-1) unstable; urgency=medium
.
* New upstream data file: microcode-20120606
+ New Microcodes:
sig 0x00020661, pf mask 0x02, 2011
On Sat, 26 May 2012, Joey Hess wrote:
Henrique de Moraes Holschuh wrote:
In fact it is the other way. We have /var/tmp for the large file since
about forever, and important platforms that have /tmp in memory since the
early 2000's (Solaris)
And that STILL wasn't enough for people
On Sat, 26 May 2012, Carlos Alberto Lopez Perez wrote:
So please, don't argue about theoretical things about virtual memory or
IO schedulers. If you are a desktop Linux user, you should know how ugly
the things get when the system is swapping.
Mine is not that annoying, but certainly not
On Sat, 26 May 2012, Salvo Tomaselli wrote:
Or, it should get clever and not unpack everything. There are plenty of
software that are able to read into archives without extracting from
them.
You can't do it for a .tar.gz or a .tar.bz and they are the most common kind
of archive.
Yes,
On Fri, 25 May 2012, Thomas Goirand wrote:
for small files, and in that case, it's faster. In reality, it's
not that much faster, thanks to Linux caching of the filesystem,
Under heavy filesystem IO load, yes it is. By several orders of magnitude.
the point. Maybe we should add a
On Fri, 25 May 2012, Jon Dowland wrote:
On Fri, May 25, 2012 at 09:46:37AM +0200, Vincent Danjean wrote:
If some kind of sync is required by the application, I think this is
because the application want to ensure the data are really written to
the disk so that their state remains coherent
On Fri, 25 May 2012, Salvo Tomaselli wrote:
Because paging out a couple Gigabytes is veery different from
writing a couple Gigabytes to disk, of course.
Yes because writing that on disk will only block the thread performing the
write, not every thread that tries to allocate memory.
On Fri, 25 May 2012, Salvo Tomaselli wrote:
nevertheless. And somehow the OOM killer was not even triggered, i kept
ending
up with a system where i had a working shell but could not run certain
commands (such as kill), but i could see the output of free for example.
Switch to the deadline
On Sun, 20 May 2012, Russ Allbery wrote:
Ben Hutchings b...@decadent.org.uk writes:
If by 'plain x86' you mean PCs with 32-bit processors, we would no
longer support them - *eventually*.
Excactly like how we no longer support pure i386 systems (as opposed to
i486 or later). And with the
On Thu, 17 May 2012, Thomas Goirand wrote:
On 05/03/2012 07:23 AM, Henrique de Moraes Holschuh wrote:
Well, FWIW postfix allows you to override all MTA notifications, not just
bounce messages, but the full set. We do that at work.
Interesting. Can you post an example here?
man bounce
On Fri, 18 May 2012, Adam Borowski wrote:
On Fri, May 18, 2012 at 12:16:40PM +0200, Andrew Shadura wrote:
On Fri, 18 May 2012 11:37:08 +0200
Adam Borowski kilob...@angband.pl wrote:
Quilt is a kind of really primitive VCS. It does not make sense to
use both it and a modern one, and
On Wed, 16 May 2012, Wookey wrote:
this to Debian? I see a couple of places in the UI where it says
'Ubuntu' and it would be good if it got a bit cleverer and put in the
If Ubuntu sponsored the creation of usb-creator, we can package it that
way just fine, as long as the trademark license for
On Thu, 17 May 2012, Charles Plessy wrote:
It strikes me that while we have more than 6,500 source packages
managed with Git, we are pushing for a source package format that does
not work transparently with them.
It does, but not on all workflows. A very large number of DDs are using
3.0
On Wed, 02 May 2012, Aron Xu wrote:
On Wed, May 2, 2012 at 4:37 PM, Adam Borowski kilob...@angband.pl wrote:
On Wed, May 02, 2012 at 10:02:37AM +0200, Josselin Mouette wrote:
Is this the right time to do it?
No. Cron needs some way to report about its jobs, mdadm has to notify about
On Wed, 02 May 2012, Christian PERRIER wrote:
(slightly off-topic)
Quoting Russell Coker (russ...@coker.com.au):
No, bouncing mail when it can't be properly delivered is much better than
violating RFCs.
Mail that is bounced with a human readable message describing the real
cause
On Sat, 28 Apr 2012, Marcus Frings wrote:
Apr 28 12:25:52 black-ice kernel: [1216918.909369]
/usr/local/texl[14001]: segfault at 0 ip b7591a11 sp bfd15c8c error 4 in
libc-2.13.so[b7515000+156000]
NULL pointer derreference.
I have uploaded the output of strace biber --version to
On Thu, 26 Apr 2012, Timo Weingärtner wrote:
2012-04-26, 23:23:54 Timo Juhani wrote:
Raphael Geissert geiss...@debian.org writes:
print hmac_sha1_hex($v, $m);
Yeah that sounds promising. Now we just need to fix the code that tries
to randomize the order of entries in the tally.
Is
On Wed, 11 Apr 2012, Raphael Hertzog wrote:
On Wed, 11 Apr 2012, Brian May wrote:
On 10 April 2012 16:06, Yves-Alexis Perez cor...@debian.org wrote:
dpkg -l | awk '/^rc/ {print $2}' | xargs --no-run-if-empty dpkg --purge
That's a pretty dangerous line. People (sometimes) don't purge
On Thu, 15 Mar 2012, Michael Biebl wrote:
The tool to process those tmpfiles will make sure to do all the
necessary sanity checks and also run restorecon when selinux is in use.
E.g. systemd-tmpfiles [2], the tool in systemd to handle tmpfiles,
already handles selinux correctly.
While at it,
On Tue, 21 Feb 2012, Gunnar Wolf wrote:
Henrique de Moraes Holschuh dijo [Sat, Feb 18, 2012 at 10:46:50AM -0200]:
Good packaging developers go to great lengths to be sure they are not
going to distribute anything trojaned. This takes a lot of work, and
often requires very goot working
On Sat, 18 Feb 2012, Teus Benschop wrote:
To put things in perspective, I just wonder how strong this 'fortress'
really is, and whether this strength is only in our perception or
whether it is real. Let me give just one example: A developer downloads
a tarball from an upstream source,
On Sat, 18 Feb 2012, Neil Williams wrote:
On Sat, 18 Feb 2012 16:25:20 +0200
Christoph Anton Mitterer cales...@scientia.net wrote:
Am 18.02.2012 14:40, schrieb Neil Williams:
I think as a start it should be made a policy that any wrapper
package that
downloads code from the net must
On Sat, 18 Feb 2012, Philip Hands wrote:
On Sat, 18 Feb 2012 15:49:30 +, Neil Williams codeh...@debian.org wrote:
On Sat, 18 Feb 2012 16:25:20 +0200
Christoph Anton Mitterer cales...@scientia.net wrote:
Am 18.02.2012 14:40, schrieb Neil Williams:
I think as a start it should be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 13 Feb 2012 21:25:55 -0200
Source: autotools-dev
Binary: autotools-dev
Architecture: source all
Version: 20120210.1
Distribution: unstable
Urgency: high
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
On Sat, 11 Feb 2012, Raphael Hertzog wrote:
It could be a source of subtle bugs if this leads to having
libfoo:i386 (1.0) + libfoo:amd64 (2.0) + libfoo-data:all (2.0)
But then the proper answer is for the maintainer to put
a tight dependency “Depends: libfoo-data (= ${source:Version})”.
On Sat, 11 Feb 2012, Henrique de Moraes Holschuh wrote:
On Sat, 11 Feb 2012, Raphael Hertzog wrote:
It could be a source of subtle bugs if this leads to having
libfoo:i386 (1.0) + libfoo:amd64 (2.0) + libfoo-data:all (2.0)
But then the proper answer is for the maintainer to put
a tight
On Tue, 07 Feb 2012, Marco d'Itri wrote:
On Feb 07, Thomas Goirand z...@debian.org wrote:
Are you trying to make the point that, with containers,
you wouldn't need ssh, and you would with VMs? If so,
With *OpenVZ* I do not need sshd, ftpd and cron in the guest because
I can use the one in
On Tue, 07 Feb 2012, Ben Hutchings wrote:
But it's worse than this: even if dpkg decompresses before comparing,
debsums won't (and mustn't, for backward compatibility). So it's
Maybe you can switch to sha256 and add the new functionality while at
it? Detect which mode (md5sum raw, sha256
On Tue, 07 Feb 2012, Jonathan Nieder wrote:
Henrique de Moraes Holschuh wrote:
Maybe you can switch to sha256 and add the new functionality while at
it? Detect which mode (md5sum raw, sha256 uncompress) by the size of
the hash. Old debsums won't work with the new files, but is that really
On Tue, 07 Feb 2012, Roger Leigh wrote:
While the waf behavour does sound quite awful, is this really
any different than the current behaviour of the autotools? The
That is one of the reasons why you are supposed to retool on distro builds.
Retooling the entire build system as part of the
On Mon, 06 Feb 2012, Ben Hutchings wrote:
arbitrarily large files (in my workflow, 5-100 GB) in /tmp, which is on
the root filesystem.
Well, that is Seriously Broken, and it needs fixing. And it is not a
wishlist bug either. We've been through a thread about this rather
recently.
There
On Fri, 20 Jan 2012, Goswin von Brederlow wrote:
Henrique de Moraes Holschuh h...@debian.org writes:
On Thu, 19 Jan 2012, Paul Eggert wrote:
On 01/19/12 07:29, Henrique de Moraes Holschuh wrote:
Note: there is no reason why the kernel could not return the mount
information with shadowed
On Fri, 20 Jan 2012, Goswin von Brederlow wrote:
Henrique de Moraes Holschuh h...@debian.org writes:
The kernel has to return all entries that are visible to the current
namespace, otherwise you pretty much cannot know about the existence of
shadowed entries in the first place, and that has
On Fri, 20 Jan 2012, Marco d'Itri wrote:
On Jan 20, Goswin von Brederlow goswin-...@web.de wrote:
But I guess the solution for this would be to have udev make /dev/r/usr
the real device and /dev/mapper/r-usr a symlink.
No, because udev does not creates/renames devices anymore.
(This
On Thu, 19 Jan 2012, Goswin von Brederlow wrote:
Paul Eggert egg...@cs.ucla.edu writes:
On 01/18/12 06:25, Goswin von Brederlow wrote:
What df should do is automatically skip the entries that are obscured or
generally inaccessible.
Isn't this missing some of the larger context? df is
On Thu, 19 Jan 2012, Henrique de Moraes Holschuh wrote:
On Thu, 19 Jan 2012, Goswin von Brederlow wrote:
Paul Eggert egg...@cs.ucla.edu writes:
On 01/18/12 06:25, Goswin von Brederlow wrote:
What df should do is automatically skip the entries that are obscured or
generally inaccessible
On Thu, 19 Jan 2012, Paul Eggert wrote:
On 01/19/12 07:29, Henrique de Moraes Holschuh wrote:
Note: there is no reason why the kernel could not return the mount
information with shadowed paths removed in a separate procfs node, as
that would cause no security/troubleshooting problems
On Mon, 02 Jan 2012, Karl Goetz wrote:
to fix a tiny problem which presents itself just for the length of
the upgrade process, if at all.
Correct. It's an option nevertheless, so I mentioned it.
Sorry if I've misunderstood, but doesn't this problem manifest for
*anyone* trying to
-By: Henrique de Moraes Holschuh h...@debian.org
Description:
intel-microcode - Processor microcode data file for Intel CPUs
Changes:
intel-microcode (0.2010-1) unstable; urgency=low
.
* New upstream data file: microcode-2010
+ New Microcodes:
sig 0x000206d6, pf mask 0x6d, 2011
On Thu, 08 Dec 2011, Marco d'Itri wrote:
There are quite good reasons why you wouldn't want to do thing that
way though. We should at least do our best not to make things
unreasonably difficult for people in this situation, even if we chose
not to really 'support' it.
We need to
On Tue, 15 Nov 2011, Aneurin Price wrote:
I think this discussion needs a sanity check.
Please remember, the topic of conversation is whether an application
can reasonably make the assumption that the system defined tmp
directory is a suitable place to store temporary data.
/tmp in RAM has
On Sun, 06 Nov 2011, Steve Langasek wrote:
On Sun, Nov 06, 2011 at 11:36:05PM +, Clint Adams wrote:
On Sun, Nov 06, 2011 at 04:25:32PM +0100, Josselin Mouette wrote:
What is the use case?
The use case is to have a place for executables that are treated
similarly to libraries by
On Tue, 25 Oct 2011, Bernhard R. Link wrote:
As a rule, you are supposed to get rid of all autogenerated files and
rebuild them from scratch when packaging for Debian. AM_MAINTAINER_MODE
changes nothing in that case, as you will readly notice any upstream
breakage when you try to build
On Tue, 25 Oct 2011, Adam Borowski wrote:
If they use AM_MAINTAINER_MODE and it's disabled [1], there's no way to
check if they aren't in DFSG and/or GPL violation by shipping sourceless
code. Forbidding it would at least deal with patching autotools output
rather than source.
As a rule, you
On Wed, 19 Oct 2011, Tollef Fog Heen wrote:
The first and obvious one is to avoid file name clashes in the
archive. Another one is so the version number in the file name actually
is the version number of the package which makes it less confusing when
you need to download a package with an
On Wed, 19 Oct 2011, Ognyan Kulev wrote:
На 19.10.2011 16:18, Henrique de Moraes Holschuh написа:
Well, while % is xml/xhtml/html-friendly, it is *not* http-friendly, and
will require double-encoding.
So we have encoding : anyway. What about using .. (horizontal
:) - it looks much nicer
de Moraes Holschuh h...@debian.org
Description:
intel-microcode - Processor microcode data file for Intel CPUs
Changes:
intel-microcode (0.20110915-1) unstable; urgency=low
.
* New upstream data file: microcode-20110915
+ New Microcodes:
sig 0x000206f2, pf mask 0x05, 2011-07-21
On Sat, 15 Oct 2011, Josselin Mouette wrote:
Le vendredi 14 octobre 2011 à 11:32 -0300, Henrique de Moraes Holschuh a
écrit :
I seem to recall our super duper memory-bloated DEs were not even
warning the user when something was screaming blood murder on the
emergency, alert and critical
On Sat, 15 Oct 2011, Adam Borowski wrote:
On Sat, Oct 15, 2011 at 12:46:50PM +0200, Josselin Mouette wrote:
Le samedi 15 octobre 2011 à 12:36 +0200, Adam Borowski a écrit :
Hell no. I'd go as far as labelling it a severity:critical bug.
Go ahead, reporting bugs doesn’t necessarily get
On Thu, 13 Oct 2011, Luca Capello wrote:
- Starting a daemon at boot time, which slows down booting. This led me
to notice the problem in Debian Live: it took a non-trivial amount of
time for the boot process to finish starting exim and move on.
I experienced the same in the past on
On Thu, 13 Oct 2011, Josh Triplett wrote:
Possibly. The system I booted Debian Live on also had no network
connection. But either way, exim takes a non-zero amount of time to
Nowadays, you really need to properly setup non-networked systems
correctly, to avoid being pestered by timeouts. I
On Thu, 13 Oct 2011, Josh Triplett wrote:
On Thu, Oct 13, 2011 at 10:57:29PM +0200, Frank Steinborn wrote:
Josh Triplett wrote:
...which produce output to somewhere other than a log file, in some
scenario other than being buggy and accidentally producing output, and
which expect end
On Thu, 13 Oct 2011, Paul Wise wrote:
As someone who runs Debian on his smartphone, I completely agree with
making an MTA optional.
Eh, it is not essential, just standard. You want Debian standard to be
tailored for smartphone use? Isn't that a much better job done through a
Debian pure
On Sun, 02 Oct 2011, Florian Weimer wrote:
Couldn't we get rid of static libraries altogether, replacing static
linking with ahead-of-time dynamic linking?
Well, the normal usecase for static libraries and static linking is to
produce self-contained objects. If you can link a bunch of dynamic
On Sat, 24 Sep 2011, Charles Plessy wrote:
If in a large number of cases where one would like to turn off the patch
system
of the 3.0 (quilt) format, the source package is stored in a Git repository,
then one way to move forward would be to make the format 3.0 (git) available
in Debian.
reassign 642005 linux-2.6
thanks
On Mon, 19 Sep 2011, Evgeni Golov wrote:
On 09/19/2011 03:12 AM, Henrique de Moraes Holschuh wrote:
On Sun, 18 Sep 2011, Evgeni Golov wrote:
On 09/18/2011 04:46 PM, Henrique de Moraes Holschuh wrote:
Reassigning to Debian live-config, please reassign
401 - 500 of 1562 matches
Mail list logo
