Processed: Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

2021-07-20 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> archive 978636
Bug #978636 {Done: Sean Whitton } [tech-ctte] move to 
merged-usr-only?
archived 978636 to archive/36 (from 978636)
> thanks
Stopping processing here.

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



Processed: Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

2021-07-20 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> unarchive 978636
Bug #978636 {Done: Sean Whitton } [tech-ctte] move to 
merged-usr-only?
Unarchived Bug 978636
> thanks
Stopping processing here.

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



Bug#976462: marked as done (tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?)

2021-05-12 Thread Debian Bug Tracking System
Your message dated Wed, 12 May 2021 20:53:43 +0100
with message-id 
and subject line Re: Bug#976462: tech-ctte: Should dbgsym files be compressed 
via objcopy --compress-debug-section or not?
has caused the Debian Bug report #976462,
regarding tech-ctte: Should dbgsym files be compressed via objcopy 
--compress-debug-section or not?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
976462: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976462
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte

Dear members of the technical committee

I am asking for you provide advice or make a decision according
Constitution 6.1.3 on the matter of whether dbgsym files should use file
level compression or not.

I intend to use the outcome of this bug to determine how to resolve
#922744 (either by implementing the request or closing it as wontfix).


A bit of context:
=

Since compat 9 (released in 2012-01-15), debhelper has compressed
detached dbgsym files using objcopy's option --compress-debug-section.
This was implemented in debhelper/8.9.10 in order to resolve #631985.

When -dbgsym packages was implemented several years later, I used
--compress-debug-section in the implementation as it was the default for
modern compat levels at the time.

Then on 2019-02-20, Matthias Klose filed the bug #922744, in where
Matthias (in my reading of the subject) effectively requests that
debhelper stopped using --compress-debug-section, which would overturn
the request in #631985.

The underlying arguments for and against --compress-debug-section appear
 to be "download size" vs. "installed disk usage" vs. "Tooling support".
 Though I ask you to please read the bugs #631985 and #922744 for the
details of the arguments by both proponents.


I have _not_ involved any of the parties/stakeholders in this nor heard
there arguments.  Please see "Why punt it to you?" for why.


Why punt it to you?
===

I am punting this to you because:

 1. As stated in #922744, I am largely not emotionally invested in the
result.  Though I admit having reservations on how the solution is
implemented (see "Non-solutions").

 2. I am certain I do _not_ have the spoons and emotional capacity for
resolving this in the best way for Debian (as opposed to the "least
discussion/work for me" solution).  This has kept me from opening
the debate with relevant stakeholders.

 3. I do not want #922744 to rot forever in the bug tracker (which is
frankly what is happening now).

Given the nature of the underlying problem is technical, then I thought
it was best to rely on you.  My other alternative would be to throw it
at debian-devel but given point 2 in my list above that seemed like it
would be counterproductive for me.


My intentions for implementations:
==

If the advice/decision is to stop using --compress-debug-section then I
intend to retroactively undo the change for all compat levels (affecting
compat 9+) after the next release (to avoid disrupting the current release).
  It is my understanding that nothing relies on a 100% coverage of
compressed dbgsyms as we never got to a 100% in Debian yet.
Furthermore, most compilers do not compress debug sections by default,
which means that most tools will need to support uncompressed debug
sections to be useful.


If the advice/decision is to keep using --compress-debug-sections, I am
tempted to just leave the implementation as-is and slow migrate the rest
of the packages as the old compat levels are phased out.


I am open to changes/advice to alternative solutions for implementation
(though please see "Non-solutions") - these alternatives can be
presented anyone (including members of the tech-ctte in their private
capacity[1]).


Non-solutions:
=-=-=-=-=-=-=-

I do _not_ think we will be better served with compression being
something you opt-in/opt-out from based on a command-line option (or a
field in debian/control).  I think debhelper has way too many
"special-case" options or toggles where people have to do case-by-case
decisions already and I would see this as "yet another one".

You may choose this as a solution but then I require you to overrule me
as a maintainer using 6.1.4 with a 3:1 supermajority in the decision.

Thanks for your time,
~Niels


[1] I do not expect a full decision cycle/vote just to propose an
alternative.  But also, I do not want 6.3.5 getting in the way of a
better solution th

Bug#975075: marked as done (tech-ctte: Should NetworkManager support elogind?)

2021-03-17 Thread Debian Bug Tracking System
Your message dated Wed, 17 Mar 2021 18:03:09 +0100
with message-id 
and subject line Closing as this has been resolved without the TC needing to 
intervene
has caused the Debian Bug report #975075,
regarding tech-ctte: Should NetworkManager support elogind?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
975075: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975075
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: tech-ctte
Control: block 921012 by -1
Control: block 964139 by -1
X-Debbugs-CC: debian-init-divers...@chiark.greenend.org.uk

Dear Technical Committee,

This bug report relates specifically to bugs in the network-manager 
package (#921012, #964139) but has broader implications, particularly 
around what it means to "support the efforts of developers"[0] working 
on support for alternative init systems (I will talk about sysvinit here 
without loss of generality to other non-systemd init systems).


In brief:

#921012 is about changing network-manager to Depend upon "default-logind 
| logind" rather than libpam-systemd


#964139 is about restoring the removed network-manager init script which 
was removed from the package. There is no suggestion that the init 
script was buggy


Both changes are necessary for it to be possible to install 
network-manager on a sysvinit system; it is going to be hard to use 
Debian without network-manager.


Both bugs have sat open for extended periods with no input from the 
maintainer; so I prepared an NMU and uploaded it to DELAYED/14 as well 
as making an MR on salsa[1].


The NMU was declined, on the basis that removing the init script was not 
a mistake; I'm not aware of any rationale being provided beyond that for 
refusing either patch.


I'm afraid the effect of this is that the maintainers of this package 
are making it impossible for other developers to enable support of 
sysvinit. There are people[2] who will (and have) test compatibility 
changes, help with issues with sysvinit scripts, and so on, but those 
efforts are in effect being stonewalled.


The effect of this, and equivalent behaviour in some other packages, is 
that it is going to be impossible to make a useful Bullseye for users 
who want to use sysvinit.


I (and a couple of other interested parties) have approached the DPL 
about this matter on a number of occasions this year, and have tried to 
follow their advice where possible. I regret that it has proved 
necessary to involve the technical committee.


I invite the technical committee to rule that:
* The network-manager init script should be restored
* Network-manager should Depend: on default-logind | logind rather than 
libpam-systemd
* Similar init-compatibility changes should not be blocked by package 
maintainers unless they are defective on their own merits

* These changes be made in time to be effective in Bullseye

Regards,

Matthew

[0] From the wording of the winning option in the 2019 Init systems GR
[1] https://salsa.debian.org/utopia-team/network-manager/-/merge_requests/7
[2] e.g the mailing list debian-init-divers...@chiark.greenend.org.uk of 
people who are more than happy to help with this sort of thing
--- End Message ---
--- Begin Message ---

Hi,

It's been a while since this bug was dealt with and I was tasked with 
closing

it, I'm sorry that it took so long to write this reply.

The technical committee declines to overrule the NetworkManager and 
udisks2

maintainer on this matter.

Instead, by working together with the maintainer of the affected 
packages, we
managed to achieve a compromise solution: the dependency on 
libpam-systemd was
lowered to a recommends so that it's still possible to install the 
package
without it, while a separate package was introduced to carry the removed 
init

scripts.

This compromise solution allows users of other init systems to still use
network-manager and udisks2, without imposing additional work on the 
maintainer

to support those other systems.

As has been mentioned in the bug, this compromise was achieved through 
private
discussions between the technical committee and the maintainer. We 
recognize

that these kind of private discussions are not ideal and can lead to
frustration on the side of those that just hear about the results of the
discussions without being able to participate in them. On the other 
hand, we
also recognize that some maintainers have been burned out by some 
particularly

contentious issues, and would rather not discuss them publicly.

In the general case, the Technical Committee urges u

Bug#985270: marked as done (Resignation + Call for votes for new Chair)

2021-03-17 Thread Debian Bug Tracking System
Your message dated Wed, 17 Mar 2021 17:53:52 +0100
with message-id <75c1fb4bb327a12d30b2e12db7f35...@debian.org>
and subject line Re: Bug#985270: Resignation + Call for votes for new Chair
has caused the Debian Bug report #985270,
regarding Resignation + Call for votes for new Chair
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
985270: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985270
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte

[Resending as a bug rather than a mailing-list email. Sorry!]

Dear TC members,

As is traditional when committee members change, I am calling for the election
of a new Chair of Debian Technical Committee by announcing my resignation as
chair effective one week from now. In accordance with Section 6.1.7 of the
Debian Constitution, the vote runs until all members have voted, or until my
resignation takes effect.

The ballot is the following:

===BEGIN===

The chair of the Debian Technical Committee will be:

 A : Margarita Manterola
 B : David Bremner
 C : Niko Tyni
 D : Gunnar Wolf
 E : Simon McVittie
 F : Sean Whitton
 G : Elana Hashman
 H : Christoph Berg

===END===

-- 
Regards,
Marga


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---


Congrats Sean, wishing you luck with what's to come :).

Here's the output of the pocket-devotee run (already pushed to git as 
well).


Starting results calculation at Wed Mar 17 16:49:22 2021

/--ABCDEFGH
V: 61245337 marga
V: 13232214 bremner
V: 11121113 spwhitton
V: 11121113 gwolf
V: 41333245 ehashman
V: 24543126 ntyni
V: 1123 myon
V: 3124 smcv
Option A "Margarita Manterola"
Option B "David Bremner"
Option C "Niko Tyni"
Option D "Gunnar Wolf"
Option E "Simon McVittie"
Option F "Sean Whitton"
Option G "Elana Hashman"
Option H "Christoph Berg"

In the following table, tally[row x][col y] represents the votes that
option x received over option y.

  Option
  A B C D E F G H
===   ===   ===   ===   ===   ===   ===   ===
Option A3 3 5 4 1 1 8
Option B  2   3 4 3 2 2 8
Option C  2 1   4 2 1 2 8
Option D  2 0 1   2 0 1 8
Option E  2 2 1 4   0 1 8
Option F  4 4 4 8 5   4 8
Option G  1 2 2 5 4 1   8
Option H  0 0 0 0 0 0 0



Looking at row 2, column 1, B
received 2 votes over A

Looking at row 1, column 2, A
received 3 votes over B.



  Option A defeats Option B by (   3 -2) =1 votes.
  Option A defeats Option C by (   3 -2) =1 votes.
  Option A defeats Option D by (   5 -2) =3 votes.
  Option A defeats Option E by (   4 -2) =2 votes.
  Option F defeats Option A by (   4 -1) =3 votes.
  Option A defeats Option H by (   8 -0) =8 votes.
  Option B defeats Option C by (   3 -1) =2 votes.
  Option B defeats Option D by (   4 -0) =4 votes.
  Option B defeats Option E by (   3 -2) =1 votes.
  Option F defeats Option B by (   4 -2) =2 votes.
  Option B defeats Option H by (   8 -0) =8 votes.
  Option C defeats Option D by (   4 -1) =3 votes.
  Option C defeats Option E by (   2 -1) =1 votes.
  Option F defeats Option C by (   4 -1) =3 votes.
  Option C defeats Option H by (   8 -0) =8 votes.
  Option E defeats Option D by (   4 -2) =2 votes.
  Option F defeats Option D by (   8 -0) =8 votes.
  Option G defeats Option D by (   5 -1) =4 votes.
  Option D defeats Option H by (   8 -0) =8 votes.
  Option F defeats Option E by (   5 -0) =5 votes.
  Option G defeats Option E by (   4 -1) =3 votes.
  Option E defeats Option H by (   8 -0) =8 votes.
  Option F defeats Option G by (   4 -1) =3 votes.
  Option F defeats Option H by (   8 -0) =8 votes.
  Option G defeats Option H by (   8 -0) =8 votes.


The Schwartz Set contains:
 Option F "Sean Whitton"



-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The winners are:
 Option F "Sean Whitton"

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
Regards,
Marga--- End Message ---


Bug#982987: marked as done (tech-ctte: Call for votes for new CTTE member)

2021-02-24 Thread Debian Bug Tracking System
Your message dated Wed, 24 Feb 2021 11:17:22 -0600
with message-id <20210224171722.ga4080...@mosca.iiec.unam.mx>
and subject line Re: Bug#982987: tech-ctte: Call for votes for new CTTE member
has caused the Debian Bug report #982987,
regarding tech-ctte: Call for votes for new CTTE member
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
982987: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982987
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal

Given that Philip Hands' term in the Technical Committee finished in
December, I want first of all to thank him on behalf ot the rest of
the Committee members for his good work during the term, and call for
votes to accept a new TC member.

So, voting will begin now, and end when the outcome is no longer in
doubt, or one week from now.

===BEGIN

The Technical Committee recommends that Christoph Berg  be
appointed by the Debian Project Leader to the Technical Committee.

A: Recommend to appoint Christoph Berg 
B: Further Discussion

===END


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Gunnar Wolf dijo [Wed, Feb 17, 2021 at 12:45:05PM -0600]:
> ===BEGIN
> 
> The Technical Committee recommends that Christoph Berg  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> A: Recommend to appoint Christoph Berg 
> B: Further Discussion
> 
> ===END

A week has passed since this call for votes. We have five votes cast
and one explicit abstainee; we do miss the vote from one of the TC
members, but the result of the vote is no longer in doubt.

So, I will close this bug, as it's no longer a concern for the TC, and
will recommend our DPL to appoint Christoph Berg  to the
Technical Committee.

Thanks to all!


signature.asc
Description: PGP signature
--- End Message ---


Processed: Re: [Pkg-utopia-maintainers] Bug#981747: network-manager: NetworkManager does not start in sysvinit system

2021-02-03 Thread Debian Bug Tracking System
Processing control commands:

> forcemerge 964139 -1
Bug #964139 [network-manager] network-manager: Please restore removed init 
script.
Bug #981747 [network-manager] network-manager: NetworkManager does not start in 
sysvinit system
Severity set to 'wishlist' from 'grave'
981747 was not blocked by any bugs.
981747 was not blocking any bugs.
Added blocking bug(s) of 981747: 975075
Marked as found in versions network-manager/1.25.91-1.
Bug #964139 [network-manager] network-manager: Please restore removed init 
script.
Marked as found in versions network-manager/1.28.0-2.
Added tag(s) newcomer.
Merged 964139 981747
> tags 964139  + wontfix
Bug #964139 [network-manager] network-manager: Please restore removed init 
script.
Bug #981747 [network-manager] network-manager: NetworkManager does not start in 
sysvinit system
Added tag(s) wontfix.
Added tag(s) wontfix.

-- 
964139: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964139
981747: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981747
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#978636: marked as done (move to merged-usr-only?)

2021-02-01 Thread Debian Bug Tracking System
Your message dated Mon, 01 Feb 2021 10:13:11 -0700
with message-id <87r1lz7lug@melete.silentflame.com>
and subject line Re: Bug#978636: move to merged-usr-only?
has caused the Debian Bug report #978636,
regarding move to merged-usr-only?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
978636: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
X-Debbugs-Cc: debian-de...@lists.debian.org

Hi,

as suggested in [1], I would like to see Debian to move to support
only the merged-usr filesystem layout.  This would simplfy things for
the future and also address the problem with installing files under
aliased trees that dpkg has to do for both variants to be supported.

merged-usr has been the default for new installations since the last
release and (as far as I am aware) no world-breaking bugs have
happened since; some environments such as buildd chroots still do not
use merged-usr.

I would like to ask the technical committee to decide whether we want
to move to merged-usr-only.  It seems to be a case of overlapping
jurisdiction (6.1.2 in the constitution).

I'm not asking the committee to decide on a concrete technical
implementation for this.  Obviously we would need to also implement a
migration path for legacy installations for a move to merged-usr-only
to be implemented.  This also isn't relevant for Debian 11 (bullseye),
but I would like to have enough time in the Debian 12 (bookworm)
cycle.

Ansgar

[1]: https://lists.debian.org/debian-devel/2020/11/#00232
 continued in December: https://lists.debian.org/debian-devel/2020/12/#00386
--- End Message ---
--- Begin Message ---
Hello,

On Mon 25 Jan 2021 at 11:45AM -07, Sean Whitton wrote:

> I call for votes on the following ballot to resolve #978636.  The voting
> period starts immediately and lasts for up to one week, or until the
> outcome is no longer in doubt (§6.3.1).

The vote has concluded.

Marga, David, Niko, Gunnar, Simon, Elana and myself all voted: YFN.

Therefore:

The Technical Committee resolves that Debian 'bookworm' should
support only the merged-usr root filesystem layout, dropping support
for the non-merged-usr layout.

Until after the release of 'bullseye', any implementation of this
resolution must be done in the 'experimental' distribution, or
otherwise kept out of the critical paths for the release of
'bullseye'.

-- 
Sean Whitton


signature.asc
Description: PGP signature
--- End Message ---


Bug#975381: marked as done (Subject: libinih: drop Debian's custom vendorisation)

2021-01-31 Thread Debian Bug Tracking System
Your message dated Sun, 31 Jan 2021 21:50:26 -0600
with message-id <20210201035026.ga2361...@mosca.iiec.unam.mx>
and subject line Re: libinih: drop Debian's custom vendorisation
has caused the Debian Bug report #975381,
regarding Subject: libinih: drop Debian's custom vendorisation
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
975381: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975381
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: tech-ctte
Severity: wishlist

Currently the package libinih uses some heavy patches, which aren't upstream
and aren't used by any other distro. I'm in favor of dropping this, but the
current maintainer disagrees and we weren't able to make any progess in the
discussion, so I want to put this here. Parts of the discussion can be found on
this MR: https://salsa.debian.org/yangfl-guest/inih/-/merge_requests/2

To understand this, one has to look a bit at the history behind inih. Upstream
was designed as a static library for embedded devices, and therefore has a lot
of compile time options. At this point, the current maintainer created a patch
to make all compile time option available on runtime.

When gamemode started using inih, I wanted to get rid of shipped inih code and
upstreamed a build system to inih for a shared library, that any distro can
use. This was done in version 48. Due to the popularity of gamemode, inih is
now found in most major distros (all without Debian's patches):
https://repology.org/project/inih/versions

There is a notable "exception": inih is not in Ubuntu's main repository. This
is a bit weird because gamemode is in main, but with the shipped inih source
which got dropped from 1.6, meaning gamemode is stuck on 1.5.1 on Ubuntu. I'm
not sure why, but I suspect the heavy patches make it harder to be included in
main.

Because the library was designed for embedded use cases where every little bit
of performance matters, the runtime patch was refused upstream. Dropping the
runtime patch from Debian actually isn't problem, no reverse dependency of
libinih uses compile time options anyway. However, due to the history of inih
in Debian is has the soversion 1, while upstream is soversion 0.

I want to drop the vendorisation of Debian and start a transition to soversion
0 (which is also a reason I contact the Technical Committee, as it's not clear
how this would be done). A transition is needed anyway since dropping the patch
is a breaking change anyway. If the Technical Committee agrees to this, I would
also gladly help to maintain this package since it is 2 version behind upstream
since almost half a year and I maintain gamemode, which is directly affected by
this.

This isn't urgent, but it would be nice to get this done till bulleseye.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEu0Wws/9WG9vUXuips1tJ6l1WPv4FAl+5BWIACgkQs1tJ6l1W
Pv7dyA//QMHV+BGlUzXIMCcBlkVnYe85/TT8xH2peZTZ7j5ULBwvGGVhYG1Dt8/A
PcziDIcVLhmEN6N5r9vTispp0McTy5nNpotVgZ/5KJ1+WzRS+7D1YGXyS6YOTF7H
p4rK7PMMok8Yvjrxe/k8TRqRL6tw9+1cXRYhSBQg0TQGPTCEPh5nlWSgSOTKyHAe
ZAcpeUmLXvI0fLHiKAyxtI2nVPadWy+MFlJP4oJU1ml5+4ZUqDZ/DcC+qeHE8tSh
8oFdtG4/3REtb1e2x0LfeV45oj/MBv7X6IyWaw5vvjzLEiZHxuY8SRgMpgBzkNaC
y675orpcwNKFFkA5PdlxtGstDfzoUi70Gl8sNMNFt26w3+eX9+w/CxpgSIftHp6/
2cJRlgjfN6a2Eog9skq6XhGGoVZ1HHjq1mAtinKw9Wv0L88hd62PCzRu+ZVScGr8
MNK43VxbP2PCBMWY5z9uFlANBbgY4R4wPbKjZmH9NJW3yJDXHeKjCGfDrw3KX/5l
eIC+CbfEMuPHl02HY6TJwn0cDeEsRiyrLA+4aHrG1Vxy92L+4PPsQuJts6DzmGej
HNiyXvaSC88ovkOk2mgxtPx+dgI3qpmpMzJYqkpHg2Eo5zn12DpiubsZRHmR/1Fz
hrE4lwvV3W1DN4ztQs/Faa9zsRgPrhgEVKJMuqCwLSDeMovXCsY=
=kj7T
-END PGP SIGNATURE-
--- End Message ---
--- Begin Message ---
Hello,

The Technical Committee has decided to close this bug without further
action, because:

- While this bug reflects a difference in opinion regarding the
  packaging of libinih, said conflict does not impact Debian. The
  submitter is an Ubuntu maintainer, and –as stated in the bug report–
  it could be fixed downstream (i.e. in Ubuntu itself). We will not
  overrule a Debian Developer on issues not pertinent to Debian.

- The bug was opened by Stephan Lachnit for the Technical Committee to
  act upon on November 21, 2020. That very same day, the Debian
  Developer who maintains this package replied. Three weeks later,
  Sean Whitton asked on behalf of the Technical Committee for further
  input to better understand the issues at hand. A couple of days
  later, Andreas Metzler showed some examples where Stephan's claims
  didn't hold. We had no further input 

Bug#971515: marked as done (kubernetes: excessive vendoring (private libraries))

2021-01-20 Thread Debian Bug Tracking System
Your message dated Wed, 20 Jan 2021 12:28:46 -0700
with message-id <87mtx35rwx@melete.silentflame.com>
and subject line CTTE decision on "kubernetes: excessive vendoring (private 
libraries)"
has caused the Debian Bug report #971515,
regarding kubernetes: excessive vendoring (private libraries)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
971515: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971515
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal
X-Debbugs-CC: o...@debian.org
Control: block 970717 by -1

Dear Technical Committee,

Apologies that we were not able to resolve the problem without your help.

I seek your judgement regarding excessive, unnecessary and unjustifiable
vendoring of private libraries in Kubernetes package:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970717

Some relevant argumentation can be found in

  https://lists.debian.org/debian-devel/2020/03/msg00359.html
  https://lists.debian.org/debian-devel/2020/03/msg00400.html
  https://lists.debian.org/debian-devel/2020/03/msg00441.html

In short, myself and Golang packaging team spent years on stabilising
Golang ecosystem of packaged libraries for re-use by Golang software.

To the best of my knowledge, all packaged Golang software, regardless of its 
sophistication, use some packages libraries.
Except Kubernetes, that disconnected itself from cooperation by not using any 
packaged libraries, instead exclusively using only private libraries in 
numbers greater than any Debian package ever used.

As a former Kubernetes maintainer and a developer who originally introduced
Kubernetes to Debian, I know that it could be maintained with only few (or 
several) private libraries at most.

Current state of Kubernetes package is in violation of ftp-master's policy 
for inclusion of new packages to Debian.

Thank you.

This matter is not urgent.

-- 
Regards,
 Dmitry Smirnov

---

We do our friends no favors by pretending not to notice flaws in their
work, especially when those who are not their friends are bound to notice
these same flaws.
-- Sam Harris


signature.asc
Description: This is a digitally signed message part.
--- End Message ---
--- Begin Message ---
Hello,

