Package: apt
Version: 1.4.8
Severity: important
I tried to install a package which is documented to exist and that install
attempt consistently failed (though apt seems to work normally most of the rest
of the time):
# apt-get install php-imagick
Reading package lists... Done
Building
I apologize for not voting, but while I generally concur with
the voted decision, I have not had time to study any of
our issues in any depth these last couple weeks.
Thanks,
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
On 3/12/07, Steve Langasek [EMAIL PROTECTED] wrote:
Hmm -- if it's the RMs' call, I guess that means Andi and I both are
required to abstain from any vote on this (Constitution 6.3.2). Is it still
ok for me to call for a vote? :) (FWIW, as RM the decision I consider to
have made is defer to
On 10/31/06, Goswin von Brederlow [EMAIL PROTECTED] wrote:
* Person C creates a driver knowing with properly names defines and
comments explaining why he does what and where to easily readable
structures of the register mappings of the hardware. Person C then
goes and obfuscates the code into
On 8/30/06, Roberto Gordo Saez [EMAIL PROTECTED] wrote:
I strongly disagree with your arguments. It looks that we have
opposite way of thinking, so I will not reply to them, it is going to
nowhere. Don't worry, as I said, I won't continue searching for this.
When conversations go nowhere, it's
Package: wnpp
There's a bug more than a year old about a new upstream
version available for cipe, with no discussion from the maintainer
as to why this new version has not been incorporated. The
package should probably be orphaned, so that someone who
is more interested can maintain the
I'm not sure what you're asking.
Ideally, I'd like to see three things:
(1) A concise description of the technical conflict that needs to be resolved.
(2) Good background material for understanding any subtle issues
underlying the conflict.
(3) A concise, specific and unambiguous proposal for
On 4/3/06, Steve Langasek [EMAIL PROTECTED] wrote:
Raul suggested in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342455;msg=15 that policy
should also be amended to spell out the permissions for disk devices -- do
we need to include text here which addresses that directly?
Perhaps the
On 3/7/06, Sven Luther [EMAIL PROTECTED] wrote:
On Tue, Mar 07, 2006 at 07:20:31PM +0100, Jonas Smedegaard wrote:
Please see http://wiki.debian.org/LinuxKernelIdeProblem that I created
today and have invited the kernel team and udev developers to improve
on.
An assembly of patent ...
It
On 2/27/06, Margarita Manterola [EMAIL PROTECTED] wrote:
On 2/21/06, Raul Miller [EMAIL PROTECTED] wrote:
1 open source windows driver available (can be used with ndiswrapper)
Well, I couldn't find any trace of 1 ever happening. If it ever
happened, then it's ok. But as far as I know
On 2/21/06, Margarita Manterola [EMAIL PROTECTED] wrote:
On 2/20/06, Raul Miller [EMAIL PROTECTED] wrote:
As a specific counter example, consider
http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page
which is a project porting a windows driver to linux. This port
appears to be possible
On 2/21/06, Ian Jackson [EMAIL PROTECTED] wrote:
Raul Miller writes (Bug#353277: ndiswrapper in main):
It looks to me as if the sequence of events was:
1 open source windows driver available (can be used with ndiswrapper)
2 someone ports windows driver to linux
3 linux driver available
On 2/20/06, Robert Millan [EMAIL PROTECTED] wrote:
I requested that ndiswrapper and ndiswrapper-modules-i386 be moved to contrib.
This proposal is clear enough.
My reasons are:
- The sole purpose of these packages is allowing the use of non-free Windows
drivers.
- There are no free
On 2/20/06, Anthony Towns aj@azure.humbug.org.au wrote:
AFAICS, this would come under the overrule a developer (3:1 majority)
power.
That's a good point.
While there are technical issues here (such as: what software does ndiswrapper
depend on?), they are not the deciding issues. The core
On 2/10/06, Bastian Blank [EMAIL PROTECTED] wrote:
On Fri, Feb 10, 2006 at 04:40:22PM -0800, Steve Langasek wrote:
Otherwise, having access to the underlying block devices means having access
to meddle with anything on the LVM devices as well.
And who says that anyone have access to the
On 2/10/06, Ian Jackson [EMAIL PROTECTED] wrote:
Raul Miller writes (Re: #342455):
On 2/10/06, Ian Jackson [EMAIL PROTECTED] channelled:
The proposed change to devmapper changes the permissions for all block
devices, doesn't it ? Whereas the other debian defaults vary from one
kind
On 2/10/06, Steve Langasek [EMAIL PROTECTED] wrote:
... follow-up to self: given that crypt-dm sits on top of devmapper, it is
indeed plausible that one would want to prevent members of group disk from
reading the decrypted volume.
So don't use group disk in that context.
Just because a
On 2/10/06, Ian Jackson [EMAIL PROTECTED] channelled:
The proposed change to devmapper changes the permissions for all block
devices, doesn't it ? Whereas the other debian defaults vary from one
kind of device to another. For example, floppies are g+w floppy.
The change to devmapper is
On 2/10/06, Roger Leigh [EMAIL PROTECTED] wrote:
I did read this, and I'm happy progress is being made. However, the
default is still currently wrong in unstable, and the fix is a simple
change to configure in debian/rules.
I agree that the devmapper default should match other
debian
On 2/2/06, Roger Leigh [EMAIL PROTECTED] wrote:
It's nearly a month since the last mail to this bug. Is this getting
close to being resolved?
Did you notice the content of the message before yours in this bug's
history? It's from Bastian Blank, and includes among other things the
statement:
On 12/23/05, Bastian Blank [EMAIL PROTECTED] wrote:
Anyway, what are the problems with a default of 666? It fixes any
of the problems.
Is this a serious question?
Access to group disk can be easily controlled by the
system administrator. On some systems, only root
has this access, on other
Is there anything more to be said about the devmapper group/permissions issues?
I've gone into this assuming that I've overlooked something important,
but so far I've not seen anything that makes me think that there's any
good reason for this conflict.
Does anyone have any credible reason why
On 12/17/05, Bastian Blank [EMAIL PROTECTED] wrote:
On Fri, Dec 16, 2005 at 02:43:29PM -0500, Raul Miller wrote:
On 12/16/05, Bastian Blank [EMAIL PROTECTED] wrote:
On Wed, Dec 14, 2005 at 01:54:45PM +, Ian Jackson wrote:
Are you saying that the current default permissions on (eg
On 12/16/05, Bastian Blank [EMAIL PROTECTED] wrote:
On Wed, Dec 14, 2005 at 01:54:45PM +, Ian Jackson wrote:
Are you saying that the current default permissions on (eg) /dev/hda*
are insecure and therefore wrong ?
Yes, I overwrite them on my machines.
And what is your reason for being
I've been looking at these bugs, and I can see no good reason for the 600
permissions, nor the reason to avoid using the disk group.
There also seems to be some huge confusion about where responsibility for
setting permissions and group should be handled.
Here's what I currently see suggested:
On 12/5/05, Nathanael Nerode [EMAIL PROTECTED] wrote:
It's very old, Branden can't reproduce it, and if you the submitter can't,
perhaps it should be closed.
I can't reproduce it.
Yeah, it should probably be closed.
Thanks,
--
Raul
I think I have a working fix for this bug. However, the disk with my
secret key on it is bad, so I can't upload at the moment. I'll try to
address this monday evening.
For now, here's my approach.
(A) In debian/rules change the build target, inserting the following just
before touch
This is a copy of the text I included on the re-assign message. I'm
re-posting it so that it's more visible.
Note that my proposed solution for libsilc will almost certainly require
the use of epoch, and the present naming and numbering scheme
for libsilc is not very useful.
=
The
On 8/30/05, Robert McQueen [EMAIL PROTECTED] wrote:
Raul Miller wrote:
It's not clear to me why this was assigned to the technical committee.
The problem is that the maintainer refuses to concede that his packages
are in violation of Debian's shared library packaging policy, or
believes
On 8/14/05, Debian Bug Tracking System [EMAIL PROTECTED] wrote:
reassign -1 tech-ctte
Bug#323035: libslc violates library policies
Bug reassigned from package `libsilc' to `tech-ctte'.
It's not clear to me why this was assigned to the technical committee.
There's definitely some issues here.
On 6/12/05, Christian Perrier [EMAIL PROTECTED] wrote:
Honestly, I'm having hard times to make my own mind and I need help
and wise advice on that issue. I personnally tend to favor the
current choice of only one prompt, but this is definitely not a strong
position.
Is this true even after
On 6/9/05, Christian Perrier [EMAIL PROTECTED] wrote:
Some people have argued this does against all established practices in
such matter. Others have argued that the way to install a system is a
very specific way and that, after all, the password confirmation is
not *mandatory* to have the
On 5/27/05, Michael K. Edwards [EMAIL PROTECTED] wrote:
On 5/27/05, Matthijs Kooijman [EMAIL PROTECTED] wrote:
That's correct; and, with or without that dependency, OpenTTD
infringes the copyright on Transport Tycoon Deluxe under a mise en
scene theory, as discussed on debian-legal.
33 matches
Mail list logo
