Ian Jackson wrote:
> A. Open a new bug against policy, asking that 7.6.2 be replaced with
> something like this (exercising our power to specify what should
> be in policy):
>
> Secondly, Replaces allows the packaging system to resolve which
> package should be removed when
Raphael Hertzog wrote:
> On Fri, 21 May 2010, Ian Jackson wrote:
>>> Rename A to B | optional make A | Conflicts: A
>>> | dummy/transitional| Replaces: A
>>> | Depends: B | Provides: A optional
>>
>> I think this is rig
Hi,
Raphael Hertzog wrote:
> We have dpkg-buildflags available but few packages are using it and it's
> unlikely they will be all converted in the wheezy timeframe.
I agree with the precise meaning of this statement, but the spirit seems
quite wrong. For the packages I am involved in (not many)
dave b wrote:
> On 21 November 2010 02:45, Jonathan Nieder wrote:
>> Also, I am not the GCC maintainer, but from experience of receiving
>> reports from people building software with Ubuntu, I think changing
>> the defaults in GCC is quite wrong.
>
> Why do you think
reassign 622837 tech-ctte
quit
Ludovic Rousseau wrote:
> Le 15/04/11 10:40, Jonathan Nieder a écrit :
>> - if users of the library will crash or otherwise fail if pcscd
>>is not installed, mentioning that in the package description;
>
> The library functions would
Hi again,
The following is not strictly speaking about the same bug, so dropping
Bug#622837 from the cc list.
Ludovic Rousseau wrote:
> Le 15/04/11 22:04, Don Armstrong a écrit :
>> 3) Why is there a versioned Recommends: on an exact version pcscd?
>
> Because libpcsclite1 and pcscd use an ad-ho
Ludovic Rousseau wrote:
> The protocol version is exchanged as the first message.
Ah, that's a comfort.
> The ABI between pcscd and libpcsclite is not used by any other
> software I know. And should not be used by other components. It is an
> internal ad-hoc protocol.
As is that.
>> One (ugly?
reassign 614907 tech-ctte
quit
Dear Technical Committee,
The "node" and "nodejs" packages both provide a command named "node".
The command in the node package is in /usr/sbin; the command in nodejs
is in /usr/bin. Both are very important commands that are widely used
in their respective communit
(replying to debian-ctte@ only to avoid spamming innocent readers of
debian-hams et al)
Jonathan Nieder wrote:
> I'd be happy to talk about work so far, transition plans,
> complications and possible ways forward in a separate message.
Ok, let's start with what I think is the l
# proposed patch only solves part of the problem
tags 614907 - patch
quit
Jonathan Nieder wrote:
> I'd be happy to talk about work so far, transition plans,
> complications and possible ways forward in a separate message.
I personally am not too worried about the people who will suf
Ian Jackson wrote:
> Jonathan Nieder writes ("Bug#614907: nodejs/node command conflict: reasons to
> include the command in each package"):
>> There is a transition plan and patch for the (ham radio) node in
>> #614907. Nobody has been able to demonst
Jonathan Nieder wrote:
> I'd be happy to talk about work so far, transition plans,
> complications and possible ways forward in a separate message.
Ok, the hard part: how can we change a command's name so smoothly that
the user does not notice anything has happened?
For LinuxNod
(culling cc list since there were noise complains from debian-hams@)
Russ Allbery wrote:
> It's interesting that Fedora has nodejs, and I think we should also
> provide nodejs and encourage people to use that name, but I think it would
> be best for our users to also provide node.
For the record,
Jonathan Nieder wrote:
> I'd be happy to talk about work so far, transition plans,
> complications and possible ways forward in a separate message.
This seems like a long shot, but the maintainers of both packages
seemed to like it, so let's give mentioning it a try:
Assuming we
Jonathan Nieder wrote:
> I'd be happy to talk about work so far, transition plans,
> complications and possible ways forward in a separate message.
After all this conversation with tentative agreements[1], why hasn't a
transition to a new command name started? I think this goes
Steve Langasek wrote:
> Clint Byrum has nudged me about this (wearing his Ubuntu Server hat rather
> than his shiny new Debian Developer hat) and I've agreed to approach node.js
> upstream about a possible upstream rename. I'll report back to the TC what
> I find out.
Best of luck. You know the
Hi Steve,
Steve Langasek wrote:
> On Thu, May 03, 2012 at 04:23:21PM -0500, Jonathan Nieder wrote:
>> Best of luck. You know they've been asked twice before (once for Fedora,
>> once for Debian), right?
>
> No, didn't know that. Were these requests public
Hi Russ,
Russ Allbery wrote:
> I believe at this point the dpkg-buildflags solution has proven reasonably
> successful and is being widely deployed. I think we should confirm that
> the TC agrees with that approach and close out this bug.
While I understand that the PR effect would be good, I e
Russ Allbery wrote:
> Why?
No strong reason. The tech-ctte is free to decide any matter of
technical policy they choose to, so there's no constitutional reason
to go the way I was suggesting.
Since it sounds like you've thought about this carefully already,
I'm satisfied. Sorry for the noise.
Ian Jackson wrote:
> Patrick Ouellette writes:
>> I got called a passive aggressive, stonewalling individual not interested in
>> moving the issue forward.
>
> I agree that no-one should be calling anyone names. IIRC Jonathan has
> already retracted those insults but I can't seem to find his mess
Carsten Hey wrote:
> it would be reasonable for the nodejs maintainers to stop working
> on implementing your ruling after the hamradio node has been renamed and
> to tell users to use backports after the Wheezy release.
I hope you are not serious.
Jonathan
--
To UNSUBSCRIBE, email to de
Russ Allbery wrote:
> Actually, it could ship in the regular shared library path. It would just
> change its SONAME a lot, which would be fine, since no other applications
> would link against it and therefore no one would really care. And indeed
> it would probably have to be in the public sear
Hi,
Russ Allbery wrote:
> Things that I don't think are TC issues:
>
> * Whether desktop files should be documented in Policy at all.
For what it's worth:
* I was unhappy with the patch at http://bugs.debian.org/707851 and
said so. I didn't object when people seconded it and applied it
Hi again,
Russ Allbery wrote:
> So, I think the questions before the TC are:
>
> 1. Should programs that make sense in the context of a typical DE (I
>realize there's some fuzziness around this) all have desktop files?
Ah, I completely misread this before as saying "menu files" instead of
"d
Hi Charles,
Charles Plessy wrote:
>In particular, in the absence of
> Bill's contribution to the resolution of our conflict, I am asking the TC to
> not discuss the menu systems and focus instead on correcting Bill's
> misbehaviour.
>
> What is at a sta
25 matches
Mail list logo