The Committee declines to overrule the maintainer and accepts the level
of vendoring used in the 'kubernetes' source package.  We also decline
to intervene in bugs requesting that vendored components in the
'kubernetes' source package be installed in binary packages in such a
way that other packages can make use of them.

Our consensus is that Kubernetes ought to be considered special in the
same way that Firefox is considered special -- we treat the package
differently from most other source packages because (i) it is very large
and complex, and (ii) upstream has significantly more resources to keep
all those moving parts up-to-date than Debian does.

In the case of Kubernetes, what this means is that instead of breaking
the package down into separate libraries connected together with dpkg
dependency relationships, as is usual, we take updates of the whole set
of sources directly from upstream and make a single upload to our
archive.

Our most basic reason for this point of view is that given how much
fewer resources we have than upstream Kubernetes, it is not feasible for
Kubernetes to make it into a stable release of Debian unless we take an
approach like this one.  The same goes for the possibility of providing
security support.  And given that a strategy for security support is
available, we do not see any reason why having the Kubernetes bundle in
a stable release alongside other copies of its vendored dependencies is
worse than not having Kubernetes in a stable release at all.

It should be noted that we think the greater resources of upstream is
relevant not only to keeping on top of patches and security fixes, but
also to license compliance.  It is our belief that there is no reason at
the present time to be concerned that non-DFSG material would find its
way into the package, because Kubernetes upstream care about ensuring
that all vendored dependencies are free software, and they have the
resources to check.  This could change in the future and it may not be
true for other upstreams.

-- 
Sean Whitton


signature.asc
Description: PGP signature
--- End Message ---


Processed: retitle 975075 to tech-ctte: Should NetworkManager support elogind?

2020-12-23 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> retitle 975075 tech-ctte: Should NetworkManager support elogind?
Bug #975075 [tech-ctte] Should NetworkManager support elogind?
Changed Bug title to 'tech-ctte: Should NetworkManager support elogind?' from 
'Should NetworkManager support elogind?'.
> thanks
Stopping processing here.

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



Processed: retitle 975075 to Should NetworkManager support elogind?

2020-12-23 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> retitle 975075 Should NetworkManager support elogind?
Bug #975075 [tech-ctte] tech-ctte: Should maintainers be able to block init 
compatibility changes?
Changed Bug title to 'Should NetworkManager support elogind?' from 'tech-ctte: 
Should maintainers be able to block init compatibility changes?'.
> thanks
Stopping processing here.

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



Processed: Re: Bug#975381: Subject: libinih: drop Debian's custom vendorisation

2020-12-14 Thread Debian Bug Tracking System
Processing control commands:

> tag -1 + moreinfo
Bug #975381 [tech-ctte] Subject: libinih: drop Debian's custom vendorisation
Added tag(s) moreinfo.

-- 
975381: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975381
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-18 Thread Debian Bug Tracking System
Processing control commands:

> block 921012 by -1
Bug #921012 [network-manager] network-manager: change dependency on 
libpam-systemd to libpam-systemd or libpam-elogind
Bug #960780 [network-manager] Network-manager: please Depend on libpam-systemd 
| logind
921012 was not blocked by any bugs.
921012 was not blocking any bugs.
Added blocking bug(s) of 921012: 975075
960780 was not blocked by any bugs.
960780 was not blocking any bugs.
Added blocking bug(s) of 960780: 975075
> block 964139 by -1
Bug #964139 [network-manager] network-manager: Please restore removed init 
script.
964139 was not blocked by any bugs.
964139 was not blocking any bugs.
Added blocking bug(s) of 964139: 975075

-- 
921012: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921012
960780: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960780
964139: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964139
975075: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975075
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: unarchiving 947847

2020-10-07 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> unarchive 947847
Bug #947847 {Done: Margarita Manterola } [tech-ctte] please 
install systemd-sysusers using update-alternatives
Unarchived Bug 947847
> thanks
Stopping processing here.

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



Processed: kubernetes: excessive vendoring (private libraries)

2020-09-30 Thread Debian Bug Tracking System
Processing control commands:

> block 970717 by -1
Bug #970717 [src:kubernetes] kubernetes: abuse of "embedded code copies" | 
hundreds of vendored libraries
970717 was not blocked by any bugs.
970717 was not blocking any bugs.
Added blocking bug(s) of 970717: 971515

-- 
970717: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970717
971515: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971515
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#965080: marked as done (Resignation + Call for votes for new Chair)

2020-07-21 Thread Debian Bug Tracking System
Your message dated Tue, 21 Jul 2020 12:08:59 +0200
with message-id 
and subject line Re: Bug#965080: Resignation + Call for votes for new Chair
has caused the Debian Bug report #965080,
regarding Resignation + Call for votes for new Chair
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
965080: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965080
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte

[Resending as a bug rather than a mailing-list email. Sorry!]

Dear TC members,

I am calling for the election of a new Chair of Debian Technical
Committee by announcing my resignation as chair effective one week from
now. In accordance with Section 6.1.7 of the Debian Constitution, the
vote runs until all members have voted, or until my resignation takes
effect.

The ballot is the following:

===BEGIN===

The chair of the Debian Technical Committee will be:

 A : Philip Hands
 B : Margarita Manterola
 C : David Bremner
 D : Niko Tyni
 E : Gunnar Wolf
 F : Simon McVittie
 G : Sean Whitton
 H : Elana Hashman 

===END===

-- 
Regards,
Marga


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---

Hi!

All votes are in, so we can conclude this election.

The full result tally from pocket-devotee can be found here:
https://salsa.debian.org/debian/tech-ctte/-/blob/master/resolved_issues/965080_TC_Chair_election/results.txt

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The winners are:
 Option B "Margarita Manterola"

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

I guess I'll stay as chair for a while longer. Thanks!

--
Regards,
Marga--- End Message ---


Bug#963112: marked as done (Request for advice on katex rejected by ftp masters)

2020-07-15 Thread Debian Bug Tracking System
Your message dated Wed, 15 Jul 2020 22:12:11 +0200
with message-id 
and subject line Technical Committee response to #963112
has caused the Debian Bug report #963112,
regarding Request for advice on katex rejected by ftp masters
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
963112: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963112
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte

Hi,

The general case was discussed earlier and a recommendation was given at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948#54

I'd like a confirmation from you if katex was following your recommendations or 
not. I think katex should be a separate binary package because it is shipping a 
user facing executable. But ftp masters don't agree with my interpretation.

Their rejection mail and explanation is given below.

Thanks
Praveen


 Original Message 
From: Scott Kitterman 
Sent: 2020, ജൂൺ 19 3:14:43 AM IST
To: Pirate Praveen 
Cc: pkg-javascript-de...@alioth-lists.debian.net, 
ftpmas...@ftp-master.debian.org, Debian Javascript Maintainers 

Subject: Re: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes 
REJECTED

On Thursday, June 18, 2020 4:57:52 PM EDT Pirate Praveen wrote:
> On 2020, ജൂൺ 19 1:40:09 AM IST, Bastian Blank 
>  wrote:
> >The introduces an unnecessary split into katex and libjs-katex.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948#54
> 
> * User-facing executable programs associated with a library should usually
> be packaged in a non-library binary package whose name reflects the program
> (for example tappy, flatpak, parted) or collection of related programs (for
> example kmod, libsecret-tools, libglib2.0-bin), rather than being bundled
> in the same binary package as the runtime library.
> 
> Do you disagree with recommendation of ctte or you don't think it does not
> apply here?

You did read the rest of that, right?

Scott K
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--- End Message ---
--- Begin Message ---

Hi!

Thanks for submitting the bug to the technical committee.

As we said on 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948#54, we 
encourage maintainers and the ftp-team to communicate respectfully and 
try to find agreement when possible, considering that each other's goals 
are valid.


In this specific issue, it seems that there has been additional 
information provided to the ftp-master team that might resolve the 
issue. If that is not the case, we encourage you to keep communicating 
amicably to find a solution that is acceptable to both parties.


We hope that this can be resolved without having to go through a General 
Resolution, which would be very taxing to everyone involved.


--
Regards,
Margarita Manterola--- End Message ---


Bug#961153: marked as done (tech-ctte: Call for votes on TC membership of Sean Whitton)

2020-05-28 Thread Debian Bug Tracking System
Your message dated Thu, 28 May 2020 11:19:47 -0300
with message-id <87367k2lbw@tethera.net>
and subject line Re: Bug#961153: Acknowledgement (tech-ctte: Call for votes on 
TC membership of Sean Whitton)
has caused the Debian Bug report #961153,
regarding tech-ctte: Call for votes on TC membership of Sean Whitton
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
961153: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961153
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I call for votes on the following ballot to fill a vacant seat in the
Debian Technical Committee. The voting period starts immediately and
lasts for up to one week, or until the outcome is no longer in doubt
(§6.3.1).

===BEGIN
The Technical Committee recommends that Sean Whitton  be
appointed by the Debian Project Leader to the Technical Committee.

S: Recommend to Appoint Sean Whitton 
F: Further Discussion
===END
- -- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl7FjQMACgkQA0U5G1Wq
FSEFRg/9GBxoEc1kvjkJ87jstyqLbPs9mm5fslBnA4vZ479AoRcG1NgowifN2cTA
emF3d2FyHV2Q3r/xk4bo1GFAzLxvcBy/nh1WEetgLDBOrii0G63YaMWjpCpSyzI+
UiMUrHio+qIYLqtCnGGlOBn4OlONIADjzeytSH/wFl2Puv6txjK0zRiDrLO8B5RS
iZ8j/zD6mb3a+3AJKfbzrP+/jElVrEfMrwTVMJzni2K/QYlEc3uW/QiEnDUbcg08
+DiF0BiVqNXXOMPYfeIIT6cG89Evh3uxEqWOjgNREnrOOhtJzeVQrHW5N3X9XYM0
JOHGqJTBVDryR6tmQWBh38ta72nSkskMxV0An/Rbz5EUMKYq5Qy3RSkN6H9ogROS
HeovIdwB8vLbVRuUJY93kA112m0LgdTtqRZIz5Fqj1zj9U6cm5gt1pcC60xZnM5+
qH95UEbsuIbDpnxc8KdHTtVyNU6mZAT2novOFwwM2JjXgvPzj6AZ4AQ1nn1OWZMo
uajo1tmwXqENPlO288Edsml5mSNT+ztgOo6gTqyYca+38nu/RqmfO85MbFFSgOE4
uYtQm30MRjNsjLKkNLu7miadpWfUIIRddqBZRN8A2i18KyPpzpv/CkjIeaM3ejxs
vv9lSOyLC7vy14LGXELQ4nO6NmKu54XL7K0QIgVLIesTFJYFmpY=
=nouT
-END PGP SIGNATURE-
--- End Message ---
--- Begin Message ---

With six votes in favour, and no votes for further discussion:

  The Technical Committee recommends that Sean Whitton  be
  appointed by the Debian Project Leader to the Technical Committee.

Jonathan, you have our recommendation,

Re-sending, to the right bug this time, hopefully.


signature.asc
Description: PGP signature
--- End Message ---


Bug#961156: marked as done (tech-ctte: Call for votes on TC membership of Elana Hashman)

2020-05-28 Thread Debian Bug Tracking System
Your message dated Thu, 28 May 2020 08:46:58 -0300
with message-id <87eer42sel@tethera.net>
and subject line Re: Bug#961156: tech-ctte: Call for votes on TC membership of 
Elana Hashman
has caused the Debian Bug report #961156,
regarding tech-ctte: Call for votes on TC membership of Elana Hashman
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
961156: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961156
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I call for votes on the following ballot to fill a vacant seat in the
Debian Technical Committee. The voting period starts immediately and
lasts for up to one week, or until the outcome is no longer in doubt
(§6.3.1).

===BEGIN
The Technical Committee recommends that Elana Hashman  be
appointed by the Debian Project Leader to the Technical Committee.

S: Recommend to Appoint Elana Hashman 
F: Further Discussion
===END

- -- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl7FjrEACgkQA0U5G1Wq
FSFzhBAAuoTkGCCjBTGqFTDOMHvFuQaKPp5sRWHGuNv4DNuZQ92GBtkWHjo2pVaN
np5f6RHFaDfG50PqqITvrSarHmpIaLvESVaFCYjaBGKXhkqa/I0vS/KRFiuXwu0j
YQHHCTMqbTWwHLU0MSYXwZtacXGE9muk12yCZH9IxICvU7rzwO2GKo4TpKPGjwlF
D3jMmxa0/KtYDDMuiReY8O/5XV+Ht5dEVUMNb7yDTIeBv5r9AzWSZT3iCve5ox+p
e1EUDIpLpy9zQH0z+G9fy8rQWsjpRAdxBqaWySgH76NOM8Ni02KC8k9UXCbezOiZ
NAQvtnRLTy1ovDvN3X3uP8xxp65fIkBTZwS8HfM4atiSV89IiN3hiipf1rDlrzz5
iwvxyK186cKlZlExgLwV+lrjWY1mco3KV1lgsmKuf6p9px4f9IPDwGKaMgzDP7yl
KOxdSKhilP54Ve6lodsFaqMDVr/wZS1sx7B9EBawBhMLYWrFHc26WKCQ45cWrLvd
QDhcYj6d6N+X3AfJVru83c0rTLcrwbn/0hnhCeYWbrak0sUfsY4E8+/4LjXX0tdF
+MGYWsySdaNHDqMa+n0yKxCvQQnZc0Xv1Bmns1DNZD/M+wi2wkUt1ZHuFdm0JtJ4
lDhDRZdqDEMIDzxMbIHa+0iiS+wCx01yGGBlmtcLUEtgfyzcE0M=
=LfgW
-END PGP SIGNATURE-
--- End Message ---
--- Begin Message ---

With 6 votes in favour, and no votes the for further discussion:

 The Technical Committee recommends that Elana Hashman  be
 appointed by the Debian Project Leader to the Technical Committee.

Jonathan, it's up to you now.

d


signature.asc
Description: PGP signature
--- End Message ---


Bug#961150: marked as done (tech-ctte: Call for votes on TC membership of Sean Whitton)

2020-05-20 Thread Debian Bug Tracking System
Your message dated Wed, 20 May 2020 17:00:24 -0300
with message-id <87zha2v0kn@tethera.net>
and subject line Re: Bug#961150: tech-ctte: Call for votes on TC membership of 
Sean Whitton
has caused the Debian Bug report #961150,
regarding tech-ctte: Call for votes on TC membership of Sean Whitton
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
961150: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961150
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I call for votes on the following ballot to fill a vacant seat in the
Debian Technical Committee. The voting period starts immediately and
lasts for up to one week, or until the outcome is no longer in doubt
(§6.3.1).

===BEGIN
The Technical Committee recommends that Niko Tyni  be
appointed by the Debian Project Leader to the Technical Committee.

S: Recommend to Appoint Sean Whitton 
F: Further Discussion
===END

- -- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl7FhWoACgkQA0U5G1Wq
FSEKuA/+I/D3o3m2MVTYQSbanNygV8PiXAvtRuRZ1n8uxmXGAsNc45pmKH6uiHhn
dXJxen2KZaaBiYwkYMUQiJxL500+28sWJX9VFHAbsRLqZsqdhmkEL/dzreAqLiWL
NrwzmQUlawvslbepJnHQOfjMXo4PRfoUyxg3UXwVIcNOBujjL4VDciUn8U+FljXo
AnYYcLcgj1oSpJM6a999MqFjvEYGupstfnjW7PZH9sZGwl4XwAmrv5PiCtjE28sW
rlF/INFXWa8CVbQrky+Ib0yKxhA4Cx7JsPVQP0egI+WmD7bmvNmMcfisk0YqtzES
nHPCyEWUjMwfwGAS7rWHkttyqIdSen+3+zYqxM+2VgblRW0bXmOtC/BV5ldgsdL2
ieAyVVB+KgZtzSiPNh0+tWL6A/EA6r4E+bDAjgsnhK7TeM6NfdSrQFylh2v42+0+
0dOicsnWUeZqIfii3WlXNjRJa6NqFArzpXG48CHL66ud0efUDwLK/qdEdGTXT1iy
H4wUtN4zXSTADrCgyV1qV4Kn2LYRCJSHl6SBu/Pzjw2EaIWQX6MEwW4PTSbhupfG
QQiwh96Xd1fBXq2X1Jw9zLX59bRAKjb7jgPlf+9gD/Ntd18EjCydIePVPLnYVLky
Lz7JOSq0EdErDXncL4nt81CO9QEt0mdc/1f62Txx/Svg+XwESpM=
=5gqS
-END PGP SIGNATURE-
--- End Message ---
--- Begin Message ---
David Bremner  writes:

> Package: tech-ctte
> Severity: normal
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> I call for votes on the following ballot to fill a vacant seat in the
> Debian Technical Committee. The voting period starts immediately and
> lasts for up to one week, or until the outcome is no longer in doubt
> (§6.3.1).
>
> ===BEGIN
> The Technical Committee recommends that Niko Tyni  be
> appointed by the Debian Project Leader to the Technical Committee.
>
> S: Recommend to Appoint Sean Whitton 
> F: Further Discussion
> ===END
>
I messed up the ballot, so to (hopefully) minimize confusion I'm going
to close this bug and try again.


signature.asc
Description: PGP signature
--- End Message ---


Bug#947847: marked as done (please install systemd-sysusers using update-alternatives)

2020-03-18 Thread Debian Bug Tracking System
Your message dated Wed, 18 Mar 2020 20:35:28 +0100
with message-id 
and subject line Re: Bug#947847: please install systemd-sysusers using 
update-alternatives
has caused the Debian Bug report #947847,
regarding please install systemd-sysusers using update-alternatives
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
947847: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947847
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: systemd
Version: 244-3
Severity: important

Hi,

As I'm packaging opensysusers (see ITP: #947846), I would like my
package to also provide /bin/systemd-sysusers. Please install this
binary on another location, so that both systemd and opensysusers can
implement it. I am very much fine to have systemd have the priority over
opensysusers if you believe it should (I'm open to discussion about
priorities).

Cheers,

Thomas Goirand (zigo)
--- End Message ---
--- Begin Message ---

Hi,

The technical committee was asked to overrule the systemd maintainers in 
their decision not to use the alternatives system for systemd-sysusers 
and systemd-tmpfiles.


Our mailing list and IRC discussions have shown that we agree with the 
systemd maintainers that using the alternatives system for these files 
is not a good idea.  Therefore, we decline to overrule the systemd 
maintainers.


Some additional comments on this matter:

The alternatives system has served us well when there's a clear API that 
implementations have to follow and there's an implementation independent 
location that becomes the alternative.  In a case like sysusers or 
tmpfiles it would be perhaps make sense to use the alternatives system 
for a path like /bin/sysusers and /bin/tmpfiles, but it doesn't make 
sense to use it for /bin/systemd-sysusers.


The flip side of this is that implementing such a path would become 
Debian specific and the general agreement is that diverging from the 
rest of the Linux community for no good reason is not a good course of 
action. Perhaps this could be an option if the FHS was still evolving to 
include new tools like these, but that's unfortunately not the case.


Leaving the alternative system aside, the other two options that would 
allow opensysusers and opentmpfiles to be drop-in replacements for the 
systemd versions are: A) packages that conflict with each other and B) 
using dpkg-divert to divert the versions.


Shipping systemd-sysusers and systemd-tmpfiles as separate packages has 
been requested in [1], and there has been some work done in that 
direction in the bug. It seems that with the recent work done in that 
bug, this could possibly work. In order for this to happen, interested 
parties should probably go ahead and test / review the proposed solution 
and collaborate with systemd maintainers to find out if this is 
possible.


