Re: Draft GR for permitting private discussion

[Stefano Zacchiroli]

On Tue, Jul 17, 2012 at 10:17:34AM -0700, Russ Allbery wrote:
> I probably should save this for the main discussion in -vote or -project,

Let's do that, and sorry for dropping this here, but having mentioned it
to Ian before, I didn't want for any of you to wait indefinitely for my
comment. So feel free to go ahead with the broader discussion when you
please.  I'll postpone comments to the broader discussion, but let me
point out a counterargument.

> The current wording, read literally, means that if I happened to run into
> Steve Langasek, say, at a social occasion, I am not permitted to mention
> network-manager and GNOME to him, because that conversation isn't public
> and that's an issue currently before the technical committee.

I would agree that if yours here is the common interpretation of the
current wording of the Constitution, then we have a problem. (It is not
*my* reading, but that's meaningless.) I don't think that anyone would
want to inhibit private discussions to happen at all. But I do think
people would expect them to be reported ex-post.

If you accept such a principle, you can have all the private discussions
you want at conferences with Steve and on a private usenet hierarchy
with Colin, as long as we agree on the fact that those discussions are
reported publicly where appropriate (e.g. in the relevant tech-ctte bug
log). FWIW, I know this is actually hard to do, after having noted down
on random notepads "discussed $something with $someone" over the past 3
years of FOSS conferences :-)

Note the above is nothing new and is just consistent with the well known
mantra that most Free Software projects try to apply that "if it didn't
happen on a mailing list, it didn't happen".

I think the above principle would address your infeasibility concern.
(OTOH I don't have at the moment specific answers to your comparisons
with how other similar decision making bodies work in other contexts.)

Cheers.
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Bug#681687: missing mime entry

[Neil McGovern]

Hi,

On Tue, Jul 17, 2012 at 11:45:42PM +0200, Michael Biebl wrote:
> If a missing mime file would mean an RC bug, this would instantly make
> 514 packages RC buggy.
> Interestingly, the particular section in the Debian policy is a should
> directive, not a must, so I don't understand the reasons for making
> #658139 RC.
> 

For info, I do not consider all packages missing a mime file to be RC
buggy. I consider #658139 RC.

> Creating and keeping those mime files up-to-date is probably okay if you
> maintain a single package or you need some of the special features that
> mime-support provides. It adds up though, if you maintain multiple
> packages. As maintainers time is limited and valuable I'd rather see it
> spent for really important issues and simply get the patch in [1]
> applied to mime-support which auto-generates those mime entries for
> legacy apps which don't yet support the xdg mime spec [2].
> 

As I understand it, there are still a number of issues with this
approach (.desktop files do not contain enough information to get
argument ordering correct in all cases, and it's far too late to start
using a new auto-generation system this late in the cycle).

I also disagree that
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23658139#29 is
justification for this bug.

There is a two line patch that reintroduces this file, and will not
cause issues for the eventual solution (when it finally exists) that the
maintainer prefers. Deliberately breaking functionality because the
maintainer a) doesn't agree with policy and/or wants to use the package
as a stick for others to do work does not to me seem to be the correct
action to take.

Neil
-- 


signature.asc
Description: Digital signature

Re: Bug#681834: network-manager, gnome, Recommends vs Depends

[Philipp Kern]

