Le Wed, Jul 31, 2002 at 01:49:20PM +0200, Wichert Akkerman écrivait:
With testing you could use unstable as your staging area in which case
this would degenerate into solution one. Considering unstable is just
that (ie unstable) and I suspect GNOME2 problems will be resolved by
the time sarge
Le Wed, Jul 31, 2002 at 10:40:17PM +1000, Anthony Towns écrivait:
And, more particularly, there aren't any configuration upgrade scripts yet.
And there's no evidence that we'll have something provided by the
upstream developers one day.
Christian mentioned a couple of times in the thread that
Le Thu, Aug 01, 2002 at 11:29:32AM -0400, Raul Miller écrivait:
If there's any other aspect to this problem, I've overlooked it.
Your analysis is quite good.
It's tempting (though probably premature) to treat this whole situation
by filing bugs against the gnome1 packages which don't have
Le Thu, Aug 01, 2002 at 03:59:36PM -0400, Raul Miller écrivait:
This seems to me to mean that the best action, on the part of the
committee, would be to do nothing.
Certainly not. Let me explain why :
At the moment, the best seems to be let the package maintainer continue
working on the
Le Fri, Aug 02, 2002 at 03:20:49AM -0700, Chris Waters écrivait:
Even though upstream have released Gnome 2.0 to the wide public, some
uystream people still think that Gnome 2 is not yet ready to be imposed to
our unstable users.
Gnome2 is ready for users. Everyone agrees that Gnome2
Le Sun, Aug 04, 2002 at 11:51:13PM -0400, Steve M. Robbins écrivait:
There's one aspect of this debate given little attention in
submissions to the bug report: It is entirely possible that both
Gnome 1 and Gnome 2 are desirable in the next Debian release.
You're the first one who is saying
Le Sun, Aug 04, 2002 at 10:58:58PM -0600, Jason Gunthorpe écrivait:
Er, how many packages are we talking about here?
We have in the past kept multiple versions available when they do not
conflict and are not very compatible (ie emacs) but if we are talking
about 50 packages...
Keepping two
Le Tue, Aug 06, 2002 at 04:10:31PM +1000, Anthony Towns écrivait:
Anyway, the point of setting up a separate area as Brendan has is that
it gives you somewhere to mess around with things, without having to
commit to maintaining them in any particular way, or to worry about
people who aren't
Hello,
in my last mail to [EMAIL PROTECTED] I asked if someone was willing
to manage the staging area if we go on with that solution. Nobody
replied. It looks like solution 3 is not very popular among the
people on debian-gtk-gnome...
Anyway, I think that everything that could be said has been
Le Thu, Aug 15, 2002 at 02:56:17PM +0200, Rémi Letot écrivait:
That's not easily doable and nobody has ever proposed it in the
debate.
Make them conflict if it's not possible to have both installed at the
same time.
This has nothing to do with the point of Ian Jackson. Ian told about
Le Thu, Sep 05, 2002 at 12:14:18PM +0200, Marcelo E. Magallon écrivait:
patching gconf. Is there anything else?
Some Gnome1.4 applets have not been ported (maybe won't be).
IMO unstable users get what they paid for: a distribution which is not
ready for release and which has annoyances
Hey,
you still have a decision to take for Gnome2. It's more than a month
since the request of the committee. And Jeff Waugh agreed with my
summary of the irc chat. So don't expect anything more...
(and if you have followed the discussion, the choice left to you is
basically between soluton 1
Hi,
can someone explain me what the committee is waiting for ?
Everything has been said and discussed, it's time to organize
the vote. Three choices :
1. Gnome2 in unstable right now (replacing Gnome1.4 in unstable,
G1.4 would be kept in testing anyway)
2. Gnome2 in unstable right now with
Le Sun, Sep 15, 2002 at 12:00:30AM +1000, Anthony Towns écrivait:
On Sat, Sep 14, 2002 at 12:07:06PM +0200, Raphael Hertzog wrote:
can someone explain me what the committee is waiting for ?
It's probably not the explanation you're looking for, but you're insane
if you expect to get
Le Wed, Sep 18, 2002 at 01:19:31AM -0400, Colin Walters écrivait:
So, is it?
Well, personally my feelings are that it's pretty good. It is at least
Same for me.
on most Debian mirrors. On the other hand, it's more work for the
ftpmasters to deal with new packages.
Gnome2 doesn't
On Tue, 28 Feb 2006, Ian Jackson wrote:
What, then, is the intended meaning when the policy manual talks about
`wrappers' for non-free programs ? (Feel free to say that the wording
is suboptimal and shouldn't be read so closely.)
Wrapper like installation wrappers: free code that downloads a
On Tue, 28 Feb 2006, Raul Miller wrote:
On 2/28/06, Raphael Hertzog [EMAIL PROTECTED] wrote:
On Tue, 28 Feb 2006, Raul Miller wrote:
On 2/28/06, Raphael Hertzog [EMAIL PROTECTED] wrote:
What's so different between my own non-free program and my own non-free
card which requires a non
On Wed, 01 Mar 2006, Raul Miller wrote:
Let's grant that any moving to contrib will only happing in unstable/testing
(and future stable) releases of debian.
Do you see a problem with moving these to contrib? After all, everything
Honestly I don't care enough about either those libs or
On Wed, 01 Mar 2006, Raul Miller wrote:
Now, you use that input how you want and you make up your own opinion.
Ok, correct me if I'm wrong, here's how I'm understanding what you
wrote: You feel that the contents of the contrib section mentioned in the
social contract should be mechanically
On Thu, 14 Sep 2006, Raul Miller wrote:
Put differently, I do not understand the distinction between
The purpose of the ndiswrapper package is to provide an ABI layer
on top of the Linux kernel that is compatible with the interface for
Windows NDIS drivers
and
wrapper
about this document).
However, Raphael Hertzog decided to ignore this request, and continues
to commit changes directly, and now even hijacked the package by adding
himself as uploader without even considering to speak with me beforehand.
I didn't remove you from the Uploaders field. I just
On Sun, 05 Aug 2007, Andreas Barth wrote:
* Sam Hocevar ([EMAIL PROTECTED]) [070805 14:09]:
Could we try to first exhaust other means of consensus reaching
before summoning the tech-ctte with this?
I tried. Raphael told me:
Let me insert the start of the discussion:
buxy FYI, I've
On Sun, 05 Aug 2007, Ian Jackson wrote:
I'd like to ask Andreas and Raphael how they each propose to handle
the maintainership of this package in future.
Raphael says he wants a team. Raphael: what team did you have in
mind ? Who will help you ?
I've not been planning a hijack of the
On Mon, 06 Aug 2007, Adeodato Simó wrote:
I'll throw my 2¢ here:
The policy you have in place is there to ensure changes get reviewed
*before* being committed, partly because what gets commited gets
immediately published and hence Raphael's review after commit via the
PTS diff mail is not
On Wed, 12 Mar 2008, Steve Langasek wrote:
That's a fair criticism, but I don't think it changes the fact that making
style changes while there's a major branch merge outstanding is precisely
the wrong thing to be doing, because it directly impedes merging and causes
more work even if everyone
On Mon, 05 Jan 2009, Don Armstrong wrote:
Would
1) an upload to experimental with
2) all of the issues that have been identified as RC filed as RC
bugs against the package with
3) acceptance into sid occuring only when the RC bugs which have
a serious
important to support the ftpmasters'
discretion so I'm going to carry on and discuss it a bit ...)
Raphael Hertzog writes (Bug#510415: tech-ctte: Qmail inclusion (or not) in
Debian):
On Tue, 06 Jan 2009, Ian Jackson wrote:
I'm not uneasy with this at all. The ftpmasters' job
Hi,
On Fri, 09 Jan 2009, Russ Allbery wrote:
I'm with Steve on this. I think the ftp team review is valuable, and as a
project it takes us much more effort to deal with critically buggy
packages after they're in the archive than before they get there.
All of the teams who have to deal with
On Mon, 12 Jan 2009, Steve Langasek wrote:
Whoever takes the decision, we still need an agreed upon definition of
crap, otherwise people will be unhappy to not be able to maintain the
piece of software they care about. Even if that software is crap.
Do the definitions of grave and
Le samedi 09 janvier 2010, Sam Bisbee a écrit :
On Sat, Jan 09, 2010 at 06:19:27PM +0300, Sergei Golovan wrote:
On Sat, Jan 9, 2010 at 5:36 PM, Raphael Hertzog raph...@ouaza.com wrote:
Le samedi 09 janvier 2010, Sergei Golovan a écrit :
+ - split package into couchdb and couchdb-bin
Hello,
On Thu, 14 Jan 2010, Sam Bisbee wrote:
As I said before, you can fork something without making code changes to it.
It's a fork because the packaging is significantly different than the way it's
packaged upstream. I did not mean to suggest that upstream doesn't want people
to use
Package: tech-ctte
(a change in lintian is triggering my request)
On Thu, 11 Mar 2010, Cyril Brulebois wrote:
following the instructions given by Frans in [1], I've written a tiny
check to ensure I wasn't missing any occurrences in the bunch of udebs
I'm currently adding. I guess it would be
FWIW, this bug report was X-Debbugs-Cc: Cyril Brulebois k...@debian.org,
lintian-ma...@debian.org, debian-b...@lists.debian.org,
debian-d...@lists.debian.org
So all parties are aware of the tech-ctte request.
Cheers,
--
Raphaël Hertzog
Like what I do? Sponsor me:
Hi Russ,
On Tue, 23 Mar 2010, Russ Allbery wrote:
On the Lintian side, I saw the patch come in from someone who's actively
working on udebs, checked the history cited in the patch, saw that it was
requested by Frans Pop, and considered that a fairly authoritative source
for what d-i wants.
On Wed, 31 Mar 2010, Don Armstrong wrote:
On Tue, 23 Mar 2010, Raphael Hertzog wrote:
I would suggest to fix lintian to accept all variants just like
dpkg-gencontrol/dpkg-genchanges do and just like debhelper does.
So does dpkg-dev now discard Package-Type for udebs? Or not?
No, it does
On Thu, 01 Apr 2010, Don Armstrong wrote:
On Thu, 01 Apr 2010, Raphael Hertzog wrote:
I know this is the key issue, that's why the subject of the request is the
only question Should Package-Type be included in udebs or not?.
Good.
There are advantages and disadvantages to both
On Fri, 21 May 2010, Ian Jackson wrote:
+---+-
Rename A to B | optional make A | Conflicts: A
| dummy/transitional| Replaces: A
| Depends: B |
Hi,
On Fri, 21 May 2010, Ian Jackson wrote:
So if we want the views of those who are (a) not socially
dysfunctional and (b) not committed to a side of this dispute already,
we will probably have to let them express their opinions in a more
private setting.
We regularly express our concerns
Hi,
On Sun, 04 Jul 2010, Ian Jackson wrote:
What would be needed to fix it up for old systems ? How easy is it to
detect and distinguish the situation where the sysadmin deliberately
changed it (which AIUI is something they may reasonably do if they
want the additional assurance and are
Hi,
On Mon, 05 Jul 2010, Steve Langasek wrote:
* Give python-defaults, python3-defaults, python-central and
setuptools/distribute packages to a team chosen by CTTE and accepted by
bug submitters. If they will choose to include me, the first thing I
will propose to do after releasing
reassign 552688 tech-ctte
retitle 552688 Please decide how Debian should enable hardening build flags
tag 552688 - wontfix
thanks
I think none of the discussions up to now have resulted in a consensus
among all the parties. Most people are in favor of changing the defaults
in GCC, except the gcc
CCing Kees Cook, he has been the one leading the efforts up to now. I hope
he can answer your queries.
Hi,
On Sat, 20 Nov 2010, Don Armstrong wrote:
There are a couple of things here that should be worked out first
before the CTTE can make a decision:
1) Has gcc's upstream been approached
Hi,
On Sun, 21 Nov 2010, Matthias Klose wrote:
I assume that there is a decision to turn on hardening defaults?
Who made it, and which defaults to turn on? Which ports should it
use? Where is it documented? So involvement of the ctte seems to
be a bit premature, asking the *how* before the
Hi,
On Mon, 22 Nov 2010, dave b wrote:
Sir, I think you should be more polite:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=5726
Please don't dig old mails to justify your assertion. He was trying to be
polite (even if it was not obvious to you).
I was simply voicing what I thought as a
On Tue, 29 Mar 2011, Dmitry E. Oboukhov wrote:
The key point is he disagrees DFSG.
I also witnessed this when I contacted him about his dropbox package
(before it got removed).
He's not a Debian developer (and not a DM AFAIK) and you were his
entry points to Debian, so I don't think there's
Hi,
On Mon, 06 Jun 2011, Steve Langasek wrote:
3) Implement support for calling 'debian/rules build-arch' in place of
'debian/rules build' if a Build-Options field is set in debian/control
of the source package specifying that this target is supported.[3]
FYI with the recent
Hi,
On Mon, 06 Jun 2011, Roger Leigh wrote:
Has the following been considered:
- adding a command-line option for dpkg-buildpackage to explicitly
enable particular build-features (overriding the feature in the
source package).
This has not been suggested yet, I'm not opposed to the idea
(Bcc to debian-dpkg for info)
On Mon, 06 Jun 2011, Steve Langasek wrote:
If this were to be put to a vote today, I would propose the following ballot
options:
1) Implement support for calling 'debian/rules build-arch' in place of
'debian/rules build' by checking for the presence of the
On Sat, 11 Jun 2011, Steve Langasek wrote:
This actually reads to me the same as option 1. What distinction are you
meaning to draw here? It's not very direct use of build-arch if we're
checking 'make -qn' first. The only other differences I see here are
issuing a warning, and explicitly
Hi,
Matthias Klose suggested that we had a chat together (tech-ctte, me as
dpkg co-maintainer, doko as gcc maintainer) so that we can discuss how
to go forward given that none of the options on the table seem to please
everybody.
Since Steve leaves on wednesday, I would suggest to try to do it
Hi,
On Sat, 20 Nov 2010, Raphael Hertzog wrote:
I would really like Debian to build hardened binaries by default and it
would be great if the switch could happen early in the wheezy cycle. For
this I think we need to have a clear plan and I hope the technical
committee can bring some clarity
On Tue, 26 Jul 2011, Raphael Hertzog wrote:
We evaluated how dpkg-buildflags can be used for this. For most
autoconf/automake-based build systems there are 2 ways to inject flags:
1/ On the ./configure command line:
./configure --with-foo CFLAGS=... LDFLAGS=... ...
2/ In the environment
Hi,
On Wed, 27 Jul 2011, Kees Cook wrote:
TODO: revert debian/buildflags support, and implement
support for the environment variable DEB_flag_MAINT_operation which
work exactly like the corresponding DEB_flag_operation except it's
meant to be used by the package maintainer within
Hi,
On Tue, 26 Jul 2011, Raphael Hertzog wrote:
Assuming that all those improvements are done, the consensus was that
it's fine for dpkg-buildflags to start emitting the hardening build
flags by default. According to Ubuntu's experience only a few dozen of
packages are broken by the presence
Hi,
On Thu, 28 Jul 2011, Kees Cook wrote:
On Wed, Jul 27, 2011 at 11:56:39PM +0200, Raphael Hertzog wrote:
The current implementation in my branch is that PIE is disabled by defaut
but if you set DEB_BUILD_HARDENING_PIE=1 then it will be used. This was
easily done on top
On Thu, 28 Jul 2011, Kees Cook wrote:
It would not be reasonable for dpkg-dev to depend on hardening-includes so
my plan was basically to move this logic into dpkg-dev. But instead of
duplicating it we can find a way for hardening-includes to reuse the logic
that would be integrated in
Hi,
On Thu, 28 Jul 2011, Kees Cook wrote:
Oh, I've thought of one additional detail in making these defaults.
-Werror=format-security was only recently added, and this will likely
cause a fair level of FTBFS from some packages. This is not one of the gcc
defaults used in Ubuntu. It was added
On Fri, 29 Jul 2011, Steve Langasek wrote:
On Tue, Jul 26, 2011 at 11:32:27PM +0200, Raphael Hertzog wrote:
TODO: add a STRIP operation to the set of operations supported by
dpkg-buildflags. DEB_CFLAGS_MAINT_STRIP=--foo --bar would basically
drop all occurrences of --foo and --bar
Hi Josip,
On Thu, 08 Sep 2011, Josip Rodin wrote:
Instead, it is important to retain the age-old idea that the rules file has
its own calling convention (an API) that isn't linked to one specific
implementation and is instead properly specified in Debian policy, allowing
developers some
Hi,
On Sat, 23 Jul 2011, Steve Langasek wrote:
Discussion appears to have died out on this thread, so it doesn't appear
anyone from the TC is waiting for more information in order to make up their
mind and I think it's (past) time to call a vote on this.
Can we get a vote and a decision,
Hi,
On Thu, 12 Jan 2012, Roger Leigh wrote:
At this point, we have one working and well tested solution.
Which one are you referring to ?
Is there any point in waiting on the TC at this point given that it's
really the only sensible choice (as in, it's been tested on the whole
archive and
On Fri, 27 Jan 2012, Guillem Jover wrote:
This fallback is a temporary measure until all packages have been
converted to properly support the build-arch and build-indep targets.
Actually thinking about this, making this temporary will imply that
once this would get removed
On Thu, 02 Feb 2012, Roger Leigh wrote:
On Fri, Jan 27, 2012 at 08:22:22AM +0100, Raphael Hertzog wrote:
On Fri, 27 Jan 2012, Guillem Jover wrote:
This fallback is a temporary measure until all packages have been
converted to properly support the build-arch and build-indep
On Thu, 02 Feb 2012, Guillem Jover wrote:
Obviously part of this delay is my fault as the active blocking agent,
the one maintaining its C code base, but the trigger has been internal
working style discrepancies between Raphaël and me, which we have
discussed privately several times, and for
Hi,
On Sat, 31 Mar 2012, Russ Allbery wrote:
I have a sneaking suspicion that this may not actually be about what it
says on the tin, but nonetheless, I'll reply to the request as submitted.
I suspect an April's fool from a timezone different than the one Joey Hess
lives in :-)
Cheers,
--
Hi,
On Wed, 26 Sep 2012, Ian Jackson wrote:
But I'm not convinced that this is the right basis to think about it.
It is not a good precedent to set that if a matter is brought to the
TC, the maintainer who loses the debate in the TC will do something
which undermines the effect of the TC
On Fri, 12 Oct 2012, Ian Jackson wrote:
Don Armstrong writes (Bug#688772: gnome Depends network-manager-gnome):
1) we decide that failures of NM to detect basic ifupdown
configurations and avoid overriding them are bugs, possibly of RC
severity
2) given the gnome maintainer's desire to
Hi,
this is a reply to a message from the older bug but it has never
been answered and I believe it's useful to take a proper decision
so I answer in the new bug:
On Tue, 11 Sep 2012, Ian Jackson wrote:
Jeremy Bicha writes (Bug#681834: Call for votes on network-manager, gnome):
I see two
Hi,
On Thu, 25 Oct 2012, Ian Jackson wrote:
Raphael Hertzog writes (Re: Bug#681834: Call for votes on network-manager,
gnome):
Nobody responded to this but while discussing with the GNOME maintainers
I quickly got the answer. NM is a build-time dependency of GNOME Shell
but Debian has
Hi,
On Fri, 26 Oct 2012, Michael Biebl wrote:
This would also help in situations where users install both wicd and
network-manager by accident, which usually doesn't really work well
since e.g. both spawn their own instance of wpa_supplicant.
A more detailed reply will follow soon.
I
Hi,
On Wed, 06 Feb 2013, Bdale Garbee wrote:
two at a time. Holding d-i's build dependencies static in unstable for
more than half a year is just nuts to me! Sure seems like d-i is
something we should build using the components of the release it will be
contained in and not unstable... but
On Thu, 07 Feb 2013, Raphael Hertzog wrote:
on the mirror and not in the package repository (the installer directories
are shared between wheezy and sid).
Cyril pointed out to me that this specific point is wrong, while
wheezy/main/installer-* and unstable/main/installer-* have the same
content
Hi Thomas,
On Mon, 15 Apr 2013, Thomas Goirand wrote:
So, before I summit a bug to the ctte and escalate this issue, I would
like some advices from both the new DPL and the ctte.
I'm part of neither and I can understand your frustration but your mail
has been written too quickly while the
Hi,
On Sun, 23 Jun 2013, Russ Allbery wrote:
Based on the prior discussion in this bug, it looks like this is just a
case of an overwhelmed maintainer who hasn't had time to work on Debian.
And who apparently fails to acknowledge it. Peter recently packaged
libwebsockets (as a response to an
Hi,
On Mon, 18 Nov 2013, Ian Jackson wrote:
chance of winning. The reason being that it is not worth forcing
other TC members to decide between snubbing the candidate and
misrepresenting their views, unless we really have to to get the right
answer.
Or to put it another way: I am content
Hi,
On Sun, 01 Dec 2013, Steve Langasek wrote:
More review and more usage will lead to more bugs being found, we should
rather applaud Red Hat for investing resources and be diligent. After all
Red Hat is the only distro staffing a proactive product security team
(from which everyone is
On Mon, 30 Dec 2013, Ian Jackson wrote:
The only alternative I see is for systemd-shim to declare a
Replaces: against systemd without a Conflicts,
This would be quite wrong; Replaces is not supposed to be used like
that (but you apparently know that).
How do the systemd maintainers
On Thu, 02 Jan 2014, Ian Jackson wrote:
And, despite the fact that the decision has become very politicised
(to some extent along the lines of preexisting camps of strongly
disagreeing contributors), I think it is primarily a technical
decision.
The line of thought that you have been
On Thu, 02 Jan 2014, Russ Allbery wrote:
Ian Jackson ijack...@chiark.greenend.org.uk writes:
And, despite the fact that the decision has become very politicised (to
some extent along the lines of preexisting camps of strongly disagreeing
contributors), I think it is primarily a technical
Hi,
On Mon, 17 Nov 2014, Bdale Garbee wrote:
With the resignation of Russ and notice of impending resignation from
Colin, I believe we should begin the process of finding new members for
the committee.
It has not been that long since the last nomimation and you might want
to ping the last
So I have been following this whole discussion and I would like to
provide my input to Ole and the blends team.
- adding a new important package to work-around the fact that tasksel
maintainers were busy/inactive was not a good move. As you all
noted, the list of blends does not change often
On Wed, 21 Dec 2016, Ole Streicher wrote:
> I am quoting popcon here since they give a lower estimate of the number
> of users who actually did the test. Nothing more. Nothing about importance.
It gives an estimate of users who ran debootstrap and got the package
installed. It does not give an
On Sat, 24 Dec 2016, Cyril Brulebois wrote:
> So I've just looked at the proposed changes, and adding a prompt at this
> point is not an option: we're changing logic during the freeze, and
> adding translatable material (not the kind of hidden stuff that might
> happen with obscure preseeding
Hi,
On Sat, 28 Jul 2018, Colin Watson wrote:
> > Debian should not seek to prevent maintainers doing something that
> > they have agreed to do in collaboration with downstreams.
>
> My memory of the origin of this feature is that the dpkg developer who
> originated it asked me if it might help
On Tue, 28 Jan 2020, Thomas Goirand wrote:
> This is exactly what should be avoided. It's perfectly fine to try to
> use opensysusers with systemd if one wants. In fact, that's exactly the
> best way we could do to be able to test it. Also, dpkg-divert is really
> ugly, and something you use as
Hi,
On Wed, 13 Oct 2021, David Bremner wrote:
> >The which(1) program must not print any deprecation warnings.
>
> I remain to be convinced on this point. If I understand the issue
> correctly the problem is with autopkgtests failing because they were not
> expecting output on stderr. I
On Mon, 01 Nov 2021, Sean Whitton wrote:
> Of course we should be exploring the new avenues that you mention. But
> becoming more willing to break unstable/testing than we are at present
> might also be good for our project.
Maybe, maybe not. What are you basing your assertion on?
From my
On Sun, 24 Oct 2021, Clint Adams wrote:
> > In any case, a message saying that which is deprecated when in fact
> > `which` will stay around (but maintained in another packages) is not
> > helpful.
>
> Tell me, what would be helpful?
A coordinated take over of the binary with a proper transition
88 matches
Mail list logo