[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946456

On the dpkg-divert option, the rough consensus of the committee is that 
while this is not the most elegant solution out there, it's a perfectly 
valid solution for a tool that's experimental and under development. It 
makes sense for such a tool to divert the files that it's replacing. 
This is low-effort for everyone involved and lets users experiment and 
give feedback on the tools.


If the tool sees very significant adoption, it might make sense to 
eventually reconsider the strategies for dealing with multiple 
implementations.


Regards,
Marga on behalf of the Technical Committee.--- End Message ---


Bug#935164: marked as done (Dropping dependencies to avoid extra binary package when same source package targets more than one environment)

2019-12-18 Thread Debian Bug Tracking System
Your message dated Wed, 18 Dec 2019 22:55:16 +
with message-id <20191218225516.ga257...@espresso.pseudorandom.co.uk>
and subject line Bug#934948: Dropping dependencies to avoid extra binary 
package when same source package targets more than one environment
has caused the Debian Bug report #934948,
regarding Dropping dependencies to avoid extra binary package when same source 
package targets more than one environment
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
934948: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte

Hi members of CTTE,

I'd like to bring to your notice a disagreement with ftp masters about adding 
multiple binary packages when the same source package has code targeting 
multiple environments. I have been told already that CTTE cannot overrule an 
ftp master decision, so I'm just asking for opinion of the CTTE. If your 
opinion is favorable to me, it can help me if decide to start a GR eventually.

I was also told to contact CTTE and DPL before going for a GR by js team 
members.

Packages with disagreement are node-autoprefixer and ruby-task-list.

Though ftp masters stated on irc, node-autoprefixer will not be accepted, it 
was eventually accepted and in the archive. But ruby-task-list was rejected.

If I follow ftp master recommendation, node-autoprefixer binary should just 
provide libjs-autoprefixer . But it means anyone installing libjs-autoprefixer 
will have nodejs installed, even though libjs-autoprefixer can work without 
nodejs installed (it will be served by a web server and executed by a browser).

In the same way, ruby-task-list binary should provide node-deckar01-task-list. 
So anyone installing node-deckar01-task-list will get ruby and other 
dependencies of ruby-task-list installed even though it is not necessary. Same 
way anyone installing ruby-task-list will get nodejs unnecessarily.

Alternatively, if I drop nodejs and ruby dependencies, any package depending on 
ruby-task-list will have to add ruby-task-list's dependencies as its own 
dependencies.

Summary of the situation, initially shared with Ruby and JS teams: 
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-August/034881.html

Initial discussion with ftp masters (readable via a matrix client): 
https://matrix.to/#/!saEdMDOolDMHFHsdhS:matrix.org/$15495421281854XktcP:poddery.com

I have to copy each message from riot separately.

Here it is,

Me: please review node-autoprefixer, it adds libjs-autoprefixer binary required 
to replace embedded copy of autoprefixer.js in ruby-autoprefixer-rails

waldi: 
Pirate ‍ Praveen: you have been asked to not do that

me: waldi: this time there is a valid reason
unlike the previous cases

waldi: Pirate ‍ Praveen: no. nodejs as dependency is no reason

me: waldi: I'd like to ask this as an official statement from ftp team and I'd 
like to challenge it with CTTE
should I open a bug agianst ftp.debian.org?

ScottK: Pirate ‍ Praveen: CTTE can't overrule FTP team.
The only way to overrule a delegate is GR.
Just so you know what you're in for.

Gannef, and yes, open a bug.

highvoltage: Pirate ‍ Praveen: fwiw, I know that that path will take you 
nowhere, the ftp teams's advice here is sound and upwards of 99% of DDs will 
agree with their judgement here, it's going to be futile to fight it, I suggest 
you rather find a better solution for the package, that's a better way to spend 
your (and everybody elses) energy

me: highvoltage: fine, at least let this be on record

highvoltage: policy is quite clear on it and there's even an entire wiki page 
on the topic (https://wiki.debian.org/EmbeddedCodeCopies), I guess if you need 
further records on that, then that's your business

waldi: highvoltage: it's not about code copies. but about adding additional 
binary packages just to avoid one dependency

me: Ganneff: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921628

highvoltage: ew that's even worse

Clint: ...

Gannef: it does sound like a plenty bad idea

And some more...

Bug asking ftp masters for official statement (no response till now): 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921628

I think such policies should be applied consistently to all packages (it was 
inconsistently applied in the two packages I refer) and published (currently 
there is no official statement).

The outcomes could be,

a) CTTE agrees with ftp masters in rejecting ruby-task-list source package with 
node-deckar01-task-list binary added to existing ruby-task-list 

Bug#935160: marked as done (Dropping dependencies to avoid extra binary package when same source package targets more than one environment)

2019-12-18 Thread Debian Bug Tracking System
Your message dated Wed, 18 Dec 2019 22:55:16 +
with message-id <20191218225516.ga257...@espresso.pseudorandom.co.uk>
and subject line Bug#934948: Dropping dependencies to avoid extra binary 
package when same source package targets more than one environment
has caused the Debian Bug report #934948,
regarding Dropping dependencies to avoid extra binary package when same source 
package targets more than one environment
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
934948: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte

Hi members of CTTE,

I'd like to bring to your notice a disagreement with ftp masters about adding 
multiple binary packages when the same source package has code targeting 
multiple environments. I have been told already that CTTE cannot overrule an 
ftp master decision, so I'm just asking for opinion of the CTTE. If your 
opinion is favorable to me, it can help me if decide to start a GR eventually.

I was also told to contact CTTE and DPL before going for a GR by js team 
members.

Packages with disagreement are node-autoprefixer and ruby-task-list.

Though ftp masters stated on irc, node-autoprefixer will not be accepted, it 
was eventually accepted and in the archive. But ruby-task-list was rejected.

If I follow ftp master recommendation, node-autoprefixer binary should just 
provide libjs-autoprefixer . But it means anyone installing libjs-autoprefixer 
will have nodejs installed, even though libjs-autoprefixer can work without 
nodejs installed (it will be served by a web server and executed by a browser).

In the same way, ruby-task-list binary should provide node-deckar01-task-list. 
So anyone installing node-deckar01-task-list will get ruby and other 
dependencies of ruby-task-list installed even though it is not necessary. Same 
way anyone installing ruby-task-list will get nodejs unnecessarily.

Alternatively, if I drop nodejs and ruby dependencies, any package depending on 
ruby-task-list will have to add ruby-task-list's dependencies as its own 
dependencies.

Summary of the situation, initially shared with Ruby and JS teams: 
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-August/034881.html

Initial discussion with ftp masters (readable via a matrix client): 
https://matrix.to/#/!saEdMDOolDMHFHsdhS:matrix.org/$15495421281854XktcP:poddery.com

I have to copy each message from riot separately.

Here it is,

Me: please review node-autoprefixer, it adds libjs-autoprefixer binary required 
to replace embedded copy of autoprefixer.js in ruby-autoprefixer-rails

waldi: 
Pirate ‍ Praveen: you have been asked to not do that

me: waldi: this time there is a valid reason
unlike the previous cases

waldi: Pirate ‍ Praveen: no. nodejs as dependency is no reason

me: waldi: I'd like to ask this as an official statement from ftp team and I'd 
like to challenge it with CTTE
should I open a bug agianst ftp.debian.org?

ScottK: Pirate ‍ Praveen: CTTE can't overrule FTP team.
The only way to overrule a delegate is GR.
Just so you know what you're in for.

Gannef, and yes, open a bug.

highvoltage: Pirate ‍ Praveen: fwiw, I know that that path will take you 
nowhere, the ftp teams's advice here is sound and upwards of 99% of DDs will 
agree with their judgement here, it's going to be futile to fight it, I suggest 
you rather find a better solution for the package, that's a better way to spend 
your (and everybody elses) energy

me: highvoltage: fine, at least let this be on record

highvoltage: policy is quite clear on it and there's even an entire wiki page 
on the topic (https://wiki.debian.org/EmbeddedCodeCopies), I guess if you need 
further records on that, then that's your business

waldi: highvoltage: it's not about code copies. but about adding additional 
binary packages just to avoid one dependency

me: Ganneff: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921628

highvoltage: ew that's even worse

Clint: ...

Gannef: it does sound like a plenty bad idea

And some more...

Bug asking ftp masters for official statement (no response till now): 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921628

I think such policies should be applied consistently to all packages (it was 
inconsistently applied in the two packages I refer) and published (currently 
there is no official statement).

The outcomes could be,

a) CTTE agrees with ftp masters in rejecting ruby-task-list source package with 
node-deckar01-task-list binary added to existing ruby-task-list 

Bug#934948: marked as done (Dropping dependencies to avoid extra binary package when same source package targets more than one environment)

2019-12-18 Thread Debian Bug Tracking System
Your message dated Wed, 18 Dec 2019 22:55:16 +
with message-id <20191218225516.ga257...@espresso.pseudorandom.co.uk>
and subject line Bug#934948: Dropping dependencies to avoid extra binary 
package when same source package targets more than one environment
has caused the Debian Bug report #934948,
regarding Dropping dependencies to avoid extra binary package when same source 
package targets more than one environment
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
934948: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte

Hi members of CTTE,

I'd like to bring to your notice a disagreement with ftp masters about adding 
multiple binary packages when the same source package has code targeting 
multiple environments. I have been told already that CTTE cannot overrule an 
ftp master decision, so I'm just asking for opinion of the CTTE. If your 
opinion is favorable to me, it can help me if decide to start a GR eventually.

I was also told to contact CTTE and DPL before going for a GR by js team 
members.

Packages with disagreement are node-autoprefixer and ruby-task-list.

Though ftp masters stated on irc, node-autoprefixer will not be accepted, it 
was eventually accepted and in the archive. But ruby-task-list was rejected.

If I follow ftp master recommendation, node-autoprefixer binary should just 
provide libjs-autoprefixer . But it means anyone installing libjs-autoprefixer 
will have nodejs installed, even though libjs-autoprefixer can work without 
nodejs installed (it will be served by a web server and executed by a browser).

In the same way, ruby-task-list binary should provide node-deckar01-task-list. 
So anyone installing node-deckar01-task-list will get ruby and other 
dependencies of ruby-task-list installed even though it is not necessary. Same 
way anyone installing ruby-task-list will get nodejs unnecessarily.

Alternatively, if I drop nodejs and ruby dependencies, any package depending on 
ruby-task-list will have to add ruby-task-list's dependencies as its own 
dependencies.

Summary of the situation, initially shared with Ruby and JS teams: 
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-August/034881.html

Initial discussion with ftp masters (readable via a matrix client): 
https://matrix.to/#/!saEdMDOolDMHFHsdhS:matrix.org/$15495421281854XktcP:poddery.com

I have to copy each message from riot separately.

Here it is,

Me: please review node-autoprefixer, it adds libjs-autoprefixer binary required 
to replace embedded copy of autoprefixer.js in ruby-autoprefixer-rails

waldi: 
Pirate ‍ Praveen: you have been asked to not do that

me: waldi: this time there is a valid reason
unlike the previous cases

waldi: Pirate ‍ Praveen: no. nodejs as dependency is no reason

me: waldi: I'd like to ask this as an official statement from ftp team and I'd 
like to challenge it with CTTE
should I open a bug agianst ftp.debian.org?

ScottK: Pirate ‍ Praveen: CTTE can't overrule FTP team.
The only way to overrule a delegate is GR.
Just so you know what you're in for.

Gannef, and yes, open a bug.

highvoltage: Pirate ‍ Praveen: fwiw, I know that that path will take you 
nowhere, the ftp teams's advice here is sound and upwards of 99% of DDs will 
agree with their judgement here, it's going to be futile to fight it, I suggest 
you rather find a better solution for the package, that's a better way to spend 
your (and everybody elses) energy

me: highvoltage: fine, at least let this be on record

highvoltage: policy is quite clear on it and there's even an entire wiki page 
on the topic (https://wiki.debian.org/EmbeddedCodeCopies), I guess if you need 
further records on that, then that's your business

waldi: highvoltage: it's not about code copies. but about adding additional 
binary packages just to avoid one dependency

me: Ganneff: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921628

highvoltage: ew that's even worse

Clint: ...

Gannef: it does sound like a plenty bad idea

And some more...

Bug asking ftp masters for official statement (no response till now): 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921628

I think such policies should be applied consistently to all packages (it was 
inconsistently applied in the two packages I refer) and published (currently 
there is no official statement).

The outcomes could be,

a) CTTE agrees with ftp masters in rejecting ruby-task-list source package with 
node-deckar01-task-list binary added to existing ruby-task-list 

Processed: unarchive

2019-11-07 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> unarchive 932795
Bug #932795 {Done: Gunnar Wolf } [tech-ctte] How to handle 
FTBFS bugs in release architectures
Unarchived Bug 932795
> thanks
Stopping processing here.

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



Bug#932795: marked as done (How to handle FTBFS bugs in release architectures)

2019-10-09 Thread Debian Bug Tracking System
Your message dated Wed, 9 Oct 2019 11:15:32 -0500
with message-id <20191009161532.ga27...@mosca.iiec.unam.mx>
and subject line Regarding archive-wide quality assurance work
has caused the Debian Bug report #932795,
regarding How to handle FTBFS bugs in release architectures
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
932795: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932795
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte

Dear TC:

I reported this bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907829

and it was downgraded on the basis that the official autobuilders
are multi-core.

I believe this downgrade is not appropriate, for several reasons:

* The informal guideline which is being used, "FTBFS are serious if
and only if they happen on buildd.debian.org", is not written anywhere
and it's contradictory with Debian Policy, which says "it must be
possible to build the package when build-essential and the
build-dependencies are installed".

* Because this is a violation of a Policy "must" directive, I consider
the downgrade to be a tricky way to modify Debian Policy without
following the usual Policy decision-making procedure.

* I also do not recognize the informal guideline being used as
universally applicable, always valid, and in 100% of cases. In fact,
I have yet to see why people follow such guideline when there
is no rationale anywhere. Packages which FTBFS in buildd.debian.org
certainly deserve a serious bug, but P => Q is not the same as Q => P.

If we have a FTBFS bug that nobody can reproduce, then ok, downgrading
the bug if the package builds ok in the buildds may make sense as a
cautionary measure until we have more info, but a single successful
build in buildd.debian.org does not ensure that the package will build
in every system where the package must build.

To illustrate why I think this guideline can't be universal, let's
consider the case (as a "thought experiment") where we have a package
which builds ok with "dpkg-buildpackage -A" and "dpkg-buildpackage -B"
but FTBFS when built with plain "dpkg-buildpackage".

Are we truely and honestly saying this package would not deserve a
serious bug in the BTS just because it builds ok in the buildds?

Surely, the end user *must* be able to build the package as well, must
they not?


So, in the bug above, I'm asked to accept as a fact that we have
*already* deprecated building on single-cpu systems, implicitly and
automagically. Let's assume for a while that such deprecation is real
and suppose I would like to "undeprecate" it. What formal procedure
should I follow for that?

Would it work, for example, if I propose a change to Debian Policy so
that it reads "Packages must build from source" instead of "Packages
must build from source on multi-core systems"? No, that would be
useless, because Debian Policy already says that packages must build
from source.

Would it work, for example, if I propose a change to Release Policy so
that it reads "Packages must build on all architectures on which they
are supported" instead of "Packages must only build ok in the official
buildds"? No, that would not work either, because Release Policy
already says that packages must build in all architectures in which
they are supported.

See how much kafkaesque is this?

Currently, this is what is happening:

Whenever someone dares to report a bug like this as serious, following
both Debian Policy and Release Policy (or at least the letter of it),
we lambast them, we make mock of their building environment, we call
them a fool, and we quote informal guidelines which are not written
anywhere. If we do this consistently, then no doubt that building on
single-cpu systems will become de-facto obsolete regardless of what
policy says, because nobody likes to be treated that way.

But surely there must be a better way: It is my opinion, and here is
where I'm asking the TC for support, that the burden of deprecating
building on single-cpu systems, or in general any other thing which
has always been a policy "must" directive, should be on those willing
to deprecate such things, and they are the ones who should convince
the rest of us, not the other way around.

For example, being proud to call ourselves the Universal Operating System,
we drop release architectures when it's increasingly difficult for us
to support them, *not* because we dislike them, *not* because they 

Processed: retitle 934948 to Dropping dependencies to avoid extra binary package when same source package targets more than one environment

2019-09-01 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> retitle 934948 Dropping dependencies to avoid extra binary package when same 
> source package targets more than one environment
Bug #934948 [tech-ctte] Unnecessary dependencies vs multiple binary packages
Bug #935160 [tech-ctte] Unnecessary dependencies vs multiple binary packages
Bug #935164 [tech-ctte] Unnecessary dependencies vs multiple binary packages
Changed Bug title to 'Dropping dependencies to avoid extra binary package when 
same source package targets more than one environment' from 'Unnecessary 
dependencies vs multiple binary packages'.
Changed Bug title to 'Dropping dependencies to avoid extra binary package when 
same source package targets more than one environment' from 'Unnecessary 
dependencies vs multiple binary packages'.
Changed Bug title to 'Dropping dependencies to avoid extra binary package when 
same source package targets more than one environment' from 'Unnecessary 
dependencies vs multiple binary packages'.
> thanks
Stopping processing here.

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



Processed: merging 934948 935160

2019-08-20 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> merge 934948 935160
Bug #934948 [tech-ctte] Unnecessary dependencies vs multiple binary packages
Bug #935160 [tech-ctte] Unnecessary dependencies vs multiple binary packages
Bug #935164 [tech-ctte] Unnecessary dependencies vs multiple binary packages
Merged 934948 935160 935164
> thanks
Stopping processing here.

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



Processed: forcibly merging 935164 935160

2019-08-20 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> forcemerge 935164 935160
Bug #935164 [tech-ctte] Unnecessary dependencies vs multiple binary packages
Bug #935160 [tech-ctte] Unnecessary dependencies vs multiple binary packages
Merged 935160 935164
> thanks
Stopping processing here.

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



Processed: How to handle FTBFS bugs in release architectures

2019-07-24 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> retitle 932795 How to handle FTBFS bugs in release architectures
Bug #932795 [tech-ctte] Ethics of FTBFS bug reporting
Changed Bug title to 'How to handle FTBFS bugs in release architectures' from 
'Ethics of FTBFS bug reporting'.
> thanks
Stopping processing here.

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



Bug#904558: marked as done (What should happen when maintscripts fail to restart a service)

2019-04-17 Thread Debian Bug Tracking System
Your message dated Wed, 17 Apr 2019 21:41:45 +0200
with message-id <84d404a6642454b541550ec53c908...@debian.org>
and subject line Re: Bug#904558: What should happen when maintscripts fail to 
restart  a service
has caused the Debian Bug report #904558,
regarding What should happen when maintscripts fail to restart a service
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
904558: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904558
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
X-debbugs-cc: debian-pol...@lists.debian.org
Control: block 780403 by -1

I hereby request advice from the Technical Committee on a decision that
I must take in my role as a Debian Policy delegate.  To be completely
clear, I am not seeking a decision.  I refer to the third power of the
T.C. listed under section 6.1 of the Debian Constitution: "Any person or
body may ... seek advice from [the Technical Committee]."

In bugs #780403 and #802501 the following question has been asked (I
quote Daniel Pocock):

If postinst or one of the other scripts does a service restart and
the restart operation fails, should the postinst abort or should it
mask the error, continue and return success?

At present the Policy Manual does not answer this question, and thus it
is left up to maintainer discretion: whatever the maintainer thinks
makes sense for the service in question.

Others have pointed out, however, that this means that users will see
inconsistent behaviour.  There is no practical way for a user to
determine what will happen when installing a given package that starts
or restarts a service, if that start or restart attempt fails.  So if it
were possible to come up with consistent answer to the question posed,
it would be useful to our users.

As a Policy delegate I want to move this issue along, and I can see
three ways of doing that:

1. write a patch to explicitly state in Policy that what happens when a
   service (re)start fails in a maintscript is left up to package
   maintainer discretion, and close the bugs

2. make a further attempt to establish consensus on a requirement that
   maintscripts are consistent in the case of a (re)start failure (this
   is the default option, so to speak, and I cannot see it succeeding)

3. ask the T.C. to decide what maintscripts should do in these cases.

The general question about which I am seeking advice: does the
T.C. think that Debian can be consistent on service (re)starts in
maintscripts, or is the best we can do to leave it up to package
maintainer discretion?

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---

Apologies for the long delay.

We discussed this issue in several TC meetings without being able to 
make

real progress.

After several rounds of discussions we came to the conclusion that the
reason why we can't make progress is that we always end up hitting the 
wall
of "The Technical Committee does not engage in design of new proposals 
and
policies". While we recognize that this is a problem worth fixing, this 
is
not something that we can fix as a body and need the help of the 
Developers

to do it.

On the one hand, maintainers want to be able to notify sysadmins when
things don't go as expected. On the other hand, sysadmins don't want 
their
systems to be left in weird/broken states because one single thing 
didn't

go as expected.

A failing maintscript is a horrible way of notifying sysadmins, but it's
the only one available up to now and so package maintainers use it when
they think the failure is critical enough.

So, the TC declines to rule on what should maintscripts do when failing 
to

(re)start a service (or otherwise encountering a similarly serious
problem).

Instead, we recommend that a work group of developers is formed, to 
create
a better mechanism of notification that can be used to let sysadmins 
know

when things don't go as expected on their systems, without leaving the
machines in weird/broken states. Given that this is a problem faced by 
many
Linux distributions, it would be nice if this mechanism was developed 
and
published in a non Debian specific way that made it also available for 
other

distributions to use.

Once that mechanism exists, we would strongly recommend that almost all
failures use this mechanism, instead of failing maintscripts.

--
Marga, on behalf of the Technical Committee--- End Message ---


Bug#911225: marked as done (tech-ctte: Advice on stale libraries in a higher-precedence path entry)

2019-03-20 Thread Debian Bug Tracking System
Your message dated Wed, 20 Mar 2019 09:34:35 +0100
with message-id <1cc9400c0f4f4a8feb29bcd41dc0f...@debian.org>
and subject line Re: Bug#911225: tech-ctte: Advice on stale libraries in a  
higher-precedence path entry
has caused the Debian Bug report #911225,
regarding tech-ctte: Advice on stale libraries in a higher-precedence path entry
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
911225: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911225
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal

I would like advice from the technical committee on
<https://bugs.debian.org/896019>. I am not asking for anyone to be
overruled.

GLib (src:glib2.0) consists of multiple libraries. The ones that are
relevant for this bug are libglib-2.0.so.0, which is low-level, and
libgobject-2.0.so.0, which is higher-level. They come from the same source
package (indeed, in Debian they are even in the same binary package)
and are expected/required/assumed to be upgraded in lockstep:
higher-level libraries from src:glib2.0 are allowed to assume that
the lower-level libraries are at exactly the same version.

In stretch and previous releases, libglib-2.0.so.0 was installed in
/lib/MULTIARCH, ostensibly for the benefit of early-boot services. It
isn't clear to me whether any early-boot services actually ever took
advantage of this.

In buster, libglib-2.0.so.0 was moved to /usr/lib/MULTIARCH, because
versions >= stretch only support a separate /usr if there is an initramfs
that mounts it before running the main system's init, and in particular
/usr/lib/MULTIARCH will be available by the time init starts. This removed
some apparently unnecessary complexity from the packaging, which had to
move the libraries around (we couldn't just set ${libdir} to
/lib/MULTIARCH, because higher-level parts of GLib needed to be in
/usr/lib/MULTIARCH anyway).

/lib/MULTIARCH appears in /etc/ld.so.conf.d with higher precedence than
/usr/lib/MULTIARCH.

In #896019 and #894763, it appears that some upgraded systems somehow
still contain a copy of libglib-2.0.so.0.4200.0 (corresponding to
GLib from jessie) in /lib/MULTIARCH. We don't know how this can have
happened. There are suggestions that it might have been caused by
filesystem corruption or installed by third-party software.

When it does, ldconfig sees that the obsolete library
has SONAME libglib-2.0.so.0, and creates a symlink
/lib/MULTIARCH/libglib-2.0.so.0. This takes precedence over the
newer version of libglib-2.0.so.0 that is correctly installed in
/usr/lib/MULTIARCH, resulting in the new libgobject-2.0.so.0 failing
to load, because it uses symbols that are only present in the new
libglib-2.0.so.0.

Possible resolutions include:

* Do nothing; consider the systems with a leftover
  /lib/MULTIARCH/libglib-2.0.so.0.4200.0 to be an unsupported local
  misconfiguration (this is the status quo)

* Move libglib-2.0.so.0 back to /lib/MULTIARCH permanently, at a
  long-term complexity cost

* Take steps to delete /lib/MULTIARCH/libglib-2.0.so.0.* during upgrade,
  taking care to avoid deleting files that are really on
  /usr/lib/MULTIARCH in merged-/usr systems, at a significant complexity
  cost, with some risk of deleting necessary files if we get it wrong

* Advocate merged /usr where this class of problem cannot happen :-)

Do technical committee members (other than me) have any thoughts on this?

Thanks,
smcv
--- End Message ---
--- Begin Message ---

The last time this was discussed was in our IRC meeting in November:
http://meetbot.debian.net/debian-ctte/2018/debian-ctte.2018-11-21-18.58.log.html

The advice provided by Didier was found sensible by several members of 
the Technical Committee.  Simon said that while he agreed it was 
sensible, it was more complex than expected.  Simon is free to implement 
whichever solution he finds both sensible and technically sound, but the 
committee has provided the advice requested.


Therefore, I'm here closing this bug as resolved.

--
Regards,
Marga--- End Message ---


Bug#914897: marked as done (tech-ctte: Should debootstrap disable merged /usr by default?)

2019-03-05 Thread Debian Bug Tracking System
Your message dated Tue, 05 Mar 2019 12:23:44 +0100
with message-id <1757030.berfeli...@odyx.org>
and subject line Re: Bug#914897: tech-ctte: Should debootstrap disable merged 
/usr by default?
has caused the Debian Bug report #914897,
regarding tech-ctte: Should debootstrap disable merged /usr by default?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
914897: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914897
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debootstrap
Version: debootstrap/1.0.110
Severity: serious

Merged /usr is now the default in buster.  As discussed on
debian-devel, however, binary packages built on a merged-usr system
are not installable on a non-merged-usr system.  I think we would like
ad hoc builds of packages from one buster machine to be installable on
other buster machines.  That is not compatible with the current
approach.

This was an unanticipated problem.  The discussion on -devel has not
reached a consensus on a way forward, and there is no transition plan.

Accordingly, please revert this change for buster.

IMO this revert should be done quickly, to minimise the number of
installs which will generate broken packages.  If you do not agree
with my proposal, then I still think we should revert the change in
sid/buster while the matter is discussed.

This affects stretch-backports too, but I think it will be most
convenient to file a separate bug for that.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
--- End Message ---
--- Begin Message ---
Le lundi, 4 mars 2019, 22.28:38 h CET Margarita Manterola a écrit :
> Hi,
> 
> > - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > 
> > The winners are:
> >  Option M `middle`
> >  Option H `hard`
> > 
> > - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > 
> > Dear Marga, as Chair, could you please make use of your casting vote to
> > break this tie?
> 
> I'm using my casting vote to vote in favor of M `middle` (i.e. consider
> that the desirable situation at the time of bullseye is that both directory
> schemes are allowed, all packages can be built on either).
> 
> My rationale for taking this decision is as follows:
> 
> Right now we are not ready to migrate to building on merged-usr systems in
> Debian, there are still 29 known packages that are broken and need to be
> fixed.  My expectation is that those packages will be fixed in the not so
> distant future (i.e.  before bullseye) and that after that, the buildd
> profile in debootstrap will default to having a merged /usr, so that new
> buildd chroots will use that setup.
> 
> However, we have no control over how fast individual developers and
> derivative distributions will migrate to the new format. It's possible that
> more time will be required until everyone is ready to migrate.
> 
> Additionally, as of our current understanding of the issue, there are no
> known problems for building on a non-merged system. Supporting this
> setup does not imply additional work from the point of view of our
> maintainers (for now).
> 
> In the future, it would be a bug if a problem is discovered with building a
> package on a non-merged /usr system. I understand that this would mean
> additional work to the maintainers of such a package, but at least as of
> today this is a non-issue. Eventually, when fixing such bugs becomes a
> significant burden for our maintainers, it can be decided that the setup is
> no-longer supported, but my personal recommendation would be to wait at
> least until bullseye+1. That's why I'm voting "Middle" for bullseye.

