On Thu, 30 Dec 2010, Olaf van der Spek wrote:
On Thu, Dec 30, 2010 at 4:24 PM, Henrique de Moraes Holschuh
h...@debian.org wrote:
On Thu, 30 Dec 2010, Olaf van der Spek wrote:
The reason I asked for a kernelland solution is because it's hard if
not impossible to do properly in userland
On Thu, 30 Dec 2010, Henrique de Moraes Holschuh wrote:
BTW: safely removing a file is also tricky. AFAIK, one must open it RW,
in exclusive mode. stat it by fd and check whether it is what one
expects (regular file, ownership). unlink it by fd. close the fd.
Eh, as it was pointed to me
On Thu, 02 Dec 2010, Thomas Thurman wrote:
I am proposing an escape sequence which, when transmitted over SSH
or telnet, requests the client to display a desktop notification. I
have written up a description, with some example code, at
If you're going to do something this insecure, just use
On Wed, 10 Nov 2010, Bob Proulx wrote:
The packages for Debian there add a source.list.d file as you
describe. (And it really confused me until I figured out what it had
Which begs the question: why do we even have source.list.d/ suport in
the first place (or, if it is really useful to other
On Wed, 10 Nov 2010, Henrique de Moraes Holschuh wrote:
On Wed, 10 Nov 2010, Bob Proulx wrote:
The packages for Debian there add a source.list.d file as you
describe. (And it really confused me until I figured out what it had
Which begs the question: why do we even have source.list.d
On Thu, 28 Oct 2010, Mehdi Dogguy wrote:
Idiocy quietly watches for people insecurely visiting twitter on public
wifi networks, then hijacks their session to post a tweet warning them
about the dangers. It was written in response to the release of
Firesheep, which will result in a huge
de Moraes Holschuh h...@debian.org
Description:
intel-microcode - Processor microcode data file for Intel CPUs
Changes:
intel-microcode (0.20100914-1) unstable; urgency=low
.
* New upstream data file: microcode-20100914
+ Updated Microcodes:
sig 0x000206c2, pf mask 0x03, 2010-09
On Wed, 15 Sep 2010, Marco d'Itri wrote:
On Sep 15, Christian PERRIER bubu...@debian.org wrote:
I would like to know the process which lead to selecting these figures.
Apparently, just like many other things in the project: the folks
doing the work (and appointed for this by the project
On Wed, 15 Sep 2010, Marco d'Itri wrote:
On Sep 14, brian m. carlson sand...@crustytoothpaste.net wrote:
I suspect that those figures are because 2048 bits is the default size
for RSA keys and 4096 bits is the largest size that GnuPG supports.
FWIW, the OpenPGP smartcard v2 supports keys up
On Wed, 15 Sep 2010, Felipe Sateler wrote:
On 14/09/10 01:18, Gunnar Wolf wrote:
- Your new key should be signed by two or more other Debian Developers
The NM and DM processes require only one signature. Why is it harder to
replace a key than to become a DD?
Or rather, why the requirements
On Wed, 15 Sep 2010, Giuseppe Sacco wrote:
here it fails with message No patches in series because it doesn't
look for debian/patches/series but only for patches/series.
You have to set the QUILT_PATCHES environment variable or tell quilt where
to find the patches through its config file.
man
On Wed, 15 Sep 2010, Giuseppe Sacco wrote:
IMO, you should try to get yourself better acquinted with quilt before
using it, or you can end up with a mess.
Right. That's why I am testing this process while upstream only produced
and rc version.
I've found that using dpkg-source format
On Wed, 15 Sep 2010, Goswin von Brederlow wrote:
QUILT_PATCHES=debian/patches quilt push
will do the same. You only need QUILT_PATCHES for the first quilt call.
Is that so? That would be good news, but it doesn't match my
experience... although the last time I tried that was some months
On Tue, 14 Sep 2010, brian m. carlson wrote:
Personally, I can't see a reason that using an RSA 4096 bit key should
be that painful even on very slow machines. You're performing a *single
RSA encrypt operation* per signature.
Well, the main key is mostly a key-signing key/KSK (although you
On Tue, 07 Sep 2010, Sune Vuorela wrote:
I'm not planning to ever provide backports of any of my packages, and
while others are welcome to do it, I do not in any way want to be
bothered by their bugs or upload emails or anything.
Which would call for filtering, not for keeping the bad
de Moraes Holschuh h...@debian.org
Description:
intel-microcode - Processor microcode data file for Intel CPUs
Closes: 571128
Changes:
intel-microcode (0.20100826-1) unstable; urgency=low
.
* New upstream data file: microcode-20100826 (closes: #571128)
* debian/control: Add myself
On Sat, 07 Aug 2010, Neil McGovern wrote:
Well, it seems that other people haven't taken an interest in the bug,
and we've now frozen, again.
Yes. And the justifications in the bug report for not fixing the underlying
issues go like this: we should take actions which are guaranteed to destroy
On Sat, 07 Aug 2010, Henrique de Moraes Holschuh wrote:
Can we PLEASE rename this from rescue image to safe mode image, and
document in its boot screen that it should NEVER be used in a system with
filesystem or RAID problems?
Well, my whole reply came out with a lot more annoyed tone than I
On Sat, 07 Aug 2010, Frans Pop wrote:
On Saturday 07 August 2010, Neil McGovern wrote:
As there isn't a resolution in sight, I'll add a hint at the end of
August for the removal of the package unless there's significant
progress to fixing the issue.
I still feel this is an overreaction
On Sat, 07 Aug 2010, Colin Watson wrote:
On Sat, Aug 07, 2010 at 04:31:22PM +0200, Frans Pop wrote:
On Saturday 07 August 2010, Neil McGovern wrote:
As there isn't a resolution in sight, I'll add a hint at the end of
August for the removal of the package unless there's significant
On Thu, 08 Jul 2010, Thadeu Lima de Souza Cascardo wrote:
I've submitted bug 497206 for aptitude with a patch attached almost two
years ago. It's a new feature, to allow packages to be grouped by
source. It's usually easier to upgrade all packages from the same
source, without having to look
On Thu, 15 Jul 2010, Russ Allbery wrote:
Early system startup (before $remote_fs) is a weird and special
environment, and most services should just depend on $remote_fs and not
worry about it. Normally they have to anyway since the daemon being
started is in /usr. Services that do not depend
On Thu, 15 Jul 2010, Christoph Anton Mitterer wrote:
Is there any policy document or that like,... which mandates:
a) What is guaranteed to be available in initramfs images?
Not much is guaranteed to be available in initramfs, unless you arranged for
it to be, AFAIK.
b) What is guaranteed to
On Fri, 16 Jul 2010, Christoph Anton Mitterer wrote:
But I think:
1) the policy description of essential should be clarified then, as now
Essential means that the *package* essential functionality (not all of its
contents or functionality) has to be available at all times in the lifetime
of the
On Fri, 16 Jul 2010, Christoph Anton Mitterer wrote:
Having $remote_fs is a really nice way to secure that /usr/-stuff is
there (and also other stuff like /var...)
It is the *only* supported way, AFAIK...
As far as I understand - please correct me if I'm wrong - the root-fs is
just
On Sun, 18 Jul 2010, Henrique de Moraes Holschuh wrote:
On Fri, 16 Jul 2010, Christoph Anton Mitterer wrote:
Having $remote_fs is a really nice way to secure that /usr/-stuff is
there (and also other stuff like /var...)
It is the *only* supported way, AFAIK...
Erk. Look at $local_fs
On Mon, 14 Jun 2010, Brian May wrote:
On 14 June 2010 16:35, Marco d'Itri m...@linux.it wrote:
I believe that now we fixed ~everything which can be fixed, so this
leaves us with the proprietary Java implementation which apparently Sun
is unwilling to fix.
Is there software that still
(cc's dropped, sorry, I was in kernel ML netiquete mode).
On Wed, 30 Jun 2010, Juliusz Chroboczek wrote:
Henrique de Moraes Holschuh:
one probably has to mess with /etc/gai.conf
[...]
On a dual stack box and any application that does NOT work in ipv6only=1
mode, you likely have
On Thu, 01 Jul 2010, Juliusz Chroboczek wrote:
With bindv6only=0, a v6 socket bound to :: will not accept v4
connections, full stop. With bindv6only=0, connecting a v6 socket to
a v4-mapped address will not work, full stop.
That's obviously a typo -- I meant bindv6only=1.
Then, what
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 13 May 2010 22:33:25 -0300
Source: rng-tools
Binary: rng-tools
Architecture: source i386
Version: 2-unofficial-mt.13-2
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 13 May 2010 23:24:00 -0300
Source: rng-tools
Binary: rng-tools
Architecture: source amd64
Version: 2-unofficial-mt.13-3
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
On Sat, 20 Mar 2010, Florian Weimer wrote:
* Henrique de Moraes Holschuh:
2. Must be thread-safe, and fully reentrant both at the function and at
the _library_ level;
This does not include the async-signal-safe property, right? I'm also
not sure if the function needs to be reentrant
On Tue, 09 Mar 2010, Brian May wrote:
A number of packages, such as openldap have been changed to support
gnutls, instead of openssl, to avoid licensing issues in openssl.
However, it appears that gnutls uses libgcrypt, and libgcrypt has
several serious design issues.
1. libgcrypt doesn't
On Sat, 06 Mar 2010, Mike Hommey wrote:
/dev/something just feels so wrong. /dev contains block and character
devices, and almost nothing else (except some udev and initramfs files)
Not really. There's the whole /dev/shm crap (which one is not supposed to
access directly anyway).
Why should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 06 Mar 2010 10:02:41 -0300
Source: autotools-dev
Binary: autotools-dev
Architecture: source all
Version: 20100122.1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
On Fri, 19 Feb 2010, Michael Meskes wrote:
For the record, the watchdog daemon seems not to be able to deal with 1Hz
cleanly (must have something to do with these zombies it likes to keep
around for 1s) in my test boxes. It can do 0.5Hz just fine though.
The latest upload 5.7-4 or an
On Mon, 08 Feb 2010, Henrique de Moraes Holschuh wrote:
On Tue, 09 Feb 2010, Darren Salt wrote:
I demand that Guillem Jover may or may not have written...
On Mon, 2010-02-08 at 20:15:30 +0100, Michael Meskes wrote:
Please keep in mind the OOM killer will only influence watchdog
On Mon, 15 Feb 2010, Alexander Reichle-Schmehl wrote:
Dmitry E. Oboukhov schrieb:
I wish to use my country's flag to refer to my language...
Don't. There are many languages not associated with countries or in
use in many different countries. [..]
Is it really so big problem? Looks like as
On Tue, 09 Feb 2010, Michael Meskes wrote:
TOn Mon, Feb 08, 2010 at 11:44:55PM -0200, Henrique de Moraes Holschuh wrote:
And while at it, change wd_keepalive and watchdog to default to pat at 1Hz
instead of 0.1Hz. That will reduce a _lot_ the changes of spurious
reboots.
This looks like
On Tue, 09 Feb 2010, Michael Meskes wrote:
drivers have different defaults, and as far as I recall, some of them
default to whatever the BIOS or BMC programmed in the watchdog.
A period of 1s would be a much safer default on the userland side.
Okay, will change.
Thanks.
--
One
On Sun, 07 Feb 2010, David Bremner wrote:
On Mon, 08 Feb 2010 09:26:14 +1100, Ben Finney ben+deb...@benfinney.id.au
wrote:
With Bazaar, one doesn't need to rebase to achieve this. The ???loom???
plugin allows for tracking changes against upstream revisions, while
*preserving* the history
On Tue, 09 Feb 2010, Darren Salt wrote:
I demand that Guillem Jover may or may not have written...
On Mon, 2010-02-08 at 20:15:30 +0100, Michael Meskes wrote:
Please keep in mind the OOM killer will only influence watchdog if it
happens to kill it. If you happen to run out of memory though,
On Sun, 07 Feb 2010, Vincent Bernat wrote:
While git allows to keep track of modifications, it is difficult for
upstream (or some other people) to review a precise patch. Or maybe you
rebase master branch on the upstream one (which would be great to see
watch patches are applying to
On Sat, 06 Feb 2010, Marco d'Itri wrote:
On Feb 06, Henrique de Moraes Holschuh h...@debian.org wrote:
It got renamed to wdt_tco, I think, and it will hard-hang a lot of thinkpads
if it ever triggers, for example: the SMBIOS can't handle it.
OK, I will blacklist this one.
I'd rather we had
On Mon, 25 Jan 2010, Ivan Jager wrote:
On Mon, 25 Jan 2010, Thomas Koch wrote:
while searching the right way to use tmpfs for a few locations, I found this
howto:
http://forums.debian.net/viewtopic.php?t=16450
What do you think about this approach?
What's wrong with just putting it in
On Sat, 06 Feb 2010, Goswin von Brederlow wrote:
Convert to 3.0 (quilt) format and keep it out of git:
echo 3.0 (quilt) debian/source/format
echo debian/patches .gitignore
echo .pc .gitignore
And then to build you use (or pass it to git-buildpackage):
debuild --single-debian-patch
On Fri, 05 Feb 2010, Marco d'Itri wrote:
On Feb 05, Petter Reinholdtsen p...@hungry.com wrote:
do not remember any more details. This was discovered a few years
ago, and I hope that crazy driver has been fixed in the mean time.
So it looks like this *is* my fault, in my defense I can only
On Sat, 23 Jan 2010, Steve Langasek wrote:
On Sun, Jan 24, 2010 at 01:09:38AM +0100, Holger Levsen wrote:
On Samstag, 23. Januar 2010, jida...@jidanni.org wrote:
*** WARNING: ucf was run from a maintainer script that uses debconf,
but the script did not pass --debconf-ok to ucf. The
On Tue, 05 Jan 2010, Michael Gilbert wrote:
On Wed, 6 Jan 2010 11:01:01 +0800 Paul Wise wrote:
On Wed, Jan 6, 2010 at 9:20 AM, Kees Cook k...@debian.org wrote:
There is a maintained (by RedHat) patch for dealing with PIE. I already
It is perfectly reasonable to reject patches until
On Thu, 07 Jan 2010, Henrique de Moraes Holschuh wrote:
So, the question that needs an answer is: _why_ isn't it upstream yet?
And that has been answered in another part of this thread.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness
On Sun, 03 Jan 2010, William Pitcock wrote:
That was opposed quite strongly by the kernel folks last time it was
attempted. Were there any fundamental changes in the Xen dom0 patches
since then?
Only by the kernel folks which believe all of the crap that the KVM
guys say about Xen.
On Thu, 31 Dec 2009, Philipp Kern wrote:
On 2009-12-30, Henrique de Moraes Holschuh h...@debian.org wrote:
On Wed, 30 Dec 2009, Philipp Kern wrote:
You don't switch to v6-only, you switch to dual stack IPv4+IPv6. One point
being that with a v6-only host you're totally unable to reach IPv4
On Tue, 29 Dec 2009, Russ Allbery wrote:
If this is a real question, put:
127.0.1.1 fqdn nodename
I think we're having some sort of fundamental misunderstanding or
communications gap here. What FQDN do you think I should put there?
Should I just make something up, like
On Tue, 29 Dec 2009, Vincent Lefevre wrote:
On 2009-12-29 17:44:31 +0100, Milan P. Stanic wrote:
Mutt in testing/unstable use /etc/mailname.
But not the official Mutt version.
Who lets you configure the correct domain you want it to use for email
addresses in its config files, although I
On Wed, 30 Dec 2009, Henrique de Moraes Holschuh wrote:
In truth, my laptop *does not have an FQDN*. The concept has no useful
It must have, POSIX provided a way for apps to query it, and apps started
doing that. So you need one. It will be an arbitrary one, but that's fine.
Better
On Wed, 30 Dec 2009, Philipp Kern wrote:
You don't switch to v6-only, you switch to dual stack IPv4+IPv6. One point
being that with a v6-only host you're totally unable to reach IPv4 sites
without the help of application-level proxies.
That's false. You can use protocol-level gateways, which
On Tue, 29 Dec 2009, Ansgar Burchardt wrote:
there are several tools that generate C source code that is later
complied in object code, e.g. yacc, lex or valac. automake defaults to
distribute these built intermediate files, so they are usually not
regenerated during a build.
[...]
1. What
On Thu, 24 Dec 2009, Kees Cook wrote:
Anyway, I'd appreciate a bug report against amavisd-new with whatever
information is pertinent about PIE, if you guys want us to add it to the
package.
I already opened it in August when I added the patch for it in Ubuntu. :)
On Thu, 24 Dec 2009, Kees Cook wrote:
That's certainly a viable plan. This is kind of the approach we took in
Ubuntu for the PIE feature. We also considered packages with a less than
stellar security history. The list of packages built with PIE in Ubuntu
is: (see
On Wed, 02 Dec 2009, Norbert Preining wrote:
Actually I don't care. I have used python only for a small applet
that allows turning on/off rfkills (why is there nothing in the world
by now, strange, maybe I should package it for debian, but I have
On Wed, 02 Dec 2009, Norbert Preining wrote:
On Mi, 02 Dez 2009, Henrique de Moraes Holschuh wrote:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538389
Nice try, but I was talking about a GNOME/systray applet I wrote
so that you can click-point turning on/off the various hardwares.
Ah
On Wed, 02 Dec 2009, Norbert Preining wrote:
Just keep in mind that /dev/rfkill manipulates radios of a given _type_
as a group, and that an user could have many radios of the same type,
*Really*?? I was looking into the rfkill code since I reimplemented
the protocol in my python applet
On Thu, 26 Nov 2009, Nuno Paquete wrote:
Já percebi, para me tornar um desenvolvedor oficial preciso de uma chave
assinada. Mas por enquanto apenas quero começar a ganhar experiência em
projectos open-source, por isso pretendo pegar em um projecto órfão e
começar a trabalhar nele. Preciso de
On Sun, 22 Nov 2009, Raphael Hertzog wrote:
On Sun, 22 Nov 2009, Mike Hommey wrote:
My point is : dpkg-source -x should be idempotent, whatever other
packages are installed when you do it. The fact that you can't
dpkg-source -x, and *then* install quilt to manage the patches is a
On Fri, 06 Nov 2009, Peter Fritzsche wrote:
The output of `ld -v 2` is GNU gold (GNU Binutils for Debian 2.20) 1.9. So
it will catch the 1.9 here and just say hey, i am sure that you are
evil
which is of course wrong. So auto* stuff must be updated here. I will create
a
bug for
On Sat, 07 Nov 2009, Peter Fritzsche wrote:
Please understand me right. I don't have something against it, but I don't
know how to do it right and what autotool-gurus in Debian says about it.
Ok, /usr/share/doc/autotools-dev/README.Debian.gz tells me about it. It
doesn't mention a
On Thu, 29 Oct 2009, Kees Cook wrote:
On Thu, Oct 29, 2009 at 10:01:08PM -0200, Henrique de Moraes Holschuh wrote:
On Tue, 27 Oct 2009, Kees Cook wrote:
On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote:
On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
I would
On Thu, 29 Oct 2009, Christoph Anton Mitterer wrote:
On Tue, 2009-10-27 at 22:19 -0200, Henrique de Moraes Holschuh wrote:
Well, the issue raised in LKML is that you absolutely should *not* enable
-fstack-protector-all unless you _really_ know what you're doing, and most
certainly
On Tue, 27 Oct 2009, Kees Cook wrote:
On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote:
On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
I would like to propose enabling[1] the GCC hardening patches that Ubuntu
uses[2].
How do they work? Do they also change the
On Mon, 26 Oct 2009, Gabor Gombas wrote:
On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote:
On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
I would like to propose enabling[1] the GCC hardening patches that Ubuntu
uses[2].
How do they work? Do they also change
On Tue, 27 Oct 2009, Kees Cook wrote:
It seems the kernel will not be happy if the stack protector is switched
on unconditionally:
http://osdir.com/ml/linux-kernel/2009-10/msg07064.html
Indeed. The kernel build system needs to be able to command whether
stackprotect is enabled
On Sat, 17 Oct 2009, Marco d'Itri wrote:
I do not want to burden each and every Debian user just because a few
people tought it would be smart to build kernels without inotify(2) or
signalfd(2) support.
OTOH, we can bug upstream to move it to if EMBEDDED (assuming they're not
there already).
On Fri, 09 Oct 2009, Florian Weimer wrote:
* Gabor Gombas:
- start advertising that openjdk/icedtea is now supposed to be usable,
Note that the non-applet stuff has been quite usable for a while.
Even the openjdk-6 in lenny is not too bad (it's certainly possible to
run various production
On Sat, 26 Sep 2009, Russell Coker wrote:
On Mon, 7 Sep 2009, Gabor Gombas gomb...@sztaki.hu wrote:
The original announcement said that Fedora is already using upstart.
AFAIK Fedora is also commited to using SELinux. Do they use a similar
patch? Can they help convincing upstream?
In
Architecture: source all i386
Version: 2.2.13-17
Distribution: unstable
Urgency: high
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed-By: Henrique de Moraes Holschuh h...@debian.org
Description:
cyrus-admin-2.2 - Cyrus mail system - administration tools
cyrus-clients-2.2 - Cyrus
On Mon, 21 Sep 2009, Marc Haber wrote:
And people know that the package is built automatically. All users I
know especially opted in to using the package instead of freshclam for
some-or-other reason.
WHERE is that information published?
I don't see it in the package description, and I don't
On Mon, 21 Sep 2009, James Vega wrote:
On Mon, Sep 21, 2009 at 11:49 AM, Henrique de Moraes Holschuh
h...@debian.org wrote:
On Mon, 21 Sep 2009, Marc Haber wrote:
And people know that the package is built automatically. All users I
know especially opted in to using the package instead
On Sun, 20 Sep 2009, Marc Haber wrote:
As long as you do not expect me to manually sign every single upload,
Why not? It is a package, it has root access anywhere it is being installed
or removed. Even if you abuse the DM machinery to have a key restricted to
only upload clamav-data, it would
On Sat, 19 Sep 2009, Andreas Barth wrote:
* Pierre Habouzit (madco...@madism.org) [090919 01:08]:
I'll put blocks in my hint file to be sure that both those packages will
migrate in testing together (I'm unsure if britney is clever enough to
block them until all the binNMUs are done, I
On Sat, 12 Sep 2009, Frans Pop wrote:
As debmirror is a native package that may interest developers I thought a
quick announcement here is appropriate.
I uploaded version 2.2 earlier this morning. In comparison with the lenny
version, this introduces the following new features:
*
On Fri, 11 Sep 2009, Olivier Bonvalet wrote:
But combined with readahead, there is no I/O bound during init.
Most of needed files are preload.
Any initscripts that deal with devices will still be I/O bound. And the
current scheduler doesn't help (see current threads in LKML). You should
start
On Fri, 11 Sep 2009, Mike Hommey wrote:
Now, libxml2 is used a lot. A whole lot. My concern is that partial
upgrades can possibly leave people with an old libxml2 and newer
programs (they could even put themselves in this situation by pinning
some packages), in which case these warnings are
On Mon, 07 Sep 2009, Julien Cristau wrote:
On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
From what I can see in /lib/udev/rules.d, the ids files are only used to
setup
the (udev) environment variable ID_VENDOR_FROM_DATABASE
(75-net-description.rules,
On Mon, 07 Sep 2009, Steve Langasek wrote:
On Mon, Sep 07, 2009 at 02:59:44PM -0300, Henrique de Moraes Holschuh wrote:
On Mon, 07 Sep 2009, Julien Cristau wrote:
On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
From what I can see in /lib/udev/rules.d, the ids files are only
On Mon, 07 Sep 2009, Steve Langasek wrote:
On Mon, Sep 07, 2009 at 02:59:44PM -0300, Henrique de Moraes Holschuh wrote:
On Mon, 07 Sep 2009, Julien Cristau wrote:
On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
From what I can see in /lib/udev/rules.d, the ids files are only
On Mon, 07 Sep 2009, Josselin Mouette wrote:
Le lundi 07 septembre 2009 à 08:39 +0200, Petter Reinholdtsen a écrit :
I guess we were a bit unclear. The point is to use it for upgrades
(ie when it exist), while not installing /etc/inittab for new
installs, thus slowly getting rid of the
On Fri, 04 Sep 2009, Marco d'Itri wrote:
On Sep 04, Ron Johnson ron.l.john...@cox.net wrote:
Whatever the cause, it breaks the FHS.
Since it keeps being repeated, it is time to destroy this argument.
FHS documents what distributions want to do: of the other relevant
distributions,
On Mon, 07 Sep 2009, Michael Biebl wrote:
Henrique de Moraes Holschuh wrote:
So why exactly should we support this breakage in udev, again? If what it
takes is to move the usb and pci ID databases to /, so be it. When compared
to our kernel tarballs, they're small, less than 1MB for both
On Thu, 30 Jul 2009, Petter Reinholdtsen wrote:
[Matthias Klose]
Right. This seem to be a problem that need to be solved by the
compiler, and not by initscripts. Reassigning to gcc.
this has nothing to do with the compiler, which is built for a fixed
arch/tune setting.
Right. If
On Wed, 29 Jul 2009, Francesco P. Lovergine wrote:
At least in one case, I change the series file on-fly at building time
to create different flavors of the same lib with a different patchset.
I roughly suspect this is not compatible with the 3.0 format, but it
is also difficult to be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 23 Jul 2009 17:31:03 -0300
Source: autotools-dev
Binary: autotools-dev
Architecture: source all
Version: 20090611.1
Distribution: unstable
Urgency: low
Maintainer: Henrique de Moraes Holschuh h...@debian.org
Changed
On Tue, 21 Jul 2009, Russ Allbery wrote:
Giacomo A. Catenazzi c...@debian.org writes:
But probably for the shell cases it is easier to remove 'essential'
flag (especially for a minimal nearly POSIX-like shell like dash),
because the interface of #!/bin/sh is defined in policy (10.3).
On Sat, 18 Jul 2009, Harsha s.v. Banavasi wrote:
I have written device driver pgm in redhat linux with 2.4 kernel. it's
working fine. But now our boss asked me to install Debian OS with 2.6
kernel. I have install Debian 5.0 version with 2.6 kernel. But my Device
driver pgm is not working,
On Sun, 07 Jun 2009, Andres Mejia wrote:
List of space-separated globbing pathnames (see man 7 glob for more details)
indicating files that have the same licence and share copyright holders.
This doesn't take into account files or directories that may be named with
spaces.
Principle of
On Mon, 01 Jun 2009, Pierre Habouzit wrote:
Think again, if I do such a package, I would obviously check with some
kind of trivial perl programm if the device containing /usr/lib/rootkit
is mounted with nodev, would use mount -o remount,dev on the problematic
mount point in the preinst, let
On Mon, 11 May 2009, Goswin von Brederlow wrote:
A separate /usr *is* the way to go if you don't want any writes in
that filesystem 99.9% of the time (i.e. when you're not doing an
upgrade).
A read-only / does the trick just as well. And if you don't want
writes to /usr you probably
On Mon, 11 May 2009, Goswin von Brederlow wrote:
A read-only / should work out of the box just like a read-only /usr. I
haven't installed a fresh one in a long while though so if you know of
problems speak up so bugs can be filed and packages can be fixed.
Last time I tried it, /etc was a
On Fri, 08 May 2009, David Weinehall wrote:
No. But we do leave /usr read-only the rest of the time, which
is often 99.999% of the time. A separate /usr is required for this.
Uhm, no?
mount --bind /usr /usr
First, you'd need a RO bind mount (yes, it exists, but your command
On Thu, 07 May 2009, Josselin Mouette wrote:
Le jeudi 07 mai 2009 à 13:23 +0200, Harald Braumann a écrit :
No, please don't use an esoteric mailer. People who don't know and
don't want to know about their local mailer don't need to know about
Postfix' complexity. They can set up Postfix
On Thu, 07 May 2009, Ben Finney wrote:
Those who want a read-only ???/usr??? don't seriously try to leave it
read-only while installing or upgrading packages, do they?
No. And we hook apt to automatically remount stuff rw before it, and try to
remount ro after. It is easy, it works
601 - 700 of 1562 matches
Mail list logo