On Wed, Jul 18, 2012 at 01:55:03AM +0100, Ian Jackson wrote:
> Experiemnts reported on debian-devel show that this `tight coupling'
> is more a matter of doctrine than an actual hard functional
> dependency.
> 
> Indeed on two of our platorms network-manager isn't even supported, so
> it is just left out of the gnome-core metapackage!

I don't think that this is a valid argument given various comments of the
Debian GNOME maintainers that GNOME on kfreebsd is broken. (But if there's no
user and hence continuous testing there will be no bugs being reported.)

I saw Michael arguing specifically that people focus on removing functionality
that does not exist on kfreebsd to make it built, but that nobody actually
tries the result. I see the arch-specific depends on network-manager of the
gnome-core metapackage in the same way. It must be installable on kfreebsd to
migrate because it's considered a blocker from a britney/testing point of view.

Kind regards
Philipp Kern 


signature.asc
Description: Digital signature

Re: Bug#681419: Alternative dependencies on non-free packages in main

[Goswin von Brederlow]

On Tue, Jul 17, 2012 at 12:22:13PM +0100, Ian Jackson wrote:
> Goswin von Brederlow writes ("Re: Bug#681419: Alternative dependencies on 
> non-free packages in main"):
> > On Fri, Jul 13, 2012 at 09:59:33PM +0100, Ian Jackson wrote:
> > > How about instead we think about what the real issue is.  The FSF's
> > > view AIUI is that they want to avoid recommending (in the broadest
> > > sense) non-free software.  I think this is a reasonable objection, and
> > > it is one that we should be able to find some way to resolve.
> > 
> > I disagree there. The dependencies in a packages metadata are a technical
> > means of ensuring the software works.
> 
> I think we are actually mostly in agreement.  I certainly agree that
> there is a distinction between technical implementation and UI
> presentation and that we're probably mostly worried about the latter.

Indeed.

> > > It seems to me that there are two possible ways to do this:
> > > 
> > >  - Somehow change the package metatdata so that the reference to the
> > >non-free package lives in the non-free repo.
> 
> I wrote this alternative not because I thought it was a good idea but
> because it was logically possible and therefore it was necessary to
> discuss it.  But this...
> 
> > Depends: non-free/foo?
> > Depends: foo-non-free?
> > Depends: foo {non-free}?
> 
> ...isn't in that category.  What I was talking about was this:
>   
>Package: foo
>Recommends: bar
> 
>Package: bar
>Section: barthingies
> 
>Package: bar-nonfree
>Section: nonfree/barthingies
>Do-Some-Weird-Thing: bar.Recommends =~ s/bar/bar | bar-nonfree/
>
> This would be logically possible but I think it would be a bad idea.
> 
> But in many cases this could be achieved with:
> 
>Package: bar-nonfree
>Section: nonfree/barthingies
>Provides: bar
> 
> which would avoid the need for these out-of-main references.

Indeed. EXCEPT Provides is not versioned. And even if it where the
main package might require a certain version of the non-free package
for it to be an alternative to the free one. That can't be mapped with
a versioned provides.

So to preserve the expressiveness we have now you would indeed need some

   Do-Some-Weird-Thing: bar.Recommends =~ s/bar/bar | bar-nonfree/

which I hope nobody will ever implement.
 
> > >  - Change the packager UI, websites, etc. which interpret this data
> > >for users to not show references to non-free when they aren't
> > >wanted.
> > 
> > How is the UI to know what is non-free? Without the first change or
> > unless the admin has enabled non-free the package metadata does not
> > give any clue what packages are non-free. And if non-free isn't
> > wanted then why would anyone add it to sources.list?
> 
> As I wrote earlier:
> 
>   I think this is a real problem.  In general people sometimes find that
>   they need to enable non-free for some particular reason (perhaps even
>   just too make their nic work or something).   That shouldn't mean
>   that their system becomes tainted willy-nily with non-free stuff.

I think you misunderstood.

If you have non-free enabled then packages from non-free are known and
known to be non-free accodring to the packages section.

The problem arises when you don't have non-free enabled. Then a
dependency on non-free looks just like any dependency on a
non-existant package. How should the UI decide which packages are
simply non-existant and which are non-free and need to be hidden?
 
> > So your two options don't apear to be "OR"s but appear to be an "AND".
> 
> If the metadata available to the package manager were sufficient, it
> could avoid using unwanted non-free dependency arms.
> 
> Ian.


But to respond to your point:

>   I think this is a real problem.  In general people sometimes find that
>   they need to enable non-free for some particular reason (perhaps even
>   just too make their nic work or something).   That shouldn't mean
>   that their system becomes tainted willy-nily with non-free stuff.

With non-free enabled the UI could handle non-free packages
differently based on the section being non-free/*. I agree that it
probably is a good idea to have the UI search for solutions that don't
add non-free packages to the system. That is a matter of scoring and
shouldn't be too hard to do.


But I've thought of another thing that might be usefull. Non-free has
all kinds of software in it with different licensing terms. Which
basically means to do the right thing you have to read the licensing
for each to see weather you can agree with it or not.

We already have tools to present the user with bugreports, the NEWS
file and Changelog before installing a package with apt(itude). Why
not add another tool (apt-list-non-free?) that displays the copyright
file for any new non-free package and asks the user if that is
acceptable.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscri

Bug#614907: [Pkg-mediawiki-devel] [Pkg-javascript-devel] Bug#680080: Invalidated by dependency: Excuse for mediawiki-extensions

[Thorsten Glaser]

On Tue, 10 Jul 2012, Thorsten Glaser wrote:

> > Right now I am waiting for the judgement of the tech-ctte regarding 
> > nodejs.  See bug#614907.
> 
> Ah. Luckily, that’s almost resolved.

It has been resolved for days now, would please someone
implement the solution? I can, as offered previously, help.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-314
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Boris Esser, Sebastian Mancke


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.2.02.1207181403400.10...@tglase.lan.tarent.de

Bug#614907: [Pkg-mediawiki-devel] [Pkg-javascript-devel] Bug#680080: Invalidated by dependency: Excuse for mediawiki-extensions

[Ian Jackson]

Thorsten Glaser writes ("Bug#614907: [Pkg-mediawiki-devel] 
[Pkg-javascript-devel] Bug#680080: Invalidated by dependency: Excuse for 
mediawiki-extensions"):
> On Tue, 10 Jul 2012, Thorsten Glaser wrote:
> > Ah. Luckily, that’s almost resolved.
> 
> It has been resolved for days now, would please someone
> implement the solution? I can, as offered previously, help.

If this needs an NMU then that's fine; I'd be happy to sponsor it if
necessary.

Ian.


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20486.48107.436332.523...@chiark.greenend.org.uk

Re: Draft GR for permitting private discussion

[Kurt Roeckx]

On Wed, Jul 18, 2012 at 10:31:15AM +0200, Stefano Zacchiroli wrote:
> > The current wording, read literally, means that if I happened to run into
> > Steve Langasek, say, at a social occasion, I am not permitted to mention
> > network-manager and GNOME to him, because that conversation isn't public
> > and that's an issue currently before the technical committee.
> 
> I would agree that if yours here is the common interpretation of the
> current wording of the Constitution, then we have a problem. (It is not
> *my* reading, but that's meaningless.) I don't think that anyone would
> want to inhibit private discussions to happen at all. But I do think
> people would expect them to be reported ex-post.

I have no problem interpreting "are made public" to mean that a
summary is send to the list.


Kurt


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120718162445.ga26...@roeckx.be

Bug#682010: [mumble] Communication failures due to CELT codec library removal

[Chris Knadle]

Package: tech-ctte
Severity: normal


Greetings to the technical committee.

This refers to Bug #675971 (which is severity grave, and currently closed)
against the Mumble VoIP package, which is also affected by Bug #674650
concerning the removal of the CELT library.  This evening we also just
discovered the existence of Bug #674634 which concerns the CELT library
removal as well, and which may have more of the technical story.


Summary of the technical dispute


Point of view of bug reporters (text via collaboration of two reporters):

  Background:
  --

- Mumble upstream uses and requires a particular baseline audio codec
  (CELT 0.7.1, a fairly old version), the availability of which is a
  base assumption used by most Mumble servers.

- CELT's upstream has a planned transition to the standardized Opus
  codec, and Mumble plans to follow suit, but that transition won't
  complete until all clients and servers support Opus, and that will take
  a while.  (Also, current upstream support for Opus remains a work in
  progress, and they don't have a released version with non-buggy
  support for Opus yet; the current version in Debian has some
  cherry-picked patches from upstream's VCS, but that doesn't help
  non-Debian users.)

- CELT audio Codec library has been removed from Debian by the maintainer,
  which with Mumble today is causing audio to fail outright for many public
  servers as well as several prior versions of mumble-server from Debian.
  [This has also been a problem for several other audio packages and
   maintainers.]

- On newer Mumble server versions, the audio connection fails if another
  client connects that requires using CELT, because all connected clients
  require using a common Codec.

- The newest -2 upload contains this issue.  [Mentioned because the
  maintainer reported that the -2 upload fixes the bug.]

- There is no warning in the NEWS.Debian file to warn users of the
  package that only the Opus Codec is usable and how that impacts the
  usability of the package

- The bug is repeatedly being closed by the maintainer if it was fixed,
  without discussion.  [Josh Triplett has since tagged the bug "wontfix",
  which is at least an improvement, but this RC-level bug remains closed
  as is being forced by the maintainer, which will presumably allow the -2
  package with this issue to migrate to Wheezy and release with Stable.]

  Desired:
  ---

- From the point of view of the bug reporters, what we want is a
  package that inter-operates with other Mumble clients and servers,
  if possible.  To do this today would require reintroducing the celt
  source package again, which is rumored to have potential security issues.
  [We have not seen any details on this yet.]

  Note: this evening we think we have found a security expert who is
  willing to audit the CELT 0.7.1 codec for issues and possibly provide
  patches, assuming this is reasonably feasible.

- Assuming an inter-operable package is not possible, as a backup what
  we want is for the bug to be handled correctly in some way, and that
  users of the package have an opportunity to be notified of what
  limitations the package has.

  Possible options:
  

- Leave mumble out of testing and wheezy, keep it in either unstable
  or experimental (as we would for any client-server software with an
  unstable protocol that we can't support for the lifetime of a stable
  release), reintroduce CELT library for use with Mumble with security
  warnings in the description and NEWS.Debian concerning potential issues.

- Let mumble 1.2.3-349-g315b5f5-2 migrate to testing and release with
  wheezy without the CELT library, with compatibility warnings in
  NEWS.Debian. Possibly reintroduce (or at least allow the use of) a CELT
  codec library for Mumble in Unstable or Experimental which could allow
  users to use the CELT codec library with Mumble, with a warning in
  NEWS.Debian for the celt package to warn of potential issues.

- Similar to the item above, but with the CELT library in an external
  repository.

- Some other alternative we haven't thought of.



Point of view of the maintainer (as understood by reporters thus far, as
  no reply was given in several days in query for this summary):

- Someone the maintainer trusts said the CELT library contains code that
  could potentially be a crash vulnerability, among other unfixed issues

- Nobody is committing to maintaining and taking responsibility for celt
  0.7.1, or has sufficient spare time and/or the requisite knowledge to
  fully investigate this further.

- It was decided to remove the CELT library as to not burden the security
  team, and it has been an effort to get the library removed

- The mumble client that we currently have will only inter-operate with
  clients that have Opus support

- Upstream is eventually planning on dropping CELT anyway

- This isn't a bug, so it should be closed, and there is no ne

Re: Draft GR for permitting private discussion

[Michael Gilbert]

On Wed, Jul 18, 2012 at 12:24 PM, Kurt Roeckx wrote:
> On Wed, Jul 18, 2012 at 10:31:15AM +0200, Stefano Zacchiroli wrote:
>> > The current wording, read literally, means that if I happened to run into
>> > Steve Langasek, say, at a social occasion, I am not permitted to mention
>> > network-manager and GNOME to him, because that conversation isn't public
>> > and that's an issue currently before the technical committee.
>>
>> I would agree that if yours here is the common interpretation of the
>> current wording of the Constitution, then we have a problem. (It is not
>> *my* reading, but that's meaningless.) I don't think that anyone would
>> want to inhibit private discussions to happen at all. But I do think
>> people would expect them to be reported ex-post.
>
> I have no problem interpreting "are made public" to mean that a
> summary is send to the list.

Since I've been the "loudest" on this, I also fully agree with this
perspective.  I don't think matters need to be so black and white that
off-list discussions would be disallowed.

Even a summary as simple as "Hey, , , and I briefly discussed
 matter at _ forum, but we didn't really come to any new ideas
or conclusions," would often be enough to satisfy our openness ideals.
 Although more substantive summaries should be produced for
discussions that come to real conclusions.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=mmzw3esjcfw0mdgf8jx7gdawgjnf2yadhwvqj001w8...@mail.gmail.com

Re: Draft GR for permitting private discussion

[Russ Allbery]

Kurt Roeckx  writes:
> On Wed, Jul 18, 2012 at 10:31:15AM +0200, Stefano Zacchiroli wrote:

>> I would agree that if yours here is the common interpretation of the
>> current wording of the Constitution, then we have a problem. (It is not
>> *my* reading, but that's meaningless.) I don't think that anyone would
>> want to inhibit private discussions to happen at all. But I do think
>> people would expect them to be reported ex-post.

> I have no problem interpreting "are made public" to mean that a
> summary is send to the list.

I don't believe this is feasible, or at least, it's not feasible for me.
I've tried to do that off and on for years now at work, since it would
have often been a useful skill, to both participate in a verbal discussion
and take notes about that discussion.  I've sadly reached the firm
conclusion that, while there may be people who are capable of both taking
notes and participating in a discussion at the same time, I'm not one of
them.  I can do one or the other, but not both.

I can try to reconstruct a summary from memory, but it's not going to be
"discussion [...] made public on the Technical Committee public discussion
list."  It's likely to be very partial, full of gaps, and not reflect the
complete content of the discussion.  (Well, at least for the verbal
discussions.  Obviously, a Usenet discussion is amenable to summary.)

I think this is why, if you look at procedures for other organizations
that require deliberations to be made public, that requirement is only
placed on formal meetings and is done via either having an appointed
secretary who doesn't participate in the discussion and whose only job is
to record the notes, or by enforcing a meeting structure that makes people
stop talking at intervals long enough for the secretary to record what
happened.

>> Note the above is nothing new and is just consistent with the well
>> known mantra that most Free Software projects try to apply that "if it
>> didn't happen on a mailing list, it didn't happen".

I am not familiar with any free software project that bans private
discussion or requires that the discussion be reported on the mailing
list.  Not even the IETF does this, and they're one of the strictest about
requiring all formal process happen on the mailing lists.

This appears to be a social experiment unique to Debian.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gu1nem8@windlord.stanford.edu

Re: Draft GR for permitting private discussion

[Steve Langasek]

On Wed, Jul 18, 2012 at 01:18:27PM -0400, Michael Gilbert wrote:
> On Wed, Jul 18, 2012 at 12:24 PM, Kurt Roeckx wrote:
> > On Wed, Jul 18, 2012 at 10:31:15AM +0200, Stefano Zacchiroli wrote:
> >> > The current wording, read literally, means that if I happened to run into
> >> > Steve Langasek, say, at a social occasion, I am not permitted to mention
> >> > network-manager and GNOME to him, because that conversation isn't public
> >> > and that's an issue currently before the technical committee.

> >> I would agree that if yours here is the common interpretation of the
> >> current wording of the Constitution, then we have a problem. (It is not
> >> *my* reading, but that's meaningless.) I don't think that anyone would
> >> want to inhibit private discussions to happen at all. But I do think
> >> people would expect them to be reported ex-post.

> > I have no problem interpreting "are made public" to mean that a
> > summary is send to the list.

> Since I've been the "loudest" on this, I also fully agree with this
> perspective.  I don't think matters need to be so black and white that
> off-list discussions would be disallowed.

> Even a summary as simple as "Hey, , , and I briefly discussed
>  matter at _ forum, but we didn't really come to any new ideas
> or conclusions," would often be enough to satisfy our openness ideals.
>  Although more substantive summaries should be produced for
> discussions that come to real conclusions.

I don't think that's a reasonable requirement at all.  Why would you not
just assume that whenever members of the TC meet, they've spoken about
outstanding issues, instead of expecting TC members to engage in this kind
of busywork?  It's not like we're talking about secret ballots here, and on
the other hand it's not like any solution is going to give perfect knowledge
of the members' thought processes!  So what's the point of demanding
documentation every time we talk, when that won't materially alter the
project's visibility into the process?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120718180924.gc11...@virgil.dodds.net

Bug#681834: network-manager, gnome, Recommends vs Depends

[Steve Langasek]

On Wed, Jul 18, 2012 at 01:48:01AM +0100, Ian Jackson wrote:
> Michael Biebl writes ("Bug#681834: network-manager, gnome, Recommends vs 
> Depends"):
> > We thus tried a compromise, where the network-manager postinst script
> > automatically comments out dhcp-type connections in /e/n/i (and restores
> > them, in case the package is removed again,fwiw).

> So just to be clear: consider the case where a user has deliberately
> violated the Recommends in squeeze from gnome to network-manager, and
> now upgrades to wheezy.  They will get network-manager back via the
> hard dependency from gnome-core.  Presumably they don't want to
> deinstall `gnome', so they don't have a choice about that.