I have announced this decision on debian-devel-announce:
https://lists.debian.org/debian-devel-announce/2019/03/msg1.html

I am therefore hereby closing this bug.

Thank you to all involved parties!

Cheers,
OdyX

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


Bug#919951: marked as done (ocaml builder must not be called `dune' or provide /usr/bin/dune)

2019-02-25 Thread Debian Bug Tracking System
Your message dated Mon, 25 Feb 2019 11:47:56 -0600
with message-id <20190225174755.gd7...@mosca.iiec.unam.mx>
and subject line Re: Bug#919951: ocaml builder must not be called `dune' or 
provide /usr/bin/dune
has caused the Debian Bug report #919951,
regarding ocaml builder must not be called `dune' or provide /usr/bin/dune
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
919951: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919951
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte

In #919622 and the associated debian-devel thread,
 "Conflict over /usr/bin/dune"
  https://lists.debian.org/debian-devel/2019/01/msg00227.html
the file conflict over /usr/bin/dune was discussed.

The rough consensus of the debian-devel thread was that /usr/bin/dune
ought definitely not to be taken by the ocaml build system, and that
the best claim on it was the C++ library which already provides a
number of /usr/bin/dune?* binaries.

Instead, the maintainers of the ocaml package reassigned the bug
against their `dune' package to the whitedune package, which
previously provided /usr/bin/dune as a compat symlink.
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919622

They used the phrase
  "As discussed on debian-devel"
which is very misleading because it makes it sounds like there was a
consensus for this course of action, whereas the opposite is true.

Apparently as a result of this there was an NMU of `whitedune' to drop
the symlink /usr/bin/dune.
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919622#58

The maintainers of the ocaml `dune' have now uploaded `dune' (the
ocaml package) with /usr/bin/dune and Breaks+Replaces to claim the
file.
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919622#99

Meanwhile there seems to have been no contact with the maintainers of
the C++ library which is the only hit on Wikipedia for
  https://en.wikipedia.org/wiki/Dune_(software)
(Amazingly, this is still true at the time of writing even though
I referred to this fact in the debian-devel thread.)

Note that this ocaml tool `dune' was previously known as `jbuilder'.
It has nothing to do with Java AIUI.  No-one has suggested a plausible
charitable explanation for why the ocaml upstream made such
egregiously bad naming mistakes twice in succession.

Additionally the binary package name `dune' for the ocaml tool is bad,
too.


Please would the Technical Committee:

 * Declare that no-one is allowed the name /usr/bin/dune other than
   the C++ library dune-common or its friends.

 * Declare that no-one is allowed the binary package name
   /usr/bin/dune other than the C++ library dune-common
   or its friends.

 * Declare that the ocaml build system should choose a new source
   package name and use it henceforth.

I am about to file an RC bug against the `dune' package, blocked by
this one.

Ian.


-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
--- End Message ---
--- Begin Message ---
Bug report #916468 on the ownership of the /usr/bin/dune command was
opened after a quite short discussion in debian-devel¹.

¹ https://lists.debian.org/debian-devel/2018/12/msg00190.html

The Technical Committee has evaluated the situation that led to the
opening of said bug as well as this one (#919951), and in accordance
with the Procedure for the Technical Committee, 6.3.6 of the Debian
Constitution:

   The Technical Committee does not make a technical decision until
   efforts to resolve it via consensus have been tried and failed,
   unless it has been asked to make a decision by the person or body
   who would normally be responsible for it.

Together with a review of the resolution of #916468 and the last
messages in #919951, the Technical Committee recognizes the situation
as happily solved thanks to the direct interactions and good will of
both the maintainers and upstream authors of the affected packages.

Thus, not having a controversy to decide upon anymore, we have decided
to mark this bug as Closed. Furthermore, the Technical Committee
considers that, given the very short discussion the involved parties
had before raising this issue to the Committee, we should remind our
fellow Developers that any decision reached by the Technical Committee
can be seen to some as an imposition. We urge everybody to always seek
a decision by a serious, calm discussion before escalating issues.


signature.asc
Description: PGP signature
--- End Message ---


Processed: /usrr/bin/dune and `dune' binary package should refer to dune-common

2019-01-20 Thread Debian Bug Tracking System
Processing control commands:

> block -1 by 919951
Bug #919953 [dune] /usrr/bin/dune and `dune' binary package should refer to 
dune-common
919953 was not blocked by any bugs.
919953 was not blocking any bugs.
Added blocking bug(s) of 919953: 919951

-- 
919953: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919953
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: Re: Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default? /usr by default

2018-12-05 Thread Debian Bug Tracking System
Processing control commands:

> retitle 914897 tech-ctte: Should debootstrap disable merged /usr by default?
Bug #914897 [tech-ctte] debootstrap, buster: Please disabled merged /usr by 
default
Changed Bug title to 'tech-ctte: Should debootstrap disable merged /usr by 
default?' from 'debootstrap, buster: Please disabled merged /usr by default'.

-- 
914897: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914897
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

2018-11-28 Thread Debian Bug Tracking System
Processing control commands:

> reassign -1 tech-ctte
Bug #914897 [debootstrap] debootstrap, buster: Please disabled merged /usr by 
default
Bug reassigned from package 'debootstrap' to 'tech-ctte'.
Ignoring request to alter found versions of bug #914897 to the same values 
previously set
Ignoring request to alter fixed versions of bug #914897 to the same values 
previously set

-- 
914897: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914897
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#904302: marked as done (Whether vendor-specific patch series should be permitted in the archive)

2018-11-13 Thread Debian Bug Tracking System
Your message dated Tue, 13 Nov 2018 19:12:53 +0100
with message-id <87tvkk7snu@err.no>
and subject line Re: Bug#904302: Call for vote on disallowing the use dpkg's 
vendor series in the archive
has caused the Debian Bug report #904302,
regarding Whether vendor-specific patch series should be permitted in the 
archive
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
904302: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904302
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
X-debbugs-cc: debian-pol...@lists.debian.org, sunwea...@debian.org, 
ijack...@chiark.greenend.org.uk, s...@debian.org, vor...@debian.org
Control: block 850156 by -1

As a Debian Policy delegate I hereby request that the Technical
Committee decide whether a proposal that has been submitted to modify
the Debian Policy Manual should be accepted:

#850156 [n|  |  ] [dpkg-dev, debian-policy] Please firmly deprecate 
vendor-specific series files

I am making this request because we have not been able to establish
consensus, but I think this bug is one that we should not just leave
sitting open against debian-policy: if the proposal is eventually
accepted, then leaving the bug open means more vendor-specific series
files in the archive that then have to be removed.

There are currently at least 18 source packages which use
vendor-specific series files.  I have not been able to determine an
upper bound.

Before continuing to summarise the issue, I should state a conflict of
interest.  I am one of the people working on dgit, and Ian Jackson's
motivation for proposing this change is because packages with
vendor-specific series files cannot be used with dgit.  I share Ian's
desire to make dgit work with as many packages as possible, and this
might have biased the following summary.  I am, however, confident in my
judgement that this proposal should be brought before the committee.

Vendor-specific patch series are a feature of dpkg that can be used to
apply a different series of quilt patches when the source package is
unpacked on different systems.  So for example, there could be an Ubuntu
patch series alongside the default patch series, and then the results of

% dpkg-source -x foo.dsc

would be different depending on whether you are running Ubuntu or
another system (e.g. Debian).

Source packages are intended as a compressed representation of unpacked
source packages, for transportation.  But thanks to vendor-specific
patch series, it is not the case that the composition of packing and
unpacking a source package is guaranteed to be the identity function.[1]
This is very odd for a transportation format.

The practical consequences fall into two categories.  Firstly, it makes
it difficult to develop tools like dgit, which must assume that the
compressed representation works like other compressed representations.
And secondly, it can be quite confusing to users working with the
compressed representation directly.  These practical consequences are
the reasons why I think we should get this bug

For example, someone might want to use a Debian system to investigate a
bug on an Ubuntu system.  They might begin by downloading some source
packages from the Ubuntu mirrors.  Since they obtained them from Ubuntu,
they will form the reasonable expectation that unpacking these source
packages will get them the code running on the Ubuntu system they are
debugging.  But if the source packages use vendor-specific patch series,
they might get something quite different -- which, until they realise,
might completely block them from resolving the bug.  As Ian puts it,
"The version of the package you get should depend on where you got the
package from, not where you are looking at it."

On the other hand, Mike Gabriel objects to the removal of
vendor-specific patch series because they are a way of reducing the
maintainance burden for packages that need to be slightly different in
Debian and in derivatives like Ubuntu:

> My main context when working for Debian derivates is: get everything
> into Debian, bind the derivatives' devs' (wo)man(or other) power to
> Debian and allow them to achieve their goals for their derivative
> distro at the same time. Maintaining several slightly different
> src:package versions in Debian and derivative X, Y and Z costs a lot
> of time.
>
> The vendor.series file is a tiny helper tool, that eases people's day
> if working in a context I described above.
>
> With Ubuntu, where the vendor.series (i.e. ubuntu.series) file is used
&g

Processed: What should happen when maintscripts fail to restart a service

2018-07-24 Thread Debian Bug Tracking System
Processing control commands:

> block 780403 by -1
Bug #780403 [debian-policy] debian-policy: Define what should happen when 
installing a package and the init script fails to start it
Bug #802501 [debian-policy] init script failures during postinst and related 
scripts
780403 was not blocked by any bugs.
780403 was not blocking any bugs.
Added blocking bug(s) of 780403: 904558
802501 was not blocked by any bugs.
802501 was not blocking any bugs.
Added blocking bug(s) of 802501: 904558

-- 
780403: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780403
802501: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802501
904558: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904558
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: Whether vendor-specific patch series should be permitted in the archive

2018-07-22 Thread Debian Bug Tracking System
Processing control commands:

> block 850156 by -1
Bug #850156 [dpkg-dev, debian-policy] Please firmly deprecate vendor-specific 
series files
850156 was not blocked by any bugs.
850156 was not blocking any bugs.
Added blocking bug(s) of 850156: 904302

-- 
850156: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850156
904302: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904302
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#893200: marked as done (TC Chair election)

2018-03-25 Thread Debian Bug Tracking System
Your message dated Sun, 25 Mar 2018 11:14:16 +0200
with message-id <10372274.mhgyzpu...@odyx.org>
and subject line Re: Bug#893200: TC Chair election
has caused the Debian Bug report #893200,
regarding TC Chair election
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
893200: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893200
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal

Dear TC members,

With the appointment of Simon to the TC and according to our current 
procedures¹, I am hereby announcing my immediate vacation of the chair 
position, triggering a new election.

The ballot is the following:

===BEGIN===

The chair of the Debian Technical Committee will be:

A : Didier Raboud 
B : Tollef Fog Heen 
C : Phil Hands 
D : Margarita Manterola 
E : David Bremner 
F : Niko Tyni 
G : Gunnar Wolf 
H : Simon McVittie 
===END===

-- 
OdyX

¹ https://salsa.debian.org/debian/tech-ctte/blob/master/procedures/
appointment_of_the_chair.md

signature.asc
Description: This is a digitally signed message part.
--- End Message ---
--- Begin Message ---
Le samedi, 17 mars 2018, 10.25:28 h CEST Didier 'OdyX' Raboud a écrit :
> With the appointment of Simon to the TC and according to our current
> procedures¹, I am hereby announcing my immediate vacation of the chair
> position, triggering a new election.
> ===BEGIN===
> 
> The chair of the Debian Technical Committee will be:
> 
> A : Didier Raboud 
> B : Tollef Fog Heen 
> C : Phil Hands 
> D : Margarita Manterola 
> E : David Bremner 
> F : Niko Tyni 
> G : Gunnar Wolf 
> H : Simon McVittie 
> ===END===

With one week passed (§6.3.1) [0], here come the vote results:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The winners are:
 Option C "Phil Hands "
 Option D "Margarita Manterola "
 Option E "David Bremner "
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Making use of my casting vote (§A.6.8) [1,2], I hereby designate Margarita 
Manterola  as the new TC Chair, effective immediately.

Congratulations Marga!

Cheers,
OdyX


[0] Technically, Marga voted after the vote period was over; hir vote brings 
bremner to the Schwartz set. That doesn't change my casting vote though.
[1] For the first, and last time.
[2] The language I used (which is not the one from the procedure) to trigger 
the TC Chair election implies I would immediately be no longer Chair, which 
puts us in a no-casting-vote situation to designate the next Chair, which is 
very unfortunate. I've therefore assumed I was holding the Chair casting vote 
until the vote result was clear (and suggest the next Chair to phrase the 
Chair vacation message more clearly).Starting results calculation at Sun Mar 25 09:03:13 2018

/--ABCDEFGH
V: 23313345 gwolf
V: 1112 smcv
V: 11121223 odyx
V: 33112224 ntyni
V: 22111223 tfheen
V: 1333 marga
Option A "Didier Raboud "
Option B "Tollef Fog Heen "
Option C "Phil Hands "
Option D "Margarita Manterola "
Option E "David Bremner "
Option F "Niko Tyni "
Option G "Gunnar Wolf "
Option H "Simon McVittie "

In the following table, tally[row x][col y] represents the votes that
option x received over option y.

  Option
  A B C D E F G H 
===   ===   ===   ===   ===   ===   ===   === 
Option A1 1 1 1 3 3 6 
Option B  0   0 1 0 2 3 6 
Option C  2 2   1 1 4 5 6 
Option D  3 3 1   2 4 4 6 
Option E  3 3 1 2   3 4 6 
Option F  1 1 0 0 0   1 5 
Option G  1 1 0 0 0 0   5 
Option H  0 0 0 0 0 0 0   



Looking at row 2, column 1, B
received 0 votes over A

Looking at row 1, column 2, A
received 1 votes over B.

Option A Reached quorum: 6 >= 2
Option B Reached quorum: 6 >= 2
Option C Reached quorum: 6 >= 2
Option D Reached quorum: 6 >= 2
Option E Reached quorum: 6 >= 2
Option F Reached quorum: 5 >= 2
Option G Reached quorum: 5 >= 2




  Option A defeats Option B by (   1 -0) =1 votes.
  Option C defeats Option A by (   2 -1) =1 votes.
  Option D defeats Option A by (   3 -1) =2 votes.
  Option E defeats Option A by (   

Bug#877024: marked as done (modemmanager should ask before messing with serial ports)

2018-03-21 Thread Debian Bug Tracking System
Your message dated Wed, 21 Mar 2018 22:25:09 +0100
with message-id <87370tt93e@hands.com>
and subject line Re: Bug#877024: modemmanager should ask before messing with 
serial ports
has caused the Debian Bug report #877024,
regarding modemmanager should ask before messing with serial ports
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
877024: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877024
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Control: block 683839 by -1

modemmanager is a program for handling modems, particularly
usb-connected mobile-telephony modems (aka "3G/4G sticks" etc.)

Many such modems present as USB serial devices, eg ttyACM or ttyUSB.
Consequently, modemmanager has the ability to open serial ports and
probe them to see if they respond to Hayes-style AT commands.  That
functionality is currently triggered automatically by default, even
for USB serial ports whose USB device IDs are unknown to modemmanager,
or whose device IDs correspond to generic USB-to-serial adapters.

I.e., if one is running a normal Debian installation and plugs in a
usb-to-serial converter, modemmanager will open the device and send AT
commands to it, to see if it is a modem.

This behaviour is IMO unaccaptable, as a default.

Serial connections are used to connect a wide variety of equipment
including industrial robots, electronic test equipment capable of
generating hazardous voltages, accessibility hardware, scientific
instruments, and embedded computers.

In the worst case (luckily, as far as I know, hypothetical):

 * This behaviour could cause someone personal injury, if a real-world
   device connected to the serial port misinteprets modemmanager's
   probe (or if its control firmware crashes) and makes hazardous
   movements or some such

Symptoms which have been observed include:

 * User's braille display stopped working during system boot
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621851
   With a less resourceful user, that might make the computer
   completely unuseable.

 * Random number generator "interfered with"
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840697
   Ultimate consequences not clear from the bug report, but if the RNG
   driver software has poor error handling it might include poor
   quality random numbers and therefore weak cryptographic keys.

 * GPS no longer recognised at boot
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798193
   (Not as trivial a problem as it sounds, as it could prevent the
   system being used as a navigation aid.)

 * "Breaks" apcupsd
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#32

 * User's Palm Pilot PDA crashes
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#52

 * User's 1-wire DS9097 interface is messed up, requiring a
   reboot to become functional again
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#72

 * My 3D printer reported protocol violations on startup
   and host software could sometimes not connect to printer
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#5

Other possible consequences which have been hypothesised are:

 * Simply opening the port and enabling RTS might enable radio
   transmissions in a ham radio context
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#42
   (Resulting in possibly-illegal radio interference.)

 * Simply opening the port and enabling RTS switches some scientific
   equipment into remote control mode, disabling the front panel
   and perhaps leading to hazardous situations.  (pers. comm)

 * Some 3D printers will reset when RTS is toggled, interrupting
   any print job (causing real world lossage in the form of wasted
   feedstock and printer time)
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#32

In August 2012 I experienced this bug and filed #683839 with severity
`important'.  The maintainers apparently do not agree with my analysis
and there has been no action by them since then other than efforts to
maintain the blocklist.

In the intervening time many users have reported manifestations of
this problem to #683839 and to other bug reports.  The reactions from
the maintainers have consistently been to try to get individual
devices blocklisted, even though as has been explained repeatedly,
this is not really sufficient.  The maintainers have not engaged with
the arguments against blanket probing.

Note that safe behaviour does not necessarily mean that every time the
user plugs in their modem, 

Bug#880014: marked as done (2018 - New TC member)

2018-03-12 Thread Debian Bug Tracking System
Your message dated Mon, 12 Mar 2018 08:34:02 +0100
with message-id <1827597.wfcqqap...@odyx.org>
and subject line Re: Bug#880014: Call for Votes for new TC member
has caused the Debian Bug report #880014,
regarding 2018 - New TC member
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
880014: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880014
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
User: tech-c...@packages.debian.org

According to our Constitution's §6.2, Keith's term will expire at the end of
this year, freeing one seat on the TC from January 1st 2018 on.

This bug will track that process.
--- End Message ---
--- Begin Message ---
Le dimanche, 4 mars 2018, 11.44:45 h CET Didier 'OdyX' Raboud a écrit :
> I call for votes on the following ballot to fill a vacant seat in the TC.
> The voting period starts immediately and lasts for up to one week, or until
> the outcome is no longer in doubt (§6.3.1).
> 
> ===BEGIN
> The Technical Committee recommends that Simon McVittie  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> S: Recommend to Appoint Simon McVittie <s...@debian.org>
> F: Further Discussion
> ===END


With five votes in favour and a week gone, the result of this vote is no
longer in doubt:

  The Technical Committee recommends that Simon McVittie  be
  appointed by the Debian Project Leader to the Technical Committee.

@Chris: it's in your hands now. 

Cheers,
OdyX

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


Bug#881339: marked as done (allow node-babel-preset-env to build depend on itself)

2018-02-21 Thread Debian Bug Tracking System
Your message dated Wed, 21 Feb 2018 19:54:43 +0100
with message-id <2a308575644ced7853bf3b37f4f64...@debian.org>
and subject line Closing without action: the TC can't overrule delegates
has caused the Debian Bug report #881339,
regarding allow node-babel-preset-env to build depend on itself
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
881339: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881339
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte

node-babel-preset-env is a collections of plugins for babel transpiler
(node-babel package).

Babel is a transpiler to convert source written in new versions of
javascript to code that can be run by current versions of javascript
runtimes like nodejs and browsers.

node-babel-preset-env uses its own binary package during build. This is
similar to  how other packages currently in the archive which were
circularly build depending, like node-babel build depends on itself and
node-babylon, then node-babylon build depends on node-babel (this was
the same case of jison and one of its build dependencies). In these
situations a binary included upload had to be used to bootstrap and
later versions can just be built in main using the previous versions. I
don't think node-babel-preset is in principle any different from
node-babel, node-babylon or jison.

But node-babel-preset-env was rejected "it is strange that the package
Build-Depends: on itself!?"

http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2017-November/022197.html

Alternatives would be to use another transpiler to build the package.
But I don't think that should be required as a condition as it means
this same principle will need to be applied for other packages already
in main. Is gcc built using a different compiler?

I would like to ask CTTE to consider this case and overrule ftp masters
decision and allow node-babel-preset-env to be in main as it has dfsg
compliant license, has corresponding source and can be built using tools
in main (with an initial bootstrapping).




signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---

Hi!

I'm sorry this took so long to be actioned by us. This is on me.

In previous bugs that have been raised to the technical committee
it has already been discussed and agreed that the technical
committee does not have the power to overrule official Debian
delegates.  This covers the decisions taken for example by the
FTP Masters or the Release Team.

Thus, we are closing this bug now, as it's not actionable.

We suggest that you work together with the FTP Masters in
figuring out a solution to this problem.

--
Thanks.
Marga, on behalf of the Technical Committee.--- End Message ---


Bug#883573: marked as done (Reevaluate libpam-systemd systemd-sysv dependency ordering (746578))

2018-02-16 Thread Debian Bug Tracking System
Your message dated Fri, 16 Feb 2018 09:57:15 +0100
with message-id <2258543.kbqryqo...@odyx.org>
and subject line Re: Bug#883573: Call for vote on waiving libpam-systemd 
dependencies' ordering
has caused the Debian Bug report #883573,
regarding Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
883573: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883573
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal
Control: block 883569 by -1

Dear CTTE,

In 746578, the CTTE decided that the dependency be swapped
to systemd-shim | systemd-sysv in order to prevent systems
from being upgraded installing systemd.

This argument should be moot now. Either dependency is satisfied
on systems now, so an upgrade won't change anything.

More importantly, several packages now require just systemd-sysv. If
apt is told to install libpam-systemd and such a package in the same
operation (especially in a chroot I'd say, since that's where neither
shim nor sysv is installed), it may fail to resolve dependencies
because it picks systemd-shim first and fails to replace it with
systemd-sysv later. See #883555 for an example.

I thus opened bug 883569 against systemd, but mbiebl would like to
get permission from the you first.

> Package: libpam-systemd
> Version: 235-3
> Severity: important
>
> libpam-systemd depending on systemd-shim first causes severe trouble with
> resolving dependencies, as APT picks systemd-shim but then later sees a
> package which needs systemd-sysv and fails.
>
> I understand the order was necessary for preventing upgrades to stretch
> from migrating to systemd, but with the packages now widely installed,
> this should not be a problem anymore, as the dependencies are satisfied
> already, so APT won't switch them.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (500, 'unstable-debug'), 
(500, 'testing-debug'), (100, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en
--- End Message ---
--- Begin Message ---
Le vendredi, 9 février 2018, 09.14:49 h CET Didier 'OdyX' Raboud a écrit :
> === Resolution ===
> 
> In 2014, it was resolved in #746578 that the libpam-systemd binary package
> alternative dependency on systemd-shim and systemd-sysv shall be set in that
> order, in order to avoid unwanted init system changes accross upgrades.
> Debian Stretch has since been released.
> 
> The Committee therefore resolves that:
> 
> 1. The Technical Commitee decision from 2014-11-15 in bug #746578 is
> repealed.
> 
> This means Debian's normal policies and practices take over and the
> libpam-systemd package's dependencies are set free from specific ordering
> constraints.  The migration should be managed according to Debian's usual
> backwards-compatibility arrangements.
> 
> === End Resolution ===

A week is gone and all 6 submitted votes are all in favour; the TC adopts the 
above resolution. Thank you for your patience.

I will send a short d-d-a email today.

Cheers,
OdyX

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


Bug#889493: marked as done (tech-ctte: Please review if systemd is reliable enough to be the default)

2018-02-03 Thread Debian Bug Tracking System
Your message dated Sat, 03 Feb 2018 22:22:19 +0100
with message-id <87o9l5ojjo@whist.hands.com>
and subject line Re: Bug#889493: tech-ctte: Please review if systemd is 
reliable enough to be the default
has caused the Debian Bug report #889493,
regarding tech-ctte: Please review if systemd is reliable enough to be the 
default
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
889493: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889493
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: important

First of all, thank you very much for sharing your
time and expertise with the debian project.

I'm happy to report I've been using it 24x7 since 1996.


The main reason I'm writing is that it seems to
me 

1.) the committee decided in 2014 that systemd
would be the default init system[1].

2.) enough

a.) years have passed,

b.) committee members have changed[2] and

c.) bugs have been reported[3]

to re-evaluate whether systemd is reliable enough
to be debian's default init system.

So,
Kingsley

[1] [CTTE #727708] Default init system for Debian
https://lists.debian.org/debian-devel-announce/2014/02/msg5.html

[2] WikiPedia
systemd
https://en.wikipedia.org/wiki/Systemd

"In November 2014 Debian maintainers and
Technical Committee members Joey Hess,[81]
Russ Allbery,[82] Ian Jackson[83] and systemd
package-maintainer Tollef Fog Heen[84]
resigned from their positions."

[3] Debian Bug report logs: Bugs in package systemd
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dist=stable

--- End Message ---
--- Begin Message ---
On Sat, 03 Feb 2018, "Kingsley G. Morse Jr." <kings...@loaner.com> wrote:
> Package: tech-ctte

I don't formally have the right to simply close this bug (as I am now
doing), so if anyone else on the TC thinks there is any merit whatsoever
in this bug report, please feel free to reopen it.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature
--- End Message ---


Bug#886267: marked as done (Voting for TC Chair)

2018-01-17 Thread Debian Bug Tracking System
Your message dated Wed, 17 Jan 2018 21:02:19 +0100
with message-id <3104916.cnd2nar...@odyx.org>
and subject line Re: Voting for TC Chair
has caused the Debian Bug report #886267,
regarding Voting for TC Chair
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
886267: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886267
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal

Dear TC members,

With the appointment of Gunnar to the TC, Keith's term expiry and according to 
our current procedures¹, I am hereby announcing my immediate vacation of the 
chair position, triggering a new election. For clarity of the process, I am 
interested to continue serving as chair.

The ballot is the following:

===BEGIN===

The chair of the Debian Technical Committee will be:

A: Didier Raboud 
B: Tollef Fog Heen 
C: Phil Hands 
D: Margarita Manterola 
E: David Bremner 
F: Niko Tyni 
G: Gunnar Wolf 
===END===

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.
--- End Message ---
--- Begin Message ---
Dear TC,

With five votes in, and more than two week passed, I am apparently becoming 
the Technical Committee chair again. Thank you for your trust!

As was mentionned during today's IRC meeting; given my term's expiry at the 
end of 2018, it makes sense for someone else to take that role over somewhen 
during this year, for a smooth transition. It makese a lot of sense for myself 
too; I will therefore step down sometimes in summer, or at the next automatic 
vote.

./run_vote.sh | sed -e '/^$/d'
Starting results calculation at Wed Jan 17 19:37:23 2018
/--ABCDEFG
V: 134 ntyni
V: 123 gwolf
V: 113 bremner
V: 1221223 philh
V: 111 odyx
Option A "Didier Raboud "
Option B "Tollef Fog Heen "
Option C "Phil Hands "
Option D "Margarita Manterola "
Option E "David Bremner "
Option F "Niko Tyni "
Option G "Gunnar Wolf "
In the following table, tally[row x][col y] represents the votes that
option x received over option y.
  Option
  A B C D E F G 
===   ===   ===   ===   ===   ===   === 
Option A3 4 3 4 4 4 
Option B  0   1 1 1 2 4 
Option C  0 0   0 0 1 4 
Option D  0 1 1   1 2 4 
Option E  0 0 0 0   1 4 
Option F  0 0 0 0 0   4 
Option G  0 0 0 0 0 0   
Looking at row 2, column 1, B
received 0 votes over A
Looking at row 1, column 2, A
received 3 votes over B.
Option A Reached quorum: 4 >= 2
Option B Reached quorum: 4 >= 2
Option C Reached quorum: 4 >= 2
Option D Reached quorum: 4 >= 2
Option E Reached quorum: 4 >= 2
Option F Reached quorum: 4 >= 2
  Option A defeats Option B by (   3 -0) =3 votes.
  Option A defeats Option C by (   4 -0) =4 votes.
  Option A defeats Option D by (   3 -0) =3 votes.
  Option A defeats Option E by (   4 -0) =4 votes.
  Option A defeats Option F by (   4 -0) =4 votes.
  Option A defeats Option G by (   4 -0) =4 votes.
  Option B defeats Option C by (   1 -0) =1 votes.
  Option B defeats Option E by (   1 -0) =1 votes.
  Option B defeats Option F by (   2 -0) =2 votes.
  Option B defeats Option G by (   4 -0) =4 votes.
  Option D defeats Option C by (   1 -0) =1 votes.
  Option C defeats Option F by (   1 -0) =1 votes.
  Option C defeats Option G by (   4 -0) =4 votes.
  Option D defeats Option E by (   1 -0) =1 votes.
  Option D defeats Option F by (   2 -0) =2 votes.
  Option D defeats Option G by (   4 -0) =4 votes.
  Option E defeats Option F by (   1 -0) =1 votes.
  Option E defeats Option G by (   4 -0) =4 votes.
  Option F defeats Option G by (   4 -0) =4 votes.
The Schwartz Set contains:
 Option A "Didier Raboud "
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The winners are:
 Option A "Didier Raboud "
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-- 
OdyX

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


Processed: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)

2017-12-05 Thread Debian Bug Tracking System
Processing control commands:

> block 883569 by -1
Bug #883569 [libpam-systemd] libpam-systemd: Prefer systemd-sysv over 
systemd-shim
883569 was not blocked by any bugs.
883569 was not blocking any bugs.
Added blocking bug(s) of 883569: 883573

-- 
883569: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883569
883573: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883573
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: modemmanager should ask before messing with serial ports

2017-09-27 Thread Debian Bug Tracking System
Processing control commands:

> block 683839 by -1
Bug #683839 [modemmanager] modemmanager fiddles with ttyUSB devices without 
asking first
683839 was not blocked by any bugs.
683839 was not blocking any bugs.
Added blocking bug(s) of 683839: 877024

-- 
683839: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839
877024: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877024
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#865929: marked as done (Advice on dealing with GRUB upgrade failure caused by init-select)

2017-08-16 Thread Debian Bug Tracking System
Your message dated Wed, 16 Aug 2017 18:58:32 +0200
with message-id <878tija1qf@whist.hands.com>
and subject line Re: Bug#865929: Advice on dealing with GRUB upgrade failure 
caused by init-select
has caused the Debian Bug report #865929,
regarding Advice on dealing with GRUB upgrade failure caused by init-select
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
865929: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865929
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte

Preamble


I would like to seek advice from the Technical Committee on the proper
resolution of #863801.  This is (for once) not a matter of
irreconcilable disagreement among developers, but one where the only
sensible technical resolutions I can see are in clear conflict with
generally-reasonable requirements in policy.

Constitutional status
-

My belief is that I would ordinarily be responsible for this decision in
my capacity as the main active maintainer of grub2, and that in the
circumstances I could keep the policy violation narrow enough that it's
unlikely that anyone would be particularly inclined to make an issue of
it.  However, on advice from debian-devel, I'm seeking advice under
§6.1(3) anyway because of the unusual situation (and so I believe that
the "last resort" injunction in §6.3(6) does not apply).

It may be that the right thing to do involves changing our technical
policy documents, but since I'm not absolutely sure of the correct
approach yet I haven't troubled the policy list with a discussion on
that, so I'm not asking for a decision under §6.1(1); I'm happy to
propose policy changes if the committee believes that to be part of a
proper resolution.

Summary
---

init-select was introduced in January 2014 around the time of the init
system debate, with the intent of providing a straightforward way for a
user to select a non-default init daemon.  It provides a debconf
interface to select between sysvinit, systemd, and openrc (and formerly
upstart as well).  It operates by setting a variable in
/etc/default/init, and installing a conffile in
/etc/default/grub.d/init-select.cfg which adds an init= parameter to the
default kernel command line set by GRUB.

The grub2 extension facility used by init-select was added by me,
unrelatedly, in January 2013.  At present it's maintained as a
Debian-specific patch to source /etc/default/grub.d/*.cfg after
/etc/default/grub, in the spirit of many other such *.d directories in
Debian.  Any error in sourcing any of these files will cause
grub-mkconfig to exit non-zero: while this is partly due to the usual
shell "set -e" rules and would be quite difficult to avoid, I also think
it's generally appropriate here.

The conffile installed by init-select has a bug of a kind often found in
conffiles that arrange to execute programs: when init-select has been
removed but not purged, it will fail (exiting non-zero) rather than
realising that it is in a removed-but-not-purged state and silently
doing nothing.  This results in various grub2 binary packages failing to
upgrade when init-select is in this state.

init-select was removed from stretch because of #830897: it depends on
sysvinit, which was a transitional package in jessie and was removed
from the archive in stretch.  The appropriate fix would have been to
depend on sysvinit-core instead, but the maintainer did not react and no
other developer chose to issue an NMU.  As a result, it will typically
be removed as part of upgrades from jessie to stretch, exposing any
users who had previously installed it to #863801.

init-select was removed from unstable in response to #865752, following
a discussion about this general problem on debian-devel.

Considering the upgrade problems that may result from this, I'd like to
find a solution that I can reasonably implement in a point release of
stretch.

Possible grub2 changes
--

These are laid out in more detail in my debian-devel post, linked below.

I considered but rejected the idea of having grub-mkconfig explicitly
ignore errors from /etc/default/grub.d/init-select.cfg, or having it
ignore that file altogether.  That option offers no long-term cleanup
path, and so I would have to retain an ugly patch in perpetuity.

I could have NMUed init-select in both unstable and stretch with a
corrected conffile (and probably also with a corrected sysvinit
dependency), and then arranged for the relevant grub2 postinst scripts
to replace /etc/default/grub.d/init-select.cfg wit

Processed: Re: Bug#839172: TC decision regarding #741573 menu policy not reflected yet

2017-08-03 Thread Debian Bug Tracking System
Processing control commands:

> reassign -1 debian-policy 4.0.0.4
Bug #839172 [tech-ctte] TC decision regarding #741573 menu policy not reflected 
yet
Bug reassigned from package 'tech-ctte' to 'debian-policy'.
Ignoring request to alter found versions of bug #839172 to the same values 
previously set
Ignoring request to alter fixed versions of bug #839172 to the same values 
previously set
Bug #839172 [debian-policy] TC decision regarding #741573 menu policy not 
reflected yet
Marked as found in versions debian-policy/4.0.0.4.
> affects -1 + tech-ctte
Bug #839172 [debian-policy] TC decision regarding #741573 menu policy not 
reflected yet
Added indication that 839172 affects tech-ctte

-- 
839172: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839172
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#862051: marked as done (Rename nodejs back to node for buster, now that ax25-node has been removed?)

2017-08-01 Thread Debian Bug Tracking System
Your message dated Tue, 01 Aug 2017 22:12:40 +0200
with message-id <87tw1rjbd3@err.no>
and subject line [Tollef Fog Heen] Bug#862051: Call for vote on allowing nodejs 
to provide /usr/bin/node
has caused the Debian Bug report #862051,
regarding Rename nodejs back to node for buster, now that ax25-node has been 
removed?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
862051: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862051
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: nodejs-legacy
Version: 4.8.2~dfsg-1
Severity: wishlist

Hi maintainers,

Back in 2015, ax25-node (and the "node" package following) were removed citing
lack of activity:
https://packages.qa.debian.org/n/node/news/20150915T000109Z.html

Would it be possible to drop nodejs-legacy in the next Debian release and
rename nodejs back to node? IMO doing so would make working with JS programs
outside of Debian a lot easier.

Best,
James



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (700, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nodejs-legacy depends on:
ii  nodejs  4.8.2~dfsg-1

nodejs-legacy recommends no packages.

nodejs-legacy suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---

Closing this bug now, since it's been resolved.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are--- End Message ---


Bug#865485: marked as done (Voting for TC Chair)

2017-07-05 Thread Debian Bug Tracking System
Your message dated Wed, 05 Jul 2017 08:58:52 +0200
with message-id <5474183.cskpvdc...@odyx.org>
and subject line Re: Bug#865485: Voting for TC Chair
has caused the Debian Bug report #865485,
regarding Voting for TC Chair
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
865485: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865485
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal

Dear TC members,

With the appointment of Niko to the TC and according to our current 
procedures¹, I am hereby announcing my immediate vacation of the chair 
position, triggering a new election. For clarity of the process, I am 
interested to continue serving as chair.

The ballot is the following:

===BEGIN===

The chair of the Debian Technical Committee will be:

A: Keith Packard 
B: Didier Raboud 
C: Tollef Fog Heen 
D: Sam Hartman 
E: Phil Hands 
F: Margarita Manterola 
G: David Bremner 
H: Niko Tyni 
===END===

-- 
Cheers,
OdyX


signature.asc
Description: This is a digitally signed message part.
--- End Message ---
--- Begin Message ---
Dear TC,

With four votes in, but more than one week  passed, I am apparently 
becoming 
the Technical Committee chair again. Thank you for your trust!

$ ./run_vote.sh
Starting results calculation at Wed Jul  5 06:57:01 2017
/--ABCDEFGH
V: 2123 keithp
V: 51332444 odyx
V: 31333234 philh
V: 2122 ntyni
Option A "Keith Packard "
Option B "Didier Raboud "
Option C "Tollef Fog Heen "
Option D "Sam Hartman "
Option E "Phil Hands "
Option F "Margarita Manterola "
Option G "David Bremner "
Option H "Niko Tyni "

(…)
In the following table, tally[row x][col y] represents the votes that
option x received over option y.

  Option
  A B C D E F G H 
===   ===   ===   ===   ===   ===   ===   === 
Option A0 0 0 0 0 0 2 
Option B  4   4 4 4 4 4 4 
Option C  1 0   0 0 1 1 3 
Option D  1 0 0   0 1 1 3 
Option E  1 0 1 1   1 1 3 
Option F  2 0 1 1 1   1 2 
Option G  1 0 0 0 0 0   2 
Option H  1 0 0 0 0 0 0   

(…)

The Schwartz Set contains:
 Option B "Didier Raboud "

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The winners are:
 Option B "Didier Raboud "

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


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


Processed: Re: Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select

2017-07-02 Thread Debian Bug Tracking System
Processing control commands:

> block 866643 with -1
Bug #866643 [release.debian.org] jessie-pu: package 
init-select/1.20140921+deb8u1
866643 was not blocked by any bugs.
866643 was not blocking any bugs.
Added blocking bug(s) of 866643: 865929

-- 
865929: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865929
866643: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866643
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#836127: marked as done (New CTTE Members)

2017-06-21 Thread Debian Bug Tracking System
Your message dated Wed, 21 Jun 2017 12:21:56 +0200
with message-id <1576982.ljvjtqg...@odyx.org>
and subject line Re: Bug#836127: Call for Votes for new TC member
has caused the Debian Bug report #836127,
regarding New CTTE Members
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
836127: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836127
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
User: tech-c...@packages.debian.org
Usertag: discussion

With aba and myself terming out at the end of this year, we need up to
two new members.

This bug will track that process.

-- 
Don Armstrong  https://www.donarmstrong.com

I have no use for "before and after" pictures.
I can't remember starting, and I'm never done.
 -- a softer world #221
http://www.asofterworld.com/index.php?id=221
--- End Message ---
--- Begin Message ---
> ===BEGIN
> The Technical Committee recommends that Niko Tyni <nt...@debian.org> be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> N: Recommend to Appoint Niko Tyni <nt...@debian.org>
> F: Further Discussion
> ===END

With six votes in favour and a week gone, the result of this vote is now 
longer in doubt:

The TC recommends that Niko Tyni  be appointed by the Debian Project 
Leader to the Technical Committee.

@Chris: it's in your hands now; I'm hereby closing this bug as not a concern 
for the TC anymore.

Cheers,
OdyX

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


Processed: Fix cut-off title for #862051

2017-05-18 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> # Fix the butchered title due to word wrap
> retitle 862051 Rename nodejs back to node for buster, now that ax25-node has 
> been removed?
Bug #862051 [tech-ctte] Rename nodejs back to node for buster, now that
Changed Bug title to 'Rename nodejs back to node for buster, now that ax25-node 
has been removed?' from 'Rename nodejs back to node for buster, now that'.
> thanks
Stopping processing here.

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



Processed: Refer #862051 to ctte (WAS: nodejs-legacy: possibly drop this package, now that ax25-node has been removed?)

2017-05-18 Thread Debian Bug Tracking System
Processing control commands:

> reassign -1 tech-ctte
Bug #862051 [nodejs-legacy] nodejs-legacy: possibly drop this package, now that 
ax25-node has been removed?
Bug reassigned from package 'nodejs-legacy' to 'tech-ctte'.
No longer marked as found in versions nodejs/6.10.2~dfsg-1 and 
nodejs/4.8.2~dfsg-1.
Ignoring request to alter fixed versions of bug #862051 to the same values 
previously set
> retitle -1 Rename nodejs back to node for buster, now that
Bug #862051 [tech-ctte] nodejs-legacy: possibly drop this package, now that 
ax25-node has been removed?
Changed Bug title to 'Rename nodejs back to node for buster, now that' from 
'nodejs-legacy: possibly drop this package, now that ax25-node has been 
removed?'.

-- 
862051: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862051
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#860520: marked as done (Voting for TC Chair)

2017-04-25 Thread Debian Bug Tracking System
Your message dated Tue, 25 Apr 2017 22:08:40 +0200
with message-id <6257155.sz62klx...@odyx.org>
and subject line Re: Bug#860520: Voting for TC Chair
has caused the Debian Bug report #860520,
regarding Voting for TC Chair
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
860520: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860520
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal

Dear TC members,

With the appointment of David to the TC and according to our current 
procedures¹, I am hereby announcing my immediate vacation of the chair 
position, triggering a new election. For clarity of the process, I am 
interested to continue serving as chair.

The ballot is the following:

===BEGIN===

The chair of the Debian Technical Committee will be:

A: Keith Packard 
B: Didier Raboud 
C: Tollef Fog Heen 
D: Sam Hartman 
E: Phil Hands 
F: Margarita Manterola 
G: David Bremner 
===END===

-- 
Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.
--- End Message ---
--- Begin Message ---
Dear TC,

With all our votes in, I am apparently becoming the Technical Committee chair 
again. Thank you for your trust!

$ ./860520_chair_election/run_vote.sh 
Starting results calculation at Tue Apr 25 20:00:00 2017

/--ABCDEFG
V: 5133244 odyx
V: 4143424 hartmans
V: 213 keithp
V: 2122232 marga
V: 2121223 bremner
V: 312 philh
V: 3132233 tfheen
Option A "Keith Packard "
Option B "Didier Raboud "
Option C "Tollef Fog Heen "
Option D "Sam Hartman "
Option E "Phil Hands "
Option F "Margarita Manterola "
Option G "David Bremner "

In the following table, tally[row x][col y] represents the votes that option x 
received over option y.

  Option
  A B C D E F G 
===   ===   ===   ===   ===   ===   === 
Option A0 0 0 0 1 2 
Option B  7   7 6 7 7 7 
Option C  2 0   0 0 2 3 
Option D  5 0 3   2 4 5 
Option E  3 0 2 1   3 4 
Option F  3 0 1 1 1   3 
Option G  2 0 0 0 0 1   

Looking at row 2, column 1, B received 7 votes over A
Looking at row 1, column 2, A received 0 votes over B

Option A Reached quorum: 2 >= 2
Option B Reached quorum: 7 >= 2
Option C Reached quorum: 3 >= 2
Option D Reached quorum: 5 >= 2
Option E Reached quorum: 4 >= 2
Option F Reached quorum: 3 >= 2

Dropping Option A because of Majority. (1)  1.000 (2/2) <= 1
Option F passes Majority.   3.000 (3/1) > 1

  Option B defeats Option C by (   7 -0) =7 votes.
  Option B defeats Option D by (   6 -0) =6 votes.
  Option B defeats Option E by (   7 -0) =7 votes.
  Option B defeats Option F by (   7 -0) =7 votes.
  Option B defeats Option G by (   7 -0) =7 votes.
  Option D defeats Option C by (   3 -0) =3 votes.
  Option E defeats Option C by (   2 -0) =2 votes.
  Option C defeats Option F by (   2 -1) =1 votes.
  Option C defeats Option G by (   3 -0) =3 votes.
  Option D defeats Option E by (   2 -1) =1 votes.
  Option D defeats Option F by (   4 -1) =3 votes.
  Option D defeats Option G by (   5 -0) =5 votes.
  Option E defeats Option F by (   3 -1) =2 votes.
  Option E defeats Option G by (   4 -0) =4 votes.
  Option F defeats Option G by (   3 -1) =2 votes.

The Schwartz Set contains:
 Option B "Didier Raboud "
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The winners are:
 Option B "Didier Raboud "
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

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


Bug#846002: marked as done (blends-tasks must not be priority:important)

2017-04-22 Thread Debian Bug Tracking System
Your message dated Sat, 22 Apr 2017 15:51:16 +0200
with message-id <06fbeee5aa0d712149209bff5ce49...@nefele.gnuservers.com.ar>
and subject line Closing the bug with the resolution approved in February
has caused the Debian Bug report #846002,
regarding blends-tasks must not be priority:important
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
846002: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846002
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: blends
Version: 0.6.94
Severity: serious
Tags: d-i
Justification: Policy 2.5 and breaking another package

Hi,

I'm sorry, but the current implementation of installing Blends from Debian
images is simply not acceptable, as in, it completely breaks the UI of
debian-installer thus the severity. (It's also an unacceptable policy
violation, see below.)

For those wondering what the current implementation looks like, have a look at
https://lists.debian.org/debian-blends/2016/05/pngVVl6XLXLxZ.png 

In words: several blends have been added to the tasksel menu (the one which
asks which tasks should be installed, "default", "standard", "desktop",
"ssh-server", etc.)

The ascii version of the above linked screenshot looks like this:

--begin--

At the moment, only the core of the system is installed. To tune the system to 
your needs, you can
choose to install one or more of the following predefined collections of 
software.
Choon software to install.'
o webserver  _
0 printserver
O SSHserver
0 standard system utilities
O Debian Pure Blends
  o  Deb;
O.  DebianEdu
O.  DebianEzGa
O.  DebianGames
O.  DebianGIS
O.  Hamradia
O.  DebianJunior
O.  DebianMed
O.  DebianMultimedia
O ... Debian Science

-- end --

This aint acceptable for a debian-installer for the reasons laid out in 
#758116. 

Look for those two mails from bubulle in that bug, they explain very well, 
that+why 
the current implementation is a *no go*:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#320
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#340

Technically this was implemented by setting the binary package blends-tasks to 
prio: important, which needs to be reverted to fix the current tasksel mess.

Also, setting blends-tasks to priority:important is a policy violation, please
read https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities
- packages with priority:important are installed by default, and there is 
*no* need (as it doesnt make sense, it's not useful) to have blends-tasks
installed by default on each and every Debian system.

(I'm sorry if describing 
https://lists.debian.org/debian-blends/2016/05/pngVVl6XLXLxZ.png
as a mess hurts some people. I dont know a better way to put it.)


So how to fix this *and* allow Debian blends be installed easily from
official Debian media?


My idea to implement official Debian which can be used to install blends is to
introduce "flavors" (or spins or whatever, just a new term, to not overload old
ones), which basically are themed netinstall images.

For illustration, these are some netinstall image _flavors_/_spins_ I have in 
mind:

debian-classic / textmode d-i
debian-graphical installer
blends selection (graphical)
debian-edu blend (graphical)
debian-parl blend (graphical)
debian-speakup (textmode d-i with speech enabled by default)
…


The idea is, that these images have the *same features* (and packages), the
differences are just which the preselected default in the boot menu.

So they all have the same boot menu too, and it's possible to install each
and every flavor by manually choosing a different boot menu.

This has several benefits:
- it's possible to tell people "download $this iso to install $this type of
  Debian"
- without giving them congnitive stress by presenting them choices they dont
  understand
- the boot menu is also not translatetable, so having choices there wont help
  many users. 
- this can be implemented for stretch. Major changes (especially ones
  requiring translations) are not likely to happen anymore, so this is one
  way to have official Debian blends images *at all*. (As said, the current
  implementation is not acceptable.)
- the current implementation is also useless for Debian Edu and at least 
  very inconvinient for other "non-standalone" blends (those who also need the
  desktop task to be installed), not all blends are self contained. 

Bug#850887: marked as done (Decide proper solution for binutils' mips* bug)

2017-04-19 Thread Debian Bug Tracking System
Your message dated Wed, 19 Apr 2017 15:27:13 -0400
with message-id <tsl37d4jizy@suchdamage.org>
and subject line MIPS binutils for stretch
has caused the Debian Bug report #850887,
regarding Decide proper solution for binutils' mips* bug
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
850887: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850887
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal

Hi! Before stating the issue at hand I would like to address the fact that
this issue needs a quick solution as many packages are not able to
enter testing and we are near the freeze.

I would like the TC to address a solution for bug #844227. It's a binutils
bug that makes lots of packages FTBFS on mips*.

There are currently two proposed patches upstream, but upstream would like
to find a generic solution before considering accepting them, and encouraged
us to use either of them in the meantime [comment12].

[comment12] <https://sourceware.org/bugzilla/show_bug.cgi?id=20828#c12>

I proposed a patch that exclusively works on mips* to leave aside possible
bugs for other archs, see [patch].

[patch] <https://bugs.debian.org/cgi-bin/bugreport.cgi?
att=1;bug=844227;filename=844227_workaround_v2.patch;msg=144>

Yes, I happened to miss Matthias' request to not upload the patch due to a bad
spam filter, and I would like to use this opportunity to present once again
my apologies for that.

Problem is that we still have the bug affecting us.
binutils maintainer states in [m149]:

  [..] I'm fine to apply work arounds for port architectures, but not
  for release architectures (I didn't decide on this status).  The binutils 
update
  plan was announced last June [1], and I plan to stick to it.  At least one 
of
  the mips toolchain maintainers (out of the five who committed to in the
  architecture qualification process) seems to address RC issues, and 
according to
  the upstream issue, there's work in progress.

[m149] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844227#149> 

While I do totally agree with Matthias that an upstream-approved fix is indeed
the best possible way out of this, in the meantime we have been dealing with
this bug almost two months now, and it's hindering the effort of many other
package maintainers not being able to get their packages into testing on
time for the release.

I would also like to note that I could not fully test my proposed patch 
because
I can build the package on a porterbox but not use it later to build other
stuff. Of course I'll be more than happy to do this if there is a way for me
to do it.

So my question is: how can we fix this issue? Should we ask binutils 
maintainer
to apply the patch (or let someone else do it), should we leave this matter
as it is or should we take any other further way of action?

Kinds regards, Lisandro.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'testing-
debug'), (500, 'buildd-unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---

The committee would like to thank everyone who was involved in this
discussion for helping us get to a mips binutils that is working for
stretch.

It sounded like Matthias  wanted to add some extra thoughts going
forward.  In closing the bug we're not closing off any future discussion
simply noting that this is no longer an issue before the committee.

As an individual, I note that this is the second significant issue
brought before the TC in the stretch time frame with regard to the
toolchain.
Communication was somewhat challenging on both issues.
The project as a whole might want to consider how we can better balance
these issues and get folks working on the toolchain the resources they
need both to produce an effective toolchain and to communicate with the
rest of the project.
The committee is of course available for a resource if useful in such a
discussion.--- End Message ---


Bug#857257: marked as done (Supporting configuration file changes between versions in unstable/testing)

2017-03-22 Thread Debian Bug Tracking System
Your message dated Wed, 22 Mar 2017 21:10:46 +0100
with message-id <878tnx5ayh@err.no>
and subject line Re: Bug#857257: Re: Supporting configuration file changes 
between versions in unstable/testing
has caused the Debian Bug report #857257,
regarding Supporting configuration file changes between versions in 
unstable/testing
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
857257: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857257
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Control: block 856606 by -1

Hi,

#856606 is filed as a serious bug against gitlab version 8.13.11+dfsg-4
in unstable as upgrading from 8.13.11+dfsg-3 in testing fails because
/etc/gitlab/gitlab-debian.conf is changed in the new version. I think
this should not be considered an RC bug as it will require making
complicated changes in postinst to support a configuration file that was
never part of any stable release. It is much simpler to make this change
manually and I think it is reasonable to expect users who use testing or
unstable to make those changes manually. Such a requirement will make
changes in unstable/testing much harder than required. I fully agree to
support upgrading between versions in stable releases.

This was the change made to /etc/gitlab/gitlab-debian.conf:

-nginx_conf_example=/usr/share/doc/gitlab/nginx.conf.example
-nginx_ssl_conf_example_gz=/usr/share/doc/gitlab/nginx.ssl.conf.example.gz
+nginx_conf_example=/usr/lib/gitlab/templates/nginx.conf.example
+nginx_ssl_conf_example=/usr/lib/gitlab/templates/nginx.ssl.conf.example

I request CTTE to declare this bug as not RC.



signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
]] "Adam D. Barratt" 

> [this doesn't appear to have reached the tech-ctte list yet, so I'm
> replying from the BTS archive]

We've decided to close this bug. It's pretty clear that supporting
upgrades, also within unreleased suites, is a requirement, even if it's
not formally documented in Policy.

If you want to conduct experiments where you don't want to support
upgrades, use experimental instead, since the requirements there are
less strict.

-- 
Tollef Fog Heen, for the CTTE
UNIX is user friendly, it's just picky about who its friends are--- End Message ---


Processed: Supporting configuration file changes between versions in unstable/testing

2017-03-09 Thread Debian Bug Tracking System
Processing control commands:

> block 856606 by -1
Bug #856606 [gitlab] gitlab: fails to upgrade from 'stretch': nginx example 
configuration file not found
856606 was not blocked by any bugs.
856606 was not blocking any bugs.
Added blocking bug(s) of 856606: 857257

-- 
856606: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856606
857257: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857257
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: Blends install options removed from tasksel menu

2017-01-16 Thread Debian Bug Tracking System
Processing control commands:

> block -1 by 846002
Bug #851555 [tasksel] Blends install options removed from tasksel menu
851555 was not blocked by any bugs.
851555 was not blocking any bugs.
Added blocking bug(s) of 851555: 846002

-- 
851555: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851555
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#850967: marked as done (Clarify /usr/bin/foo should not be hardcoded even in upstream parts)

2017-01-12 Thread Debian Bug Tracking System
Your message dated Thu, 12 Jan 2017 15:08:05 +0100
with message-id <5566268.jkbec7e...@odyx.org>
and subject line Re: Bug#850967: Clarify /usr/bin/foo should not be hardcoded 
even in upstream parts [and 1 more messages]
has caused the Debian Bug report #850967,
regarding Clarify /usr/bin/foo should not be hardcoded even in upstream parts
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
850967: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850967
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Control: block 850657 by -1

Policy 6.1 says
| Programs called from maintainer scripts should not normally have a
| path prepended to them.

Ie, programs that are on PATH should be found via the PATH rather than
by hardcoding /usr/bin/foo or whatever.  In general, I think we
normally, at least in software written specifically for Debian, apply
this not just to maintainer scripts but to all program execution.

However, this is not always uncontroversial with some upstreams.  This
causes a particular problem when the upstream is also heavily involved
with the Debian maintenance.


I would like the TC to:

 * Declare that Debian policy should be clarified to say that programs
   in Debian (not just maintainer scripts) should not hardcode the
   location of the binaries in /{usr/,}{bin,sbin} they execute.

 * Say that this applies even when the program needs to find pieces of
   the same (or closely related) package.

 * Say that where technically feasible, this should usually be done
   for other kinds of search paths (LD_LIBRARY_PATH, PYTHONPATH,
   PERLLIB, etc.), too.

 * Provide an informal opinion that this policy ought to apply to
   gpg-agent as requested in #850657.


I don't know if it is necessary to rehearse the arguments about this
issue for the TC, but I will try to do so briefly.


The argument in favour of finding programs (and libraries) on the
PATH:

This allows substitution and wrapping of programs (by adding a
directory to PATH containing a stunt version of the program, or by
adding a wrapper or replacement to /usr/local or ~/bin).  This can be
useful in a wide variety of situations.  It is a well-known debugging
technique.  It can be used by individual users, to modify the
behaviour of their system.  It can be profitably used by things like
test suites and audit tools.  It can be used by depending software to
work around bugs.

Most of these uses can be satisfied in some other way, but the other
ways have downsides.  For example, moving the actual binary aside is a
possibility (and supported by things like dpkg-divert); but it affects
the whole system, so requires administrator privilege; it is
unsuitable on a multiuser machine or for test suites; and if done
ad-hoc it is too easy to forget to put back and leave the system in a
weird state.

Explicit configuration or command line options to change which
subcommands are used are a good thing, but: they are usually fiddly
and certainly not always provided; this can often involve complicated
nesting (eg run `foo' with --bar-program pointing to a stunt `bar'
script which passes --wombat-program pointing to your stunt `wombat'
script); and lack of such an option at any level stymies this
approach.


I will quote the counterarguments from Daniel Kahn Gillmor, as they
are fairly typical of the responses from upstreams:

  In this bug report, you're asking a tightly-coupled suite of tools to
  invoke each other via the PATH, which offers another avenue of potential
  breakage; upstream regularly receives reports from people who *don't
  even know what version of gpg their system is running* because of
  multiple copies of the thing having been installed in various places on
  their system (either deliberately or incidentally, but in either case
  forgotten about by the local sysadmin).

  It's entirely reasonable for a tightly-coupled suite to want to invoke
  its own tools in this situation.  we have enough to debug in GnuPG as it
  is :/

Perhaps this is indeed a problem for some upstreams.  But I have two
responses to this which I think are each sufficient to rebut it:

Firstly, we are talking about this in the context of Debian.  In
Debian we have `reportbug', which the majority of people use to file
bug reports.

It would be simple for reportbug to report on these kind of anomalous
situations and mention them in the bug report.  It could, for example,
check to see if there is overlap between the package being reported
(and its dependencies), and /usr/local.  I don't know if it does
already, but if it d

Processed: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

2017-01-11 Thread Debian Bug Tracking System
Processing control commands:

> block 850657 by -1
Bug #850657 [gnupg] gnupg: Please find gpg-agent on PATH
850657 was not blocked by any bugs.
850657 was not blocking any bugs.
Added blocking bug(s) of 850657: 850967

-- 
850657: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850657
850967: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850967
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#841294: marked as done (Overrule maintainer of "global" to package a new upstream version)

2016-12-14 Thread Debian Bug Tracking System
Your message dated Wed, 14 Dec 2016 11:33:59 -0500
with message-id <tslr35aqxl4@suchdamage.org>
and subject line Re: Bug#841294: global maintainer : Draft ballot
has caused the Debian Bug report #841294,
regarding Overrule maintainer of "global" to package a new upstream version
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
841294: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841294
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

GNU Global is currently "freezed" in Debian at version 5.7.1 which is
8+ years old. Many improvements and bugs were fixed in more recent
versions. Also, many frontends now expect a newer versions of global
(new flags for the command-line tools) and therefore the version
currently in Debian is difficult to use.

Ron Lee is the current maintainer and disagrees on some issues with
upstream and therefore don't want to update to a more recent
version. See bug #574947:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947

The main issue seem to be around the CGI scripts. I believe that most
users don't care about those. Upstreams is OK to not have the scripts
packaged in Debian. There seems to be other issues but it is quite
unclear what they are. Bug #816924 is about the same thing but Ron
didn't participate at all:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816924

I suppose that Ron may not accept to update the package even if the
tech committee overrules him. In this case, Punit Agrawal accepts to
take over the maintainance of the package and already produced some
packages for newer versions. Those packages would remove the CGI
scripts.

Could the technical committee:

 1. Mediate this issue with Ron to get him to accept package a newer
upstream version.

 2. If unsucessful, overrule Ron on the decision to package a new
upstream version.

 3. If Ron doesn't want to package himself a new upstream version,
transfer the ownership of the package to Punit. I'll sponsor the
uploads and assist him in this task.

There are other possibilities like a different package
"global6". However, it is unsure if Ron would accept to collaborate on
this (notably with the alternative system):

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#166

"global6" could also conflict/replace global instead of using
alternatives. However, it is unclear if global6 can be considered as
replacing global. We don't know if Ron would agree to that. If he
doesn't, another possibility for the technical committee would be to
overrule him and allowing global6 to conflict/replace global.

Thanks.

- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (101, 
'experimental-debug'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQIvBAEBCAAZBQJYB2qfEhxiZXJuYXRAZGViaWFuLm9yZwAKCRCVpC/oNTUl+QPX
D/9qr7DxEERMZP5Pz1tKnf5KrW8Ko94edmvYXs5Iw7qamUUlX+M+4HSCW6K4toUr
/R2SPRMmUgl85t88BgEfxCKo+j01ZIgcdCvvq3k4ZMmejXqvn/gl9YEkq7FmqS53
cBQJTUGERwHBkIBU3+gikUc77ORW+qVBg8+5gMY3lwWhQe8o+zBmRW2519AHWLVa
Pcs+Xgk2ortnxFj+En4zz7fTooRoZDD1gvGhmmXEWaQ2wjbE2g4R6mMaDQ6JByBR
QnF/AdwfDODrMD1wpW2EhpYSMwmDVCsPYneSpbNl2CMnVsA/CiPIiqpHuAkKq4cZ
GgRhdGY+lCFzkXeI759gCY6gmMvsXLRyTBYSnUwHwRiSgHxyR9TlEaFPzG8k8wz7
b88XcKMrQek7uWVhlCoKm1bdaoiHFcGjwKc+cjTnGmKHVcpiXQuZI8mTv9B34nsJ
2LHcE9GxU3FOOkWmOLBtI4tkfJlmXxGdUzD/8a4kIZibpbIvC/qrCyaQQsp33/U1
UdXJOqsaB7ghGKlsHbw+ZGK8a9lqaxqtR3Tm+Wu/kB6/h+zZ9miRUfRrAygIMgJd
aRKkNZ8FCC6VnkBdn2WKGoxrRo2ZohCNkZ0Ls7ed9RenwXU1eJvzvTrrWUpwyL1K
wrSB5i0RRLkLQzUB/fmKbaPjU2OzuH4qsc1xLU9AqRfgcw==
=lWow
-END PGP SIGNATURE-
--- End Message ---
--- Begin Message ---


Per  Wookey's message, this issue can be closed.
I'd like to thank everyone who participated in the discussion and thank
everyone for their contribution to global.--- End Message ---


Processed: Re: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

2016-12-05 Thread Debian Bug Tracking System
Processing control commands:

> clone -1 -2
Bug #846002 [tech-ctte] blends-tasks must not be priority:important
Bug 846002 cloned as bug 847132
> reassign -2 src:blends
Bug #847132 [tech-ctte] blends-tasks must not be priority:important
Bug reassigned from package 'tech-ctte' to 'src:blends'.
Ignoring request to alter found versions of bug #847132 to the same values 
previously set
Ignoring request to alter fixed versions of bug #847132 to the same values 
previously set
> block -2 by -1
Bug #847132 [src:blends] blends-tasks must not be priority:important
847132 was not blocked by any bugs.
847132 was not blocking any bugs.
Added blocking bug(s) of 847132: 846002

-- 
846002: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846002
847132: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847132
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: Re: Bug#846002: Lowering severity

2016-12-05 Thread Debian Bug Tracking System
Processing control commands:

> reassign -1 src:blends
Bug #846002 [tech-ctte] blends-tasks must be priority:standard and not make a 
mess out of tasksel menu
Bug reassigned from package 'tech-ctte' to 'src:blends'.
Ignoring request to alter found versions of bug #846002 to the same values 
previously set
Ignoring request to alter fixed versions of bug #846002 to the same values 
previously set

-- 
846002: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846002
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: blends-dev must not be "priority: important" - was Re: Bug#846002: Lowering severity

2016-12-05 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> reassign 846002 tech-ctte
Bug #846002 [blends-tasks] blends-tasks must be priority:standard and not make 
a mess out of tasksel menu
Bug reassigned from package 'blends-tasks' to 'tech-ctte'.
No longer marked as found in versions blends/0.6.94.
Ignoring request to alter fixed versions of bug #846002 to the same values 
previously set
> thanks
Stopping processing here.

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



Bug#839560: marked as done (tech-ctte: failure to suspend sesion or lock computer)

2016-10-02 Thread Debian Bug Tracking System
Your message dated Sun, 2 Oct 2016 13:18:52 -0700
with message-id <20161002201852.62dmuzwfvumyu...@qor.donarmstrong.com>
and subject line Re: Bug#839560: tech-ctte: failure to suspend sesion or lock 
computer
has caused the Debian Bug report #839560,
regarding tech-ctte: failure to suspend sesion or lock computer
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
839560: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839560
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: serious
Tags: security
Justification: must

Dear Maintainer,

   * Q: What led up to the situation? A: attempt to lock, suspend or hibernate 
the sytemt to NOT shut down entirely.
   * Q: What exactly did you do (or not do) that was effective (or
 ineffective)? A: I attempted the three mentioned options.
   * Q: What was the outcome of this action? A: forced restart in all cases, 
resulting on fallback to journaled entries.
   * Q: What outcome did you expect instead? I expected those functions to... 
function.

-- System Information:
Debian Release: 8.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
On Sat, 01 Oct 2016, Timothy Danielson wrote:
> Dear Maintainer,
> 
>* Q: What led up to the situation? A: attempt to lock, suspend or 
> hibernate the sytemt to NOT shut down entirely.
>* Q: What exactly did you do (or not do) that was effective (or
>  ineffective)? A: I attempted the three mentioned options.
>* Q: What was the outcome of this action? A: forced restart in all cases, 
> resulting on fallback to journaled entries.
>* Q: What outcome did you expect instead? I expected those functions to... 
> function.

The Technical Committee isn't the group which is responsible for this
particular issue.

You should ask debian-u...@lists.debian.org for assistance in finding
the proper package to file your bug against. [Possible gnome, or
something else; unfortunately, you did not include enough detail in your
bug report for me to even guess.]


-- 
Don Armstrong  https://www.donarmstrong.com

"That is why I am still tyrant of [Ankh-Morpork]. The way to retain
power, I have always thought, is to ensure the absolute unthinkability
of oneself not being there."
 -- Terry Pratchett _Unseen Academicals_ p391--- End Message ---


Bug#835507: marked as done (Please clarify that sysvinit support decision is not going to expire)

2016-09-04 Thread Debian Bug Tracking System
Your message dated Mon, 05 Sep 2016 06:30:25 +0200
with message-id <87fupfge8u@fehawnok.err.no>
and subject line Re: Bug#835507: Please clarify that sysvinit support decision 
is not going to expire
has caused the Debian Bug report #835507,
regarding Please clarify that sysvinit support decision is not going to expire
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
835507: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835507
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte

There has recently been a thread on debian-devel ("Is missing
SysV-init support a bug?) about the decision by a package maintainer
to drop sysvinit support from their package.  The maintainer has said
they are reconsidering, which is good.

But, the discussion on -devel has shown that there are some other
maintainers who are considering similar steps, and that the project's
view on this is not settle.

So: would the TC please clarify that the decision that

For the record, the TC expects maintainers to continue to support
the multiple available init systems in Debian.  That includes
merging reasonable contributions, and not reverting existing
support without a compelling reason.

still stands, and that the answer to this queston

   However, that was two years ago. How long should we be expected to
   continue maintaining sysvinit scripts?

is "indefinitely, and specifically until a contrary decision by the
TC" (subject to quibbles over the exact meaning of "maintaining").

Or to put it another way:

  The answer to "is missing sysvinit support a bug" is "yes, and
  it will continue to be regarded as a bug until further notice".

  Of course a maintainer is not required to personally fix every bug,
  but a maintainer should not introduce bugs without good reasons, and
  should merge reasonable bugfix contributions.

Thanks,
Ian.
--- End Message ---
--- Begin Message ---
]] Ian Jackson 

Hi Ian,

> So: would the TC please clarify that the decision that
> 
> For the record, the TC expects maintainers to continue to support
> the multiple available init systems in Debian.  That includes
> merging reasonable contributions, and not reverting existing
> support without a compelling reason.
> 
> still stands, and that the answer to this queston
> 
>However, that was two years ago. How long should we be expected to
>continue maintaining sysvinit scripts?
> 
> is "indefinitely, and specifically until a contrary decision by the
> TC" (subject to quibbles over the exact meaning of "maintaining").

We discussed this in the last CTTE meeting on IRC and agreed to decline
to issue a statement, and I'm therefore closing this bug.  If you would
like us to have a formal vote about not issuing a statement, please let
us know and we can go through the motions for that.

We agree that there is a need for Policy to be updated to document the
current requirements and we'll get that work on getting that started.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are--- End Message ---


Bug#830344: marked as done (How should the TC help with a project roadmap?)

2016-08-25 Thread Debian Bug Tracking System
Your message dated Thu, 25 Aug 2016 19:42:35 +0200
with message-id <6851944.68Gl8PmQ9t@gyllingar>
and subject line Re: Bug#830344: Project Roadmap question - Call for votes
has caused the Debian Bug report #830344,
regarding How should the TC help with a project roadmap?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
830344: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830344
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: tech-ctte
User: tech-c...@packages.debian.org

Mehdi has proposed that the TC be involved in some fashion with a
"project roadmap". Some of the TC members met in person at debconf 16 to
talk about how that might work. I will attempt to (badly) summarize some
of the ideas brought out in that meeting with the goal of encouraging a
more complete discussion here.

I think we had general agreement on a couple of notions:

 1) Work in Debian is done by developers at their own discretion.
 2) We do not want to stop people working on anything