> If their networking is using a dhcp entry in /etc/network/interfaces,
> the result of installing n-m will be that this entry will be commented
> out.  So the networking will break.

I don't see how this follows.  If n-m has been newly installed and is in
proper working order, and it sees that there's a trivially-configured
network interface in /e/n/i that it can take over, and it does so, how does
networking break?

And if it breaks, shouldn't we consider that a release critical bug in NM in
its own right, to be fixed for wheezy, regardless of whether NM is being
pulled in by default on upgrade?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120718182255.gd11...@virgil.dodds.net

Bug#681834: network-manager, gnome, Recommends vs Depends

[Ian Jackson]

Steve Langasek writes ("Bug#681834: network-manager, gnome, Recommends vs 
Depends"):
> I don't see how this follows.  If n-m has been newly installed and is in
> proper working order, and it sees that there's a trivially-configured
> network interface in /e/n/i that it can take over, and it does so, how does
> networking break?

Well, two ways: firstly, because the user has been told very
vigorously by the maintainers that if they didn't want n-m, they
should disable it rather than removing the package.  If they follow
this advice the result will be that n-m took over their network
interface, and then took it down when it was disabled.

Secondly, it is possible for dhcp entries to be non-trivial.  They may
specify interesting scripts to be run, dhcp options, bridging, etc.
It's not clear to me exactly which of these scenarious result in
what outcome.

Simply not installing the package clearly has the right outcomes and
is obviously the best technical solution to the requirement not to use
n-m.  There is no technical advantage in having n-m installed when the
user doesn't want to use it.

We are only having this conversation at is because the gnome upstream
and maintainers want n-m installed on people's systems for doctrinal
reasons.  Doctrinal reasons are not good reason IMO.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20487.11609.939946.221...@chiark.greenend.org.uk

Bug#681834: network-manager, gnome, Recommends vs Depends

[Michael Biebl]

On 18.07.2012 23:40, Ian Jackson wrote:

> Secondly, it is possible for dhcp entries to be non-trivial.  They may
> specify interesting scripts to be run, dhcp options, bridging, etc.
> It's not clear to me exactly which of these scenarious result in
> what outcome.

NM doesn't take over any such entries which have more complex options.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Bug#681834: network-manager, gnome, Recommends vs Depends

[Noel David Torres Taño]

Hi ctte

I just wanted to bring here an argument that came in debian-devel: the one 
that says that n-m does not play well with usb0 type network interfaces [1].

I have not tested this myself, since I do not use a laptop and do not need an 
USB network gadget on my desktop, so I can not confirm it. But if it is true, 
it means that gnome chained hard dependency on network-manager is not even 
suitable for laptops when they need to resort to USB network cards.

Another issue that has come across the discussion is about network-manager 
being deinstalled means n-m enabled applications break. As far as I know, n-m 
aware applications all have a fallback mode. My (personal) use case against 
network-manager is that I use pidgin, which is n-m aware, and I use a 
networking configuration with static interfaces (I use a static IP at home). 
If n-m is installed and running, pidgin does not work since it thinks there is 
no usable network. Deinstalling n-m (dpkg -P in my case) fixs it without 
needing to restart it, you just need to disable and reenable accounts. update-
rc.d will do the same, but I see no point of having an unused software 
installed, but it comes it again on any aptitude run (together with the option 
of pulling gnome and al its related packages out). Also in my personal use 
case, n-m messing with /e/n/i is not an issue since I do not have interfaces 
that can get hijacked by n-m, but as it has been shown in this list, some 
people can have that concern.

Regards

Noel Torres
er Envite

[1] https://lists.debian.org/debian-devel/2012/07/msg00471.html


signature.asc
Description: This is a digitally signed message part.

Re: duplicates in the archive

[Ian Jackson]

Josselin Mouette writes ("Re: duplicates in the archive"):
> Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit : 
> > What's wrong with Recommends: in that case?  It seems to perfectly
> > match the "makes life easier for  > XXX>" scenario you describe.
> 
> Recommends is wrong for metapackages because it gets upgrades very
> wrong. This is why it is used very marginally.

Could you please explain this in more detail in the specific case of
gnome-core and network-manager ?  I'm not sure I understand the
problem.

Thanks,
Ian.


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20487.16739.688176.814...@chiark.greenend.org.uk

Re: duplicates in the archive

[Ian Jackson]

Ian Jackson writes ("Re: duplicates in the archive"):
> Josselin Mouette writes ("Re: duplicates in the archive"):
> > Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit : 
> > > What's wrong with Recommends: in that case?  It seems to perfectly
> > > match the "makes life easier for  > > XXX>" scenario you describe.
> > 
> > Recommends is wrong for metapackages because it gets upgrades very
> > wrong. This is why it is used very marginally.
> 
> Could you please explain this in more detail in the specific case of
> gnome-core and network-manager ?  I'm not sure I understand the
> problem.

In particular I've just read the message from Adam Borowski replying
to you, which I will bounce to the TC list.  Is Adam wrong ?

Thanks,
Ian.


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20487.16823.624317.28...@chiark.greenend.org.uk

Re: duplicates in the archive

[Adam Borowski]

On Tue, Jul 10, 2012 at 03:32:43PM +0200, Josselin Mouette wrote:
> Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit : 
> > What's wrong with Recommends: in that case?  It seems to perfectly
> > match the "makes life easier for  > XXX>" scenario you describe.
> 
> Recommends is wrong for metapackages because it gets upgrades very
> wrong. This is why it is used very marginally.

In the general case, yes.  This needs to be fixed.  But it's not relevant
here because squeeze had network-manager-gnome already.  So we have three
scenarios:

* a new install.  Recommends will pull in n-m unless explicitely rejected.

* upgrade from squeeze (or earlier sid).  Network-manager-gnome will be
  upgraded if present, and if it has been removed, that was not without a
  cause.

* debfoster/aptitude/"apt-get autoremove".  Recommends will keep n-m-g safe
  from autoremoval.

The problem with recommends is that they fail to pull in *new* relationships
of an existing package, this is not what's the case here.

> > A hard package-dependency in a case like this, when there isn't
> > actually any hard functional dependency, and there are issues with the
> > depended-upon package, are decidedly user-unfriendly.
> 
> It is unfriendly to the extreme minority of users who want a specific
> selection of packages rather than the default metapackages.

So you call people who want to connect a smartphone an "extreme minority"?
The last time I checked, it's hard to find a person without one.  USB
cables seem to be more popular than wall chargers, and a good part of phones
can transfer data over them.  It also gets you an order of magnitude better
transfer speed than wifi, and you don't have wifi everywhere.

Folks who want to connect more than one machine via a VPN are also not that
rare among Debian users.  Or ones with a bridged setup.  Those are more
technical, yeah, but:

> Accidentally these are the users who also have the ability to make their
> own package selection.

except that unless you sit deeply in Gnome development, you don't know which
exactly components you need.  This is precisely what a metapackage is for. 
Am I supposed to know by heart whether the file manager is called "nautilus"
or "caja" this week?  Or what do I need to install to have clicking an image
show me its contents?

-- 
Copyright and patents were never about promoting culture and innovations;
from the very start they were legalized bribes to give the king some income
and to let businesses get rid of competition.  For some history, please read
https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623


signature.asc
Description: Digital signature

mumble and celt, #682010, TC

[Ian Jackson]

(Please would others avoid CCing debian-release@ and security@, who
are probably very busy and don't want to get tons of argument in their
mailboxes.)

The problem with mumble and the celt codec has been referred to the TC
- see the bug mentioned above.  I would be interested to hear from the
security and release teams.

We are told that the problem is that current sid's mumble is not
capable of talking to most other instances of mumble, because the
transition to the very new opus codec is still underway.

(mumble is a voice chat program commonly used by both gamers and
conference organisers etc.; I've seen it used at Ubuntu meetings and
also used it myself for online games.  It's a useful alternative to
some well known and awkward proprietary programs.)

In particular:

 * Do the security team have an opinion about the celt 0.7.1 codec?
   Would you want to impose any conditions for it to be included
   in wheey ?

 * Would the release team be happy with a reintroduction for wheezy of
   the celt package containing the 0.7.1 codec ?  I don't know yet
   whether mumble would need to be updated too.  Obviously this would
   have to be done promptly.

Obviously it would have been better for this all to have been raised
before the release.  Unfortunately the discussions amongst the
participants seem to have become very personal and the matter has only
just now been raised with the TC.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20487.17820.235900.900...@chiark.greenend.org.uk

Bug#681687: Bug#658139: missing mime entry

[Michael Biebl]

On 18.07.2012 11:14, Neil McGovern wrote:
> Hi,
> 
> On Tue, Jul 17, 2012 at 11:45:42PM +0200, Michael Biebl wrote:
>> If a missing mime file would mean an RC bug, this would instantly make
>> 514 packages RC buggy.
>> Interestingly, the particular section in the Debian policy is a should
>> directive, not a must, so I don't understand the reasons for making
>> #658139 RC.
>>
> 
> For info, I do not consider all packages missing a mime file to be RC
> buggy. I consider #658139 RC.

And what is the reason that makes evince special and distinguishes it
from other packages which never shipped a mime file or no longer do?
Your decision seems arbitrary.
mime files were removed across the board from the GNOME packages a long
time ago.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#682010: [mumble] Communication failures due to CELT codec library removal

[Ian Jackson]

Chris Knadle writes ("Bug#682010: [mumble] Communication failures due to CELT 
codec library removal"):
> Package: tech-ctte
> Severity: normal
...
> This refers to Bug #675971 (which is severity grave, and currently closed)
> against the Mumble VoIP package, which is also affected by Bug #674650
> concerning the removal of the CELT library.  This evening we also just
> discovered the existence of Bug #674634 which concerns the CELT library
> removal as well, and which may have more of the technical story.

Thanks for this, including the clear summary.

> - From the point of view of the bug reporters, what we want is a
>   package that inter-operates with other Mumble clients and servers,
>   if possible.  To do this today would require reintroducing the celt
>   source package again, which is rumored to have potential security issues.
>   [We have not seen any details on this yet.]
> 
>   Note: this evening we think we have found a security expert who is
>   willing to audit the CELT 0.7.1 codec for issues and possibly provide
>   patches, assuming this is reasonably feasible.

This sounds like a good option to me.  I will write to the security
team and ask them for their opinion about CELT.

>From what you say I think:

 - We should try to address the security problems, if any, in the celt
   0.7.1 codec.  An audit would be very good.

 - This is a serious problem for mumble at least and is arguably RC.

Do you have people who are willing to be the maintainer(s) and (if
necessary) sponsor(s) for the celt package ?

I assume it would be possible to reintroduce a celt package which was
very similar to the one recently removed, so as to avoid risking
unnecessary bugs.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20487.17269.635854.516...@chiark.greenend.org.uk

Bug#681687: missing mime entry

[Ian Jackson]

Neil McGovern writes ("Bug#681687: missing mime entry"):
> As I understand it, there are still a number of issues with this
> approach (.desktop files do not contain enough information to get
> argument ordering correct in all cases, and it's far too late to start
> using a new auto-generation system this late in the cycle).

Yes.

I don't think it likely that the TC will want to overrule the Release
Team's decision on this point.

So I hereby propose the following TC resolution:

  1. The Technical Committee agrees with Neil McGovern's analysis of
 the situation regarding evince's missing mime type entry.

  2. If changes are desirable to our system for dealing with mime
 type entries and desktop files, including changes to policy or
 additional automation, these should be made via the usual
 development and policy amendment processes.  It is now too
 late to do this for wheezy.

  3. We do not disagree with the Release Team's assessment that
 the failure of the evince package to provide a mime type
 entry is a release critical bug.

  4. We therefore decline to overrule the Release Team.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20487.18427.710930.229...@chiark.greenend.org.uk

Processed: block 675971 by tech-ctte 682010

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reopen 675971
Bug #675971 {Done: Ron } [mumble] Cannot communicate with the 
vast majority of Mumble servers due to lack of required baseline codec
Bug reopened
Ignoring request to alter fixed versions of bug #675971 to the same values 
previously set
> found 675971 1.2.3-349-g315b5f5-2
Bug #675971 [mumble] Cannot communicate with the vast majority of Mumble 
servers due to lack of required baseline codec
Ignoring request to alter found versions of bug #675971 to the same values 
previously set
> # block on tech-ctte bug report
> block 675971 by 682010
Bug #675971 [mumble] Cannot communicate with the vast majority of Mumble 
servers due to lack of required baseline codec
675971 was not blocked by any bugs.
675971 was not blocking any bugs.
Added blocking bug(s) of 675971: 682010
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
675971: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675971
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.134266300321898.transcr...@bugs.debian.org

Re: Bug#682010: [mumble] Communication failures due to CELT codec library removal

[Chris Knadle]

On Wednesday, July 18, 2012 19:15:01, Ian Jackson wrote:
> Chris Knadle writes ("Bug#682010: [mumble] Communication failures due to 
CELT codec library removal"):
> > Package: tech-ctte
> > Severity: normal
> 
> ...
> 
> > This refers to Bug #675971 (which is severity grave, and currently
> > closed) against the Mumble VoIP package, which is also affected by Bug
> > #674650 concerning the removal of the CELT library.  This evening we
> > also just discovered the existence of Bug #674634 which concerns the
> > CELT library removal as well, and which may have more of the technical
> > story.
> 
> Thanks for this, including the clear summary.

You're welcome.  Thanks very much for looking into this.

> > - From the point of view of the bug reporters, what we want is a
> > 
> >   package that inter-operates with other Mumble clients and servers,
> >   if possible.  To do this today would require reintroducing the celt
> >   source package again, which is rumored to have potential security
> >   issues. [We have not seen any details on this yet.]
> >   
> >   Note: this evening we think we have found a security expert who is
> >   willing to audit the CELT 0.7.1 codec for issues and possibly provide
> >   patches, assuming this is reasonably feasible.
> 
> This sounds like a good option to me.  I will write to the security
> team and ask them for their opinion about CELT.

I agree this is a good idea.

> From what you say I think:
>  - We should try to address the security problems, if any, in the celt
>0.7.1 codec.  An audit would be very good.

The professional security expert I've been put in contact with has begun 
having a look at the CELT codec.  [I'll ask if he is okay with being named.]  
This is the most relevant portion of his initial response:



CELT's git repository shows the last significant burst of activity
was in April of 2011. The last commit confirms upstream is EOLed.

commit e18de7747fb1655e66bf8d291560587036bfe53c
Author: Ralph Giles 
Date:   Wed Sep 14 12:23:04 2011 -0700

Direct users at the opus repository.
   
This repository is no longer used for active development.

[…]
Currently, I'm trying to collect as much information as possible on
libcelt.  I will be reading the API documentation to get a feel for the
architecture / call-graph.  Also interested in any example code that
decode CELT packets; this will give me an idea of which
structs/functions to fuzz.  Any rumours of crashes, unresolved bug
reports or coredumps also helps the bug hunt.  Finally, I will read every
single line looking for insecure code patterns. :)



>  - This is a serious problem for mumble at least and is arguably RC.

Yes I think I agree.  I just reopened #675691 and blocked by #682010 to keep 
the bug marked RC for now.

> Do you have people who are willing to be the maintainer(s) and (if
> necessary) sponsor(s) for the celt package ?

I have not attempted to discuss aspect this with anyone yet.  Of the people 
I've been working with concerning the technical issues of the bug report so 
far, AFAIK none of us are DMs nor DDs.

I've been doing some learning and successful packaging work in preparation for 
attempting to upload through [debian-mentors] but have not tried to upload to 
them yet, nor packaging of a library.  [Maybe I'm just chicken.  :-P]  However 
in the spirit of good faith and Debian do-ocracy I'll volunteer to maintain or 
co-maintain unless someone with more experience would like to do it.  If I end 
up being maintainer it will likely mean going through [debian-mentors] -> 
sponsor -> NEW queue -> ftpmasters -> Debian Unstable unless another DD 
volunteers to review the prospective package and sponsor.

Additionally if we plan to re-introduce the CELT library, maintainers that had 
packages using CELT need contacting if an opportunity is to be given for those 
packages to be [un]patched to re-add CELT support again desired.  This would 
naturally depend on getting CELT uploaded and accepted, which is where having 
a DD take over maintainership and upload would save time.

Additionally the Mumble client in 1.2.3-349-g315b5f5-2 will not use the CELT 
library even if it is installed, which means that the mumble package will 
require [un]patching for this as well if CELT support is to be made available 
again.

> I assume it would be possible to reintroduce a celt package which was
> very similar to the one recently removed, so as to avoid risking
> unnecessary bugs.

It looks like that would probably work.  The current celt source package uses 
individual debhelper calls with compat level 5 and is not multi-arch aware; 
I'm wondering if multi-arch support is something worth considering at this 
stage.  The current celt source package from Wheezy (via apt-get source) 
builds and seems to function correctly, appears to be piuparts clean, but has 
some lintian warnings to look into [see below] -- and some autoconf r

Bug#681783: Are Recommends really important (especially for metapackages)?

[Andrei POPESCU]

On Ma, 17 iul 12, 12:35:20, Steve Langasek wrote:
> 
> > 1. Is running a system with Recommends turned off a supported 
> > configuration?
> 
> I don't think it's really useful for the Tech Ctte to try to declare whether
> or not something is a "supported" configuration.  What is supported is up to
> the individual maintainers or to Debian as a whole.
> 
> It would better fit within the scope of the committee to ask whether a
> particular package relationship should be a Depends or a Recommends, or what
> the policy should be for use of Depends vs. Recommends generally.

Yes, a general policy would probably address my question.

> I do have a definite opinion of my own on this question.  If you are
> applying --no-install-recommends to your entire system, you are working
> contrary to the intended purpose of Policy, which says:
> 
>   The `Recommends' field should list packages that would be found
>   together with this one in all but unusual installations.
> 
> To avoid the installation of *all* recommends by default is to ignore the
> purpose of recommends:  namely, to list packages that *should* be installed
> by default, but that the admin *may* remove from the system /if they know
> what they're doing/.  The admin who ignores all recommends and leaves them
> off the system can't possibly know what they're doing; they're not making an
> informed decision that the Recommends are not needed on their installation.
> 
> So an admin who has passed --no-install-recommends to apt should not be at
> all surprised if some functionality they care about is missing.

I fully agree, and this (plus Ian's answer) is pretty much what my own 
impression is and what I had expected. But this is not reflected in user 
or developer oriented documentation (except Policy, of course). I'll be 
filing (wishlist) bugs for debian-reference, apt (apt-get(8)), aptitude 
(aptitude(8)) and so on.
 
> > It seems quite a few Debian Developers consider this rather a supported, 
> > normal configuration, and not a customized, special purpose one. 
> > Apparently, as a consequence, there is a tendency of having stronger 
> > than necessary package relationships.
> 
> The TC could certainly rule on specific cases of this if asked.  But the
> debate about whether --no-install-recommends is sane is a very old one, and
> I don't think the TC giving a position statement on this is likely to
> influence those who insist on ignoring the meaning of policy.

My intention was for you to give Maintainers a sort of backup for cases 
where others may disagree with a weaker dependency.

> > Based on this rationale, packages should not use Depends unless the 
> > given package as provided by Debian is unusable (e.g. it would crash) 
> > without the depended package. An obvious example would be an application 
> > and it's libraries.
> 
> I think there is flexibility here in how the maintainer draws the line
> between Depends and Recommends.  "is unusable" is not exactly the line that
> Policy draws.
> 
>   The `Depends' field should be used if the depended-on package is
>   required for the depending package to provide a significant
>   amount of functionality.
> 
> There's a certain amount of maintainer judgement inherent in this
> definition, which I think is appropriate.

Sure, leaving some space for individual Maintainers makes sense, but 
"significant amount of functionality" is quite wide. Wouldn't something 
like "to function properly" be better? (I'm sure this has been debated a 
lot, so I'll be researching this on first occasion. Would appreciate 
some bug numbers though if you have them handy)

> > Circular Recommends (or Depends/Recommends) relationships should also be 
> > avoided if technically feasible, as this renders the autoremoval feature 
> > of package managers almost useless.
> 
> That would be a bug in the package manager's detection of auto-installed
> packages, nothing more.

Ok, I've just found #655483, I'll be following that.

> > If you agree that by disabling Recommends the system administrator 
> > assumes responsibility for the lack of possibly important
> > functionality that may even lead to breakage (e.g. rsyslog only 
> > Recommends: logrotate), this may need a coordinated effort to 
> > write/adjust some documentation (manpages of package managers, Debian 
> > Reference, Developer's Reference, Release Notes and possibly others). I 
> > am willing to help in this regard as much as time allows during the 
> > following release cycle.
> 
> What documentation, specifically, do you see that needs adjusting here? 
> Debian Policy is IMHO already quite clear on this, and all other maintainer
> documentation is secondary to policy.
> 
> > 2. Are Depends appropriate for metapackages?
> 
> Given the way you've worded the question here, I think the answer is
> definitely "yes".
> 
> However, I think that Recommends are *also* appropriate for metapackages.

I think it makes sense to wait fo