I think that Sam suggested that the TC could help encourage work on
goals which were well specified and already in progress

Keith suggested that the TC could help identify useful goals which were
less well specified and less active.

The end goal of this bug should be a response to the DPL's request.

-- 
-keith


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Le jeudi, 25 août 2016, 18.13:27 h CEST Tollef Fog Heen a écrit :
> ]] "Margarita Manterola"
> > 1) The TC volunteers to be the Roadmap team
> > 2) The TC volunteers to be part of the regular workflow of the
> >  Roadmap team, as an advisory body.
> > 3) The TC shouldn't be part of the regular workflow of the Roadmap team.
> > We will always be available for escalations, as usual.
> > 4) Further Discussion.
> 
> 3 > 2 = 4 > 1

With this vote (no matter any vote change from Sam), the outcome is no longer 
in doubt.

The winner is:
 Option 3 "The TC shouldn't be part of the regular workflow of the
 Roadmap team. We will always be available for escalations, as usual"

I'm therefore hereby closing this bug while CC'ing the leader for further 
steps.

-- 
Cheers,
OdyXStarting results calculation at Thu Aug 25 17:31:26 2016

/--1234
V: 3214 marga
V: 3312 fil
V: 3312 don
V: 2132 hartmans
V: 3214 odyx
V: 3212 tfheen
Option 1 "The TC volunteers to be the Roadmap team"
Option 2 "The TC volunteers to be part of the regular workflow of the Roadmap 
team, as an advisory body"
Option 3 "The TC shouldn't be part of the regular workflow of the Roadmap team. 
We will always be available for escalations, as usual"
Option 4 "Further Discussion"

In the following table, tally[row x][col y] represents the votes that
option x received over option y.

  Option
  1 2 3 4 
===   ===   ===   === 
Option 10 1 2 
Option 2  4   1 3 
Option 3  5 5   5 
Option 4  3 2 1   



Looking at row 2, column 1, 2
received 4 votes over 1

Looking at row 1, column 2, 1
received 0 votes over 2.

Option 1 Reached quorum: 2 >= 2
Option 2 Reached quorum: 3 >= 2
Option 3 Reached quorum: 5 >= 2


Dropping Option 1 because of Majority. (0.667)  0.667 (2/3) <= 1
Option 2 passes Majority.   1.500 (3/2) > 1
Option 3 passes Majority.   5.000 (5/1) > 1


  Option 3 defeats Option 2 by (   5 -1) =4 votes.
  Option 2 defeats Option 4 by (   3 -2) =1 votes.
  Option 3 defeats Option 4 by (   5 -1) =4 votes.


The Schwartz Set contains:
 Option 3 "The TC shouldn't be part of the regular workflow of the 
Roadmap team. We will always be available for escalations, as usual"



-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The winners are:
 Option 3 "The TC shouldn't be part of the regular workflow of the 
Roadmap team. We will always be available for escalations, as usual"

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


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


Bug#830978: marked as done (Browserified javascript and DFSG 2)

2016-07-28 Thread Debian Bug Tracking System
Your message dated Thu, 28 Jul 2016 15:37:54 -0400
with message-id <tsld1lxeep9@mit.edu>
and subject line Re: Bug#830978: Browserified javascript and DFSG 2
has caused the Debian Bug report #830978,
regarding Browserified javascript and DFSG 2
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
830978: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
package: tech-ctte

Background: Javascript on the server (with nodejs) uses modules to split
libraries, but using the same on browser requires combining these
modules to single file.

DFSG Section 2 [1] gives requirement for source code

"Source Code

The program must include source code, and must allow distribution in
source code as well as compiled form."

Browserified files are readable and editable javascript files. I believe
this meets DFSG 2 requirements. Someone who is familiar with javascript
can easily modify and run modified versions.

Some believe this is not enough and the tool required to browserify
should be in debian so we can integrate patches from upstream and also
send patches upstream (they expect patches against original split module
instead of the browserified file). [2][3][4].

The tool required for browserifying is grunt and it has long chain of
dependencies and has not been packaged yet.[5] Those who care about the
issue should help package grunt instead of using DFSG as a way of
blocking perfectly Free Software (with ability to use, modify, share and
distribute changes), albeit with some extra effort to port patches.

I agree with the concern, but not with the severity. I think the
severity should be 'important', instead of 'serious'.

I consider the situation as simliar to maintaining an older release or
forking (wodim for example) or a hostile upstream that does not want
their software packaged at all (like diaspora). In all those cases
upstream will not accept a patch against the version shipped in debian
and will need extra work to adapt the patches to latest vcs tree.

I don't think preferred format of upstream to accept patches should not
be a criteria to keep a package away from main.

I request CTTE to make a ruling on this issue.

Thanks
Praveen

[1] https://www.debian.org/social_contract
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817092
[3] https://lists.debian.org/debian-devel/2016/07/msg00238.html
[4] https://lists.debian.org/debian-devel/2016/07/msg00255.html
[5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673727




signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---


At today's meeting the technical committee decided to close this issue.

My understanding of our rationale is as follows:

The FTP team is responsible for determining if a package meets the
requirements of DFSG, including whether the source code meets the
conditions of DFSG #2:

2. Source Code
   The program must include source code, and must allow distribution
   in source code as well as compiled form.

The Release team is responsible for determining whether a particular bug
is release critical.  The Release team has decided that compliance with
the DFSG is release critical and has deferred the determination of DFSG
compliance to the FTP team [1]

[1] https://lists.debian.org/016cfb0b-076a-9f8f-3b4b-7d3190e5c...@debian.org

With regard to the particular issue of Browserified javascript,
particularly in the libjs-handlebars package, the best way forward is
for the submitter to discuss the question with the FTP team.  Such a
discussion would be less confusing if it took place after #830986 is
resolved.

In accordance with another discussion today, any member of the project
can reopen the bug and ask for a formal vote.
In this instance, I'd recommend reading the logs of the meeting before doing 
that.--- End Message ---


Processed: Re: ruby-uglifier: embedded code copy of uglifyJS (should depend on some package built from uglifyjs source)

2016-07-27 Thread Debian Bug Tracking System
Processing control commands:

> severity -1 serious
Bug #718367 [ruby-uglifier] ruby-uglifier: embedded code copy of uglifyJS 
(should depend on some package built from uglifyjs source)
Severity set to 'serious' from 'normal'
> block -1 by 830978
Bug #718367 [ruby-uglifier] ruby-uglifier: embedded code copy of uglifyJS 
(should depend on some package built from uglifyjs source)
718367 was blocked by: 757877
718367 was not blocking any bugs.
Added blocking bug(s) of 718367: 830978

-- 
718367: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718367
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: Block by tech-ctte bug

2016-07-13 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> block 817092 by 830978
Bug #817092 [src:libjs-handlebars] libjs-handlebars: source package contains 
files whose source is not in Debian
817092 was not blocked by any bugs.
817092 was not blocking any bugs.
Added blocking bug(s) of 817092: 830978
>
End of message, stopping processing here.

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



Processed: Re: Bug#822803: Call for votes for new TC member

2016-07-05 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 +pending
Bug #822803 [tech-ctte] New CTTE member(s)
Added tag(s) pending.

-- 
822803: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822803
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#828677: marked as done (tech-ctte: user/root password occasionally appear in clear text when rebooting from CLI)

2016-06-26 Thread Debian Bug Tracking System
Your message dated Sun, 26 Jun 2016 11:16:41 -0700
with message-id <20160626181641.ga3...@qor.donarmstrong.com>
and subject line Re: Bug#828677: tech-ctte: user/root password occasionally 
appear in clear text when rebooting from CLI
has caused the Debian Bug report #828677,
regarding tech-ctte: user/root password occasionally appear in clear text when 
rebooting from CLI
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
828677: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828677
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: important

Dear Maintainer,
   Before version 8 jessie, I frequently rebooted/shutdown from the
CLI... When I tried doing so since installing version 8 ( I
think I was up to 8.3?) I would get varying results: mostly the machine would
"Hang" for a minute or so & then power down; but occassionally it would reboot.
After the minute of hanging - a flashing little white line in the top Left Hand
Side of a black screen - I would get unformatted messages across the screen
followed occasionally by my password in clear text before the (tty?) login...On
one occasion, it was my root password! I experimented with several suggestions
from various forums: ; ; ...but got
confused. So I went to the Devuan site & downloaded it because in my gut, I
believed that the problems were caused by systemd? I think systemd "has its
finger in too many pies"! i.e.: it is involved in too many processes beyond the
initialisation of the computer. This seems to me to go against the general
grain of the basic Unix/Linux philosophy: (my paraphrase): Do ONE thing- Keep
it SIMPLE - do it RIGHT.



-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
--- End Message ---
--- Begin Message ---
Unless you're typing in the root password or have a custom script which
has the root password stored, there's no place that the root password is
stored in an unhashed form in a Debian system. [Furthermore, there's no
need to store it.]

-- 
Don Armstrong  https://www.donarmstrong.com

Identical parts aren't.
 -- Beach's Law--- End Message ---


Bug#771070: marked as done (Coordinate plan and requirements for cross toolchain packages in Debian)

2016-06-04 Thread Debian Bug Tracking System
Your message dated Sat, 04 Jun 2016 11:03:50 +0200
with message-id <87lh2ll409@whist.hands.com>
and subject line Re: Bug#766708: Coordinating a plan and requirements for cross 
toolchain packages in Debian
has caused the Debian Bug report #766708,
regarding Coordinate plan and requirements for cross toolchain packages in 
Debian
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
766708: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766708
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: tech-ctte

Recently some crippled cross toolchain packages were uploaded to
Debian unstable, without having any consent with the Debian GCC
maintainers, nor announcing these packages anywhere.  Maintained by a
single person, not even trying to form a maintainer group, and
downgrading bug reports without addressing concerns of the GCC
maintainers. I'm asking the ctte to state that

 - a cross compiler based on GCC within Debian is able to cross
   build the existing gcc-x.y packages without disabling any
   features that are offered by the packaging, and used for the
   native compilers. This includes frontends and multilib'ed
   runtime libraries.

 - a cross compiler based on GCC within Debian provides all the
   front ends required to cross-build GCC.

 - a cross compiler based on GCC within Debian uses the very
   same sources, patches and configuration, so that it is
   equivalent to the native compiler provided by the Debian
   GCC maintainers.

The current maintainer of the cross compiler packages has shown that
he is not able to work together on these issues in a group. I'm asking
the ctte that anybody who is able and willing to maintain the cross
compiler packages as outlined above, becomes the new maintainer of the
cross compiler packages targeting Debian architectures. It would be
good if the GCC maintainer group is involved in this group.
--- End Message ---
--- Begin Message ---
As agreed at the most recent meeting of the Technical Committee, this
bug is being closed.

It has not been resolved, as such, but parts of it have been rendered
moot by the release of Jessie, and other parts have been rendered less
relevant by the passage of time.

This is not a particularly satisfying outcome, but at least it clears
the way for bugs in related areas, which people might otherwise hesitate
to submit as long as this bug remains open.

Please be assured, the members of the Technical Committee are still very
much interested in assisting in whatever way we can with progress in
this area (either as individuals or as a group, in either informal
mediation or via bugs submitted to the committee).

We also intend to learn the lessons of this bug:

  Some issues clearly have an expiry date, and in such cases any
  decision is generally better than none.

  In order to make such quick decisions possible, we intend to
  encourage good behaviour by giving the most sympathetic hearing to
  those participants that provide clear justifications of their position
  and respond to questions in a timely manner.

Philip Hands
(on behalf of the Technical Committee)


signature.asc
Description: PGP signature
--- End Message ---


Bug#766708: marked as done (Coordinate plan and requirements for cross toolchain packages in Debian)

2016-06-04 Thread Debian Bug Tracking System
Your message dated Sat, 04 Jun 2016 11:03:50 +0200
with message-id <87lh2ll409@whist.hands.com>
and subject line Re: Bug#766708: Coordinating a plan and requirements for cross 
toolchain packages in Debian
has caused the Debian Bug report #766708,
regarding Coordinate plan and requirements for cross toolchain packages in 
Debian
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
766708: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766708
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: gcc-4.9
Version: 4.9.1-19
Severity: serious
Justification: do not migrate to jessie
User: helm...@debian.org
Usertags: rebootstrap

Hi Matthias,

I notice that starting with -19 gcc emits unsatisfiable dependencies in
multiarch cross builds regressing from -18. This makes all rebootstrap
builds fail to install gcc. You can find a failed attempt to install at
https://jenkins.debian.net/job/rebootstrap_m68k_gcc49/100/console.

It seems that gcc now emits dependencies on libc-*-$arch-cross, but
glibc doesn't build those.

I'll look into the matter and try to provide a patch.

Helmut
--- End Message ---
--- Begin Message ---
As agreed at the most recent meeting of the Technical Committee, this
bug is being closed.

It has not been resolved, as such, but parts of it have been rendered
moot by the release of Jessie, and other parts have been rendered less
relevant by the passage of time.

This is not a particularly satisfying outcome, but at least it clears
the way for bugs in related areas, which people might otherwise hesitate
to submit as long as this bug remains open.

Please be assured, the members of the Technical Committee are still very
much interested in assisting in whatever way we can with progress in
this area (either as individuals or as a group, in either informal
mediation or via bugs submitted to the committee).

We also intend to learn the lessons of this bug:

  Some issues clearly have an expiry date, and in such cases any
  decision is generally better than none.

  In order to make such quick decisions possible, we intend to
  encourage good behaviour by giving the most sympathetic hearing to
  those participants that provide clear justifications of their position
  and respond to questions in a timely manner.

Philip Hands
(on behalf of the Technical Committee)


signature.asc
Description: PGP signature
--- End Message ---


Bug#821361: marked as done (Voting for CTTE Chair)

2016-04-25 Thread Debian Bug Tracking System
Your message dated Mon, 25 Apr 2016 21:55:30 +0200
with message-id <1623654.qvfttb0...@odyx.org>
and subject line Re: Bug#821361: Voting for CTTE Chair
has caused the Debian Bug report #821361,
regarding Voting for CTTE Chair
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
821361: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821361
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal

With the appointment of Phil to the CTTE, according to our procedures,
we should elect the chair of the CTTE.[1]

Therefore, I am announcing my intention to step down from the CTTE
chairmanship effective Monday, April 25th at 03:00:00 UTC (or as soon as
the outcome of this election is no longer in doubt) to force an election
of the CTTE chair from our membership.

The ballot is the following:

===BEGIN===

The chair of the CTTE will be:

A: Don Armstrong
B: Andreas Barth
C: Phil Hands
D: Sam Hartman
E: Tollef Fog Heen
F: Keith Packard
G: Didier Raboud 
===END===


1: For those following along at home, this is not in the constitution,
but was discussed and agreed upon in #795857 and is documented in
procedures.md in our git repository.
-- 
Don Armstrong  https://www.donarmstrong.com

"Them as can do has to do for them as can't. And someone has to speak
up for them as have no voices."
 -- Grandma Aching in _The Wee Free Men_ by Terry Pratchett p227


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Dear TC members,

Le lundi, 25 avril 2016, 09.27:41 Don Armstrong a écrit :
> The voting period has ended; Didier Raboud (odyx) is the new CTTE
> chair! Thanks everyone for working with me during my term as
> chair.

Thank you very much Don for your service as chair, the bar has been set 
high.

I'm deeply honoured by this election, and am truly grateful for the 
trust you have placed in me for this position. I'll try my best and will 
welcome feedback of all sorts to help me fulfill all the duties of the 
position.

With my sincere regards,
OdyX

P.S. As for adminstrativia: hereby closing this bug & cc'ing the debian-
www team for the website update.

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


Bug#814095: marked as done (tech-ctte: Cannot shut down computer. Have to turn off computer using reset.)

2016-02-08 Thread Debian Bug Tracking System
Your message dated Mon, 8 Feb 2016 09:47:25 -0600
with message-id <20160208154725.GE8833@geta>
and subject line Re: Bug#814095: tech-ctte: Cannot shut down computer. Have to 
turn off computer using reset.
has caused the Debian Bug report #814095,
regarding tech-ctte: Cannot shut down computer. Have to turn off computer using 
reset.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
814095: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814095
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***



-- System Information:
Distributor ID: Sparky
Description:SparkyLinux
Release:4
Codename:   Tyche
Architecture: x86_64

Kernel: Linux 4.2.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
On Mon, 08 Feb 2016, Cannot logout of system wrote:
> -- System Information:
> Distributor ID:   Sparky
> Description:  SparkyLinux
> Release:  4
> Codename: Tyche
> Architecture: x86_64

You're using spark linux. Bugs can be reported here:
http://sourceforge.net/p/sparkylinux/tickets/


-- 
Don Armstrong  http://www.donarmstrong.com

Some pirates achieved immortality by great deeds of cruelty or
daring-do. Some achieved immortality by amassing great wealth. But
the captain had long ago decided that he would, on the whole, prefer
to achieve immortality by not dying.
 -- Terry Pratchet _The Color of Magic_--- End Message ---


Bug#795854: marked as done (Constitutional Amendment: Fix duplicate section numbering (A1))

2016-01-27 Thread Debian Bug Tracking System
Your message dated Wed, 27 Jan 2016 11:44:23 -0600
with message-id <20160127174423.GG8833@geta>
and subject line Resolved with the passing of 2015/vote_003.
has caused the Debian Bug report #795854,
regarding Constitutional Amendment: Fix duplicate section numbering (A1)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
795854: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795854
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal

Hi all,

here's my understanding of the state of our "Fix duplicate section 
numbering" discussion: There are two A.1 sections in the current 
constitution, the proposed solution is to renumber the first to A.0.

Ian wrote a full GR proposal in 
<20996.60469.968631.307...@chiark.greenend.org.uk> ( 
[636783_supermajority/propose-numberfix] in 
our git repository and I've attached it to this mail) which addresses 
this.

Cheers, 
OdyX

[636783_supermajority/propose-numberfix]
http://anonscm.debian.org/cgit/collab-maint/debian-ctte.git/tree/636783_supermajority/propose-numberfix

signature.asc
Description: This is a digitally signed message part.
--- End Message ---
--- Begin Message ---
With the passing of https://www.debian.org/vote/2015/vote_003, these
have been resolved.

-- 
Don Armstrong  http://www.donarmstrong.com

To punish me for my contempt of authority, Fate has made me an
authority myself
 -- Albert Einstein--- End Message ---


Bug#802159: marked as done (New OpenSSL upstream version)

2016-01-27 Thread Debian Bug Tracking System
Your message dated Wed, 27 Jan 2016 13:27:22 -0500
with message-id <tsl1t92ri7p@mit.edu>
and subject line Openssl Upstream in discussion with SRM
has caused the Debian Bug report #802159,
regarding New OpenSSL upstream version
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
802159: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802159
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte

Hi,

I've been waiting for the release team for a while to make a
decision on #765639 for a year now.  Could you help in getting a
decision?

I've actually been waiting for longer than that, I can't directly
find all links, but previous discussions about it are at least:
https://lists.debian.org/debian-devel/2013/09/msg00466.html
https://lists.debian.org/debian-project/2013/12/msg00140.html


Kurt
--- End Message ---
--- Begin Message ---
Hi.

It's the TC's understanding that the SRMs and Kurt are currently in a
productive discussion of this request and that neither party is
currently asking the TC for any action.
We're closing this as not currently affecting the TC.
If either side wants our help or wants us to make a decision, feel free
to reopen this.
Also, if our understanding is wrong and we're supposed to be doing
something here, please reopen and explain what you're hoping for.

Thanks,

--Sam--- End Message ---


Bug#795855: marked as done (Introduction of a formal cloture vote procedure for the TC)

2016-01-13 Thread Debian Bug Tracking System
Your message dated Wed, 13 Jan 2016 15:32:15 -0500
with message-id <tsltwmh8blc@mit.edu>
and subject line Multiple Ballots
has caused the Debian Bug report #795855,
regarding Introduction of a formal cloture vote procedure for the TC
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
795855: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795855
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal

Hi all,

here's my understanding of the state of our "Introduction of a formal 
cloture vote procedure for the TC" discussion.

In June 2014, in answer to a proposal from Ian to introduce a minimum 
discussion period in the TC, Steve, referring to a previous TC IRC 
discussoin, proposed in <20140628005011.ga8...@virgil.dodds.net> to 
introduce a formal cloture vote procedure for the TC, with the following 
"strawman"

Le vendredi, 27 juin 2014, 17.50:11 Steve Langasek a écrit :
>  - Any member of the TC may call for a cloture vote on a proposed
>ballot at any time.
>  - Quorum for a cloture vote is 1/2 + 1 members.
>  - A cloture vote must receive 2/3 majority in favor in order to pass.
>  - Voting period for cloture is 48 hours, or until the outcome is no
>longer in doubt.
>  - Ballot options proposed during the cloture vote shall be included
>on the ballot.
>  - If a cloture vote fails, any TC member who voted in favor of
>cloture may not repeat the call for a period of one week following
>the first call. Other members of the TC may call for cloture during
>this time.
>  - If a cloture vote fails, any ballot options that are subsequently
>proposed and not withdrawn shall be included on the ballot for the 
>issue.
>  - If, two weeks after the original call for cloture, there have been
>no further ballot options proposed, voting proceeds on the original
>ballot.
> 
> Features:
> 
>  - If there is procedural consensus, we can act as quickly as we need
>to.
>  - If someone tries to CFV too early, whether because of an error
>in judgement or because they're trying to cut off debate, a
>"cooldown" period applies, ensuring that a failed cloture vote
>actually leaves room for further discussion
>  - However, as soon as any one person who has voted against cloture is
>satisfied with a revised ballot, they can call for cloture again
>and the vote can move forward
>  - A CFV can largely not be used to prevent a minority viewpoint being
>represented on the ballot, since additional ballot options can be
>submitted during the cloture vote and are guaranteed to be
>included.
>  - Voting down cloture cannot be used to prevent a question from
>coming to a vote; anyone opposed to cloture must still put in the
>effort to come up with alternative ballot options or the vote will
>still happen.
> 
> Misfeatures:
> 
>  - A member of the TC can ensure "irrelevant" ballot options are
>included on the ballot, possibly spoiling the vote.  I don't think
>this is a real issue.  But then, I also fundamentally disagree with
>Bdale's characterization of the init system ballot proposals as
>"conflation"; so I consider this the lesser evil compared with the
>status quo, and think it should not be possible for any member of
>the TC to ever do again what Bdale did in that case.

This proposal was answered by Anthony in  with the following alternative 
strawman:

Le dimanche, 29 juin 2014, 20.35:56 Anthony Towns a écrit :
>  - Any member of the TC may call for votes on a ballot at any time.
>  - When calling for votes, the TC member may propose any combination
>of resolutions they believe is appropriate to be considered on the
>ballot, provided they fall under the ctte's constitutional powers.
>  - When voting on the ballot, TC members may rank the proposed options
>from 1 to n in the normal manner for Debian ballots.
>  - An additional "Cloture" option will be automatically added to the
>ballot.
>  - The Cloture option may only be marked "Y" to approve cloture, or
>"N" to deny cloture.
>  - The Cloture option is the default option for the SRP. A "Y" vote
>for cloture is treated as ranking the default option below all
>others (including unranked options). A "N" vo

Processed: tagging 741573

2015-11-27 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> tags 741573 - pending
Bug #741573 {Done: Don Armstrong <d...@debian.org>} [tech-ctte] On menu systems.
Removed tag(s) pending.
> thanks
Stopping processing here.

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



Processed: your mail

2015-11-24 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> clone 741573 -1
Bug #741573 {Done: Don Armstrong <d...@debian.org>} [tech-ctte] On menu systems.
Bug 741573 cloned as bug 806161
> reassign -1 debian-policy
Bug #806161 {Done: Don Armstrong <d...@debian.org>} [tech-ctte] On menu systems.
Bug reassigned from package 'tech-ctte' to 'debian-policy'.
Ignoring request to alter found versions of bug #806161 to the same values 
previously set
Ignoring request to alter fixed versions of bug #806161 to the same values 
previously set
> retitle -1 Deprecating menu files and transition to desktop files
Bug #806161 {Done: Don Armstrong <d...@debian.org>} [debian-policy] On menu 
systems.
Changed Bug title to 'Deprecating menu files and transition to desktop files' 
from 'On menu systems.'
> thanks
Stopping processing here.

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



Bug#795857: marked as done (Constitutional Amendment: TC chair appointment)

2015-11-23 Thread Debian Bug Tracking System
Your message dated Mon, 23 Nov 2015 17:38:01 -0800
with message-id <20151124013801.gt4...@qor.donarmstring.com>
and subject line Chair election procedure in git
has caused the Debian Bug report #795857,
regarding Constitutional Amendment: TC chair appointment
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
795857: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795857
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal

Hi all,

here's my understanding of the state of our "TC chair appointment" 
discussion.

In June 2014, in <21420.15439.20061.525...@chiark.greenend.org.uk>, Ian 
described a problem he wanted to see fixed in the constitution:

Le jeudi, 26 juin 2014, 16.29:19 Ian Jackson a écrit :
> The TC chair arrangements have what is arguably a bug, which is that
> the TC cannot change a sitting chair other than by the chair resigning
> or leaving the committee.
> 
> I think the TC chair should be reappointed regularly (annually?), and
> that a new chair election should be held when the TC composition
> changes.
> 
> If we are having a formal TC member retirement scheme, and TC chair
> election when a new member is appointed, then perhaps making explicit
> provision for time-based chair retirement is unnecessary.

As far as I could find, this mail didn't get answered, either way, let's 
use this bug to consider this proposal.

Cheers, 
OdyX

signature.asc
Description: This is a digitally signed message part.
--- End Message ---
--- Begin Message ---
We have committed the following to git:

Appointment of the Chair of the CTTE


In general, the procedure in §6.1.7 should be followed.

Re-appointment of chair after membership change
===

When new members are appointed to the CTTE or within three months of a
member resigning from the CTTE, the current chairperson should
announce their intention to vacate the position within two weeks.

This will force a new election to which all members of the CTTE
(including the vacating chair if the chair is still a member) are
eligible.


-- 
Don Armstrong  http://www.donarmstrong.com--- End Message ---


Processed: your mail

2015-11-18 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> reassign 805482 linux
Bug #805482 [tech-ctte] CPU: 0 PID: 0 at 
/usr/src/packages/BUILD/linux-3.18.5/net/core/skbuff.c:3995
Bug reassigned from package 'tech-ctte' to 'linux'.
Ignoring request to alter found versions of bug #805482 to the same values 
previously set
Ignoring request to alter fixed versions of bug #805482 to the same values 
previously set
> thanks
Stopping processing here.

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



Bug#741573: marked as done (On menu systems.)

2015-10-13 Thread Debian Bug Tracking System
Your message dated Thu, 03 Sep 2015 20:34:14 -0700
with message-id <20150904033414.gd3...@qor.donarmstring.com>
and subject line [CTTE #741573] Debian Menu System
has caused the Debian Bug report #741573,
regarding On menu systems.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
741573: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal

Dear technical comittee,

I am asking for your arbitration on an unresolvable conflict on the subject of
Desktop menu systems, between a broad number of developers including on one
hand maintainers of the Debian packages for the GNOME and KDE desktop systems
and the mime-support package (myself), and on the other hand Bill Alombert on
his quality of Policy Editor (DPL delegate).

Over almost one year of work and discussion, including a call for comments on
the debian-devel mailing list, we have shaped a modification to the Debian
Policy that 1) incorporates the description of the FreeDesktop menu system and
its use in Debian for listing program in desktop menus and associating them
with media types, and 2) softens the wording on the Debian Menu system to
reflect that in Jessie it will be neither displayed nor installed by default on
standard Debian installations.

The proposal reached consensus through the Policy Changes process, was seconded
by me, Lisandro Damián Nicanor Pérez Meyer, Cyril Brulebois and Russ Allbery,
who is also Policy Editor and assessed that the consensus was obtained.
Apparently without coordination with the other Policy Editors, Bill then
canceled the change and has been avoiding any concrete discussion the change.

You can find the proposal at the following URL.


http://anonscm.debian.org/gitweb/?p=dbnpolicy/policy.git;a=commitdiff;h=ba679bff76f5b9152f43d5bc901b9b3aad257479;hp=f6997b3ba793c9a9e463cca9f7e7b138add8b788

The whole discussion is at https://bugs.debian.org/707851.

I will not describe Bill's behaviour in further details unless you ask me to do
so, but the end result is that me and others are stongly dissatisfied by his
obstructive attitude and unilateral veto, to the point that we do not think
that discussion is possible and we need a decision from a third party.  I am
asking you to overrule Bill and let me or the Policy Editors upload an updated
version of the Policy containing our changes.

I will inform Bill and the debian-policy mailing list in the thread for #707851
once I have a bug number for this appeal.

Please let me know if there is further information you need.

Cheers, and many thanks for your work.

-- 
Charles Plessy
Maintainer of the 'mime-support' package
Tsurumi, Kanagawa, Japan
--- End Message ---
--- Begin Message ---
The technical committee was asked in #741573 to decide an issue of
Debian technical policy regarding menu regarding the menu system.

 RESOLUTION 

Whereas:

   1. The Debian Policy Manual states (§9.6) that 'The Debian menu
  package provides a standard interface between packages providing
  applications and "menu programs"'. It further states that 'All
  packages that provide applications that need not be passed any
  special command line arguments for normal operations should
  register a menu entry for those applications'.

   2. All details about menu system requirement are delegated to the
  Debian Menu sub-policy and Debian Menu System manuals (the
  "Debian menu system").

   3. An external specification, the Freedesktop Desktop Entry
  Specification (the ".desktop spec"), with native support in many
  X desktop environments, has appeared since the Debian Menu
  system was developed. The .desktop spec offers a fairly strict
  super-set of Debian Menu system functionality.

   4. The .desktop specification has significant technical benefits
  for users over the Debian menu system. The .desktop
  specification works together with the freedesktop.org mime type
  and icon specifications to provide operations expected by
  desktop users from other environments, such as Mac OS X or
  Windows. As such, applications must provide a .desktop file to
  operate well in most desktop environments.

   5. The Debian Technical Committee has been asked to resolve a
  dispute between maintainers of Debian Policy over a change that

  i. incorporates the description of the FreeDesktop menu system
 and its use in Debian for listing program in desktop menus
 and associ

Processed: tagging 636783, tagging 795854

2015-08-31 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> tags 636783 + pending
Bug #636783 [tech-ctte] proposed constitution fix for super-majority within the 
tech ctte
Added tag(s) pending.
> # GR in process
> tags 795854 + pending
Bug #795854 [tech-ctte] Constitutional Amendment: Fix duplicate section 
numbering (A1)
Added tag(s) pending.
> thanks
Stopping processing here.

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



Bug#686235: marked as done (Committee list of decisions on webpage is incomplete)

2015-08-18 Thread Debian Bug Tracking System
Your message dated Tue, 18 Aug 2015 20:16:44 +0200
with message-id 20150818181644.gc2...@mails.so.argh.org
and subject line Webpage extended
has caused the Debian Bug report #686235,
regarding Committee list of decisions on webpage is incomplete
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
686235: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686235
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: tech-ctte

Stefano Zacchiroli writes (Re: tech-ctte webpage cleanup):
 On Wed, Aug 29, 2012 at 03:31:09PM +0100, Ian Jackson wrote:
  While I was there I noticed some infelicities, so I have:
 
 Thanks Ian. Prodded by this, I've documented the current team formation
 in /intro/organization, which was out of date after recent changes. The
 change will be live at the next website update pulse.

Thanks.  (Do you know how often that happens?)

 It seems to me that the history section of appointments in the tech-ctte
 page is out of date: Manoj should be thanked there, AFAICT. Also, Colin
 is not mentioned in the Formal nontechnical and procedural decisions
 section. All in all, I'm not sure if it's worth the effort of keeping up
 to date that part...

I think we should do so.  Someone (I volunteer) should go through the
list archives and look for anything else we're missing.  grepping for
vote might do it.

It's a relatively small amount of work to do this when we make a final
decision, compared to the effort of discussing, voting, etc.  If it
gets too tedious we can probably automate it a bit more.

Ian.
---End Message---
---BeginMessage---
Hi,

I added more decisions to the web page, so that it should now be
complete. For this reasons I close this bug report now, if anything
else is missing please inform me.


Andi---End Message---


Bug#750135: marked as done (Determine maintainer of aptitude package)

2015-08-17 Thread Debian Bug Tracking System
Your message dated Fri, 19 Jun 2015 07:28 -0700
with message-id 20150619142800.ga8...@qor.donarmstring.com
and subject line [CTTE #750135] Aptitude Project Maintainer
has caused the Debian Bug report #750135,
regarding Determine maintainer of aptitude package
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
750135: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750135
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: tech-ctte
Severity: normal
Control: submitter -1 Manuel A. Fernandez Montecelo 
manuel.montez...@gmail.com
Control: retitle -1 Determine maintainer of aptitude package

- Forwarded message from Manuel A. Fernandez Montecelo 
manuel.montez...@gmail.com -

Date: Sun, 1 Jun 2014 16:17:58 +0100
From: Manuel A. Fernandez Montecelo manuel.montez...@gmail.com
To: aptitude-de...@lists.alioth.debian.org
Cc: debian-ctte@lists.debian.org
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Request to ctte about administration of aptitude project -- was Re: 
[Aptitude-devel] Processed: Unmark changes that
are no longer pending

Hi,

Just for reference, the fixes marked as pending in the bugs in the email
below that you are unmarking, are not commited to the repository because
you removed access permissions from me months ago and did not restore
them yet after several requests, not because I don't have them applied
locally and plan to upload them in next uploads of the package.

I am still waiting for you to grant me permissions to commit again.

BTW, Daniel, you did not push anything to the repository in more than 2
months now (last commits: 2014-03-22), and also didn't push anything
significant in the 3 months since you kicked me out of the aptitude
project in Alioth.  Even if you have made any improvements in private,
they should not be kept private, as requested since long ago and not
only by me.

So you keep acting in an unproductive way for the project and Debian in
general, and since you don't want to agree to anything and only follow
your own will, I am going to attempt something a bit more radical.  I
didn't want to do because it is bad for everybody initially (hopefully
better for the long term survival of aptitude), but you didn't leave me
any other alternative other than me staying silent, which also is bad
for everybody but for you.


@ctte, tl;dr:

Can you please tell me what's the best way (if asking a formal
resolution from the ctte, or what other ways do I have available) to
request that I am restored my admin status on aptitude project in
Alioth, and Daniel gets the admin permissions removed?

Daniel Hartwig asked Alioth admins to grant him admin permissions in the
project just to remove me immediately (in early March), after more than
one year (since late 2012) of him keeping the development of aptitude in
a stand-still, which I picked it up again in January this year.

The reason was because he did not like the changes that I was doing to
aptitude (mostly fixes to existing bug reports, no radical new
developments), and without agreement from anybody but him he kicked me
out of the project (even plain member status) 3 months ago, so I cannot
commit to the repository.

After several requests, 3 months after that, nothing much has changed.

--

Background: Daniel Burrows, the creator of aptitude and maintainer for a
decade or more, stopped being active in mid 2011, and soon after that
(Nov 2011 or so) both Hartwig and I took over, because Christian Perrier
and other people gave us member permissions immediately and without any
restriction to do as we pleased -- when we did not even know if Daniel
Burrows would eventually return.

Soon after that, in Feb 2012 or so, because of similar clashes (Hartwig
complaining about every other change that I made for one reason or
another, with multiple private messages and very silly details
sometimes) I retired to the background, thinking that it would be better
overall for the project.  (I would be very happy if projects that I
consider important/critical ran fine, and I didn't feel the need to be
involved -- and I would be also be very happy if somebody else was
taking good care of aptitude right now, I would stop again being
involved).

When we took over, the pace of development was good for a while, Nov
2011 to Feb 2012 when we both were active, and then after I retired to
the backstage relatively steady until Nov 2012 (although not very much
after June 2012) when Daniel Hartwig keeped the development active.

But, since Daniel Burrows left, the development of aptitude was only
really active during one year or so

Bug#784399: marked as done (tech-ctte: on bootup: MUX_INFO call failed)

2015-05-06 Thread Debian Bug Tracking System
Your message dated Wed, 06 May 2015 08:47:25 +0200
with message-id 1528071.gshsNHLRZ0@gyllingar
and subject line Re: Bug#784399: tech-ctte: on bootup: MUX_INFO call failed
has caused the Debian Bug report #784399,
regarding tech-ctte: on bootup: MUX_INFO call failed
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
784399: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784399
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: tech-ctte
Severity: normal

Dear Maintainer,
This is a new install. When the machine is booting, it comes to the line
 (populating /dev) then displays [DRM intel ~~~ MUX_INFO call failed.
It hangs there for maybe 15 seconds, then continues. Nothing seems to be
affected when using the system, but I haven't used it very long.
I installed (i965-va-driver-1.0.17-1) but nothing changed.  

-- System Information:
Debian Release: 7.8
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
---End Message---
---BeginMessage---
Le mardi, 5 mai 2015, 22.19:27 jerry a écrit :
 Package: tech-ctte
 This is a new install. When the machine is booting, it comes to the
 line (populating /dev) then displays [DRM intel ~~~ MUX_INFO call
 failed. It hangs there for maybe 15 seconds, then continues. Nothing
 seems to be affected when using the system, but I haven't used it
 very long. I installed (i965-va-driver-1.0.17-1) but nothing changed.

The technical committee is not the right place for this bug report, see 
[0]. You should probably first ask for help through any of Debian's 
support channels.

I'm hereby closing this bug.

Cheers,
OdyX

[0] https://www.debian.org/devel/tech-ctte

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


Bug#769972: marked as done (New CTTE members)

2015-03-18 Thread Debian Bug Tracking System
Your message dated Wed, 18 Mar 2015 17:18:42 -0700
with message-id 20150319001842.gr31...@teltox.donarmstrong.com
and subject line New members appointed.
has caused the Debian Bug report #769972,
regarding New CTTE members
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
769972: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769972
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: tech-ctte
Severity: minor
User: tech-c...@packages.debian.org
Usertag: consensus-seeking

On Mon, 17 Nov 2014, Bdale Garbee wrote:
 I see that Don has added an agenda item about this to our next IRC
 meeting scheduled for 4 December, but I don't really want to wait until
 then to start the process.

I'm OK with sending out the call for nominations cribbing from #685795,
and putting a start date of the 1st of December to start considering
nominations.

Does anyone object in principle with this?

Are we OK with sending out this call in 24 hours if there are no
objections?

-- 
Don Armstrong  http://www.donarmstrong.com

I learned really early the difference between knowing the name of
something and knowing something
 -- Richard Feynman What is Science Phys. Teach. 7(6) 1969
---End Message---
---BeginMessage---
New members have been appointed; closing this bug.

-- 
Don Armstrong  http://www.donarmstrong.com

Who is thinking this?
I am.
 -- Greg Egan _Diaspora_ p38---End Message---


Bug#765803: marked as done (tech-ctte: Ask before changing init system when upgrading to jessie and Inform about init systems when installing jessie)

2015-03-18 Thread Debian Bug Tracking System
Your message dated Wed, 18 Mar 2015 17:19:51 -0700
with message-id 20150319001951.gs31...@teltox.donarmstrong.com
and subject line The statement closed this issue
has caused the Debian Bug report #762194,
regarding tech-ctte: Ask before changing init system when upgrading to jessie 
and Inform about init systems when installing jessie
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
762194: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762194
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: tech-ctte
Severity: Important

When upgrading an old system installing certain packages, like
network-manager and gdm3 systemd-sysv is installed changing the init
system. These packages depend on libpam-systemd, which depends on
systemd-sysv | systemd-shim. If systemd-shim is not installed
systemd-sysv will be, and the init system changes the default to
systemd-sysv, and changing PID 1.

Changing init system, i.e. PID1, should be warned about loudly by
debconf. Not all users want to change init system when doing and
upgrade, of course this should not happen (sometimes unnoticed by
upgrading a lot of packages).

For new installations the situation is different, systemd is the
default init system. Nevertheless, perhaps even for new installations
the user should be given a choice. At least on how to reinstall
sysvinit-core after installing the default init system: systemd-sysv in
the Debian Installer (DI) (if not solvable by other means in the DI). 

The bug on (and the discussion there) on systemd-sysv:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747535
has ping-ponged in severity and the systemd maintainers always downgrade
the severity to wishlist and tagged it wontfix. The only way to resolve
this issue is that the CTTE makes a decision on this matter.

Other bugs related to this issue are: 760601 764186 746578

In summary, the CTTE is asked to make a decision on debconf warnings on:
1) Changing init system on upgrades (including sid)
2) Inform about alternate init systems for new installations

Thank you for your attention!
---End Message---
---BeginMessage---
This issue has been closed by the CTTE statement made a few weeks ago.

-- 
Don Armstrong  http://www.donarmstrong.com

Whatever you do will be insignificant, but it is very important that
you do it.
 -- Mohandas Karamchand Gandhi---End Message---


Bug#762194: marked as done (Automatic switch to systemd on wheezy-jessie upgrades)

2015-03-18 Thread Debian Bug Tracking System
Your message dated Wed, 18 Mar 2015 17:19:51 -0700
with message-id 20150319001951.gs31...@teltox.donarmstrong.com
and subject line The statement closed this issue
has caused the Debian Bug report #762194,
regarding Automatic switch to systemd on wheezy-jessie upgrades
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
762194: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762194
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: tech-ctte

At the risk of generating confusion due to a duplication of threads:

It appears that the answer to #746578 (libpam-systemd dependency) does
not depend on whether users upgrading should be switched to systemd by
default.  The current state in jessie is that users are switched by
default.  This is controversial.  The Technical Committee should make
a decision about this.

My view is that users should not be automatically switched when
upgrading to jessie.  As I said in my intro to #746578:

This is especially important given the controversy, and our commitment
to support multiple init systems.

This would also be analogous with other similar decisions.  For
example, if the default desktop for jessie remains XFCE, we do not
expect users upgrading from wheezy to have GNOME replaced with XFCE.
If we were to change the default MTA or nameserver or syslogd, we
would not expect to replace the installed MTA or nameserver or syslogd
on existing systems.

There are also of course important practical problems with
automatically switching.  There have been suggestions that these
should be dealt with by automatically detecting problem cases.  But we
do not yet have a coherent design for such an approach, let alone an
implementation.  It is IMO too late in the jessie release cycle for us
to be developing and introducing such a thing.  This is particularly
true given that the details are likely to be contested.

I think that the TC's correct approach is probably to make a bare
statement that:

Users upgrading to jessie should, by default, not be automatically
switched from sysvinit to systemd.

A straightforward mechanism for making the switch should be
provided and documented.

The alternative would be:

Users upgrading to jessie should, by default, be automatically
switched from sysvinit to systemd, where feasible.

A straightforward mechanism for avoiding the switch should be
provided and documented.

The detailed implications of what this means for dependencies should
be dealt with separately if the implementation runs into trouble or
conflict.

Ian.
---End Message---
---BeginMessage---
This issue has been closed by the CTTE statement made a few weeks ago.

-- 
Don Armstrong  http://www.donarmstrong.com

Whatever you do will be insignificant, but it is very important that
you do it.
 -- Mohandas Karamchand Gandhi---End Message---


Bug#741573: marked as done (On menu systems.)

2014-12-16 Thread Debian Bug Tracking System
Your message dated Tue, 16 Dec 2014 16:13:47 +0100
with message-id 4140568.tjN7gh2ivf@gyllingar
and subject line Re: Bug#741573: tech-ctte: Window will not open.
has caused the Debian Bug report #741573,
regarding On menu systems.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
741573: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: tech-ctte
Severity: normal

Dear technical comittee,

I am asking for your arbitration on an unresolvable conflict on the subject of
Desktop menu systems, between a broad number of developers including on one
hand maintainers of the Debian packages for the GNOME and KDE desktop systems
and the mime-support package (myself), and on the other hand Bill Alombert on
his quality of Policy Editor (DPL delegate).

Over almost one year of work and discussion, including a call for comments on
the debian-devel mailing list, we have shaped a modification to the Debian
Policy that 1) incorporates the description of the FreeDesktop menu system and
its use in Debian for listing program in desktop menus and associating them
with media types, and 2) softens the wording on the Debian Menu system to
reflect that in Jessie it will be neither displayed nor installed by default on
standard Debian installations.

The proposal reached consensus through the Policy Changes process, was seconded
by me, Lisandro Damián Nicanor Pérez Meyer, Cyril Brulebois and Russ Allbery,
who is also Policy Editor and assessed that the consensus was obtained.
Apparently without coordination with the other Policy Editors, Bill then
canceled the change and has been avoiding any concrete discussion the change.

You can find the proposal at the following URL.


http://anonscm.debian.org/gitweb/?p=dbnpolicy/policy.git;a=commitdiff;h=ba679bff76f5b9152f43d5bc901b9b3aad257479;hp=f6997b3ba793c9a9e463cca9f7e7b138add8b788

The whole discussion is at https://bugs.debian.org/707851.

I will not describe Bill's behaviour in further details unless you ask me to do
so, but the end result is that me and others are stongly dissatisfied by his
obstructive attitude and unilateral veto, to the point that we do not think
that discussion is possible and we need a decision from a third party.  I am
asking you to overrule Bill and let me or the Policy Editors upload an updated
version of the Policy containing our changes.

I will inform Bill and the debian-policy mailing list in the thread for #707851
once I have a bug number for this appeal.

Please let me know if there is further information you need.

Cheers, and many thanks for your work.

-- 
Charles Plessy
Maintainer of the 'mime-support' package
Tsurumi, Kanagawa, Japan
---End Message---
---BeginMessage---
Le mardi, 16 décembre 2014, 09.58:02 Harry-Werner a écrit :
 When the first bar button on the top right corner of a window
 is clicked the window will not size or open after being reduced to a
 bar.

tech-ctte is not the correct target for such a bug, I'm hereby closing 
this bug.

Please ask on debian-u...@lists.debian.org to find help and a potential 
target package for a bug.

Cheers,
OdyX---End Message---


Processed: Re: Bug#741573: tech-ctte: Window will not open.

2014-12-16 Thread Debian Bug Tracking System
Processing control commands:

 reopen -1
Bug #741573 {Done: Didier 'OdyX' Raboud o...@debian.org} [tech-ctte] On menu 
systems.
Bug reopened
Ignoring request to alter fixed versions of bug #741573 to the same values 
previously set

-- 
741573: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573
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: 
https://lists.debian.org/handler.s.b741573.141874316921523.transcr...@bugs.debian.org



Processed: Coordinating a plan and requirements for cross toolchain packages in Debian

2014-12-16 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 forcemerge 771070 766708
Bug #771070 [tech-ctte] requirements for cross toolchain packages in the 
distribution
Bug #766708 [tech-ctte] Revert gcc cross-building changes
Severity set to 'normal' from 'wishlist'
766924 was blocked by: 766708
766924 was not blocking any bugs.
Removed blocking bug(s) of 766924: 766708
Bug #771070 [tech-ctte] requirements for cross toolchain packages in the 
distribution
Added tag(s) patch.
Merged 766708 771070
 retitle 771070 Coordinate plan and requirements for cross toolchain packages 
 in Debian
Bug #771070 [tech-ctte] requirements for cross toolchain packages in the 
distribution
Bug #766708 [tech-ctte] Revert gcc cross-building changes
Changed Bug title to 'Coordinate plan and requirements for cross toolchain 
packages in Debian' from 'requirements for cross toolchain packages in the 
distribution'
Changed Bug title to 'Coordinate plan and requirements for cross toolchain 
packages in Debian' from 'Revert gcc cross-building changes'
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
766708: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766708
766924: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766924
771070: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771070
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: 
https://lists.debian.org/handler.s.c.1418775067898.transcr...@bugs.debian.org



  1   2   3   >