#x27;s rhetoric and style.
I stand that removing those documents will not make Emacs more free
than it is nowdays.
You are an extremist, a fundamentalist, with no bits of common sense
at all. You aren't helping anyone, not even the Debian Project.
So just please go away and find yourself another sandbox.
--
Jérôme Marant
stuff.
> Trust me, if that passes, you'll see a lot of unmodifiable stuff going
> into main. I seriously doubt it will pass; if you really want to wait
> to see, however, fine with me.
Sooner or later, Debian will have to decide if it definitely wants to
leave the project in the hands of extremists. I hope the GR will lead
us to the right path, that is getting rid of fundamentalists.
--
Jérôme Marant
an ad hominem attack, and was given with no evidence.
I'm sad I have to use such words but I don't think there is anything
else to say.
It is based on your interventions on debian-legal. I don't have
to give evidence, you already have.
> > You aren't helping anyone, not even the Debian Project.
> OK, that's partly an ad hominem attack, but worse, it is provably false.
> I am not the only one who gains direct benefit from having a clear,
> obvious division -- "main" exclusive of license texts -- between
> material satisfying the DFSG and that which doesn't.
It is an extreme view of the DFSG, I call this fundamentalism.
--
Jérôme Marant
Quoting Nathanael Nerode <[EMAIL PROTECTED]>:
> Jérôme Marant wrote:
> > Sooner or later, Debian will have to decide if it definitely wants to
> > leave the project in the hands of extremists. I hope the GR will lead
> > us to the right path, that is getting rid o
uments contain invariant sections, they will have to be
moved to non-free very soon.
So, I'll propose to move those essays to non-free as well at the same
time in order to avoid changing the orig tar as much as possible.
Shall we make a truce, a peace even, and move on?
--
Jérôme Marant
es C-h C-p points to the documentation (info documentation) or to
the DOC file ?
I guess some patches will have to be added to handle such cases, yes.
I'm sorry you don't like this. I'm not really fond of it either, but I
have the choice of either do what the Project decided or resign from the
Project. I've chosen the former.
--
Jérôme Marant
rig tar as much as possible.
>>
>> Shall we make a truce, a peace even,
>
> Or make Emacs package unofficial :-). Personally I wouldn't care.
>
> Best regards and thanks for your work on Emacs packaging.
Will grabbing documentation from non-free will be a mjor inconvenience
for you? I'm not so sure.
--
Jérôme Marant
Quoting "Janusz S. Bieñ" <[EMAIL PROTECTED]>:
> On Tue, 14 Mar 2006 Jérôme Marant <[EMAIL PROTECTED]> wrote:
>
>
> [...]
>
> > Will grabbing documentation from non-free will be a mjor inconvenience
> > for you? I'm not so sure.
>
>
e were allowed to remove those invariant sections (not necessarily
to be able to modify them since they are essays), manuals would stay
in main.
--
Jérôme Marant
ction is broken, and so something wrong is
The ppc64 detection is not broken. It has been tested by the
ppc64 porters.
> happening on ppc32. Perhaps drop this patch and see if that causes
> the regression to vanish?
One must double check with the CVS trunk then.
--
Jérôme Marant
Rob Browning <[EMAIL PROTECTED]> writes:
> Jérôme Marant <[EMAIL PROTECTED]> writes:
>
>> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
>
>>> Perhaps the ppc64 detection is broken, and so something wrong is
>>
>> The ppc64 detection is
day of work fidling, trying to find out what's wrong
> and that good old emacs21 with GUI is gone.
How about being polite with people and stop whining?
Nothing has changed regarding window manager entries. Did you check
that the problem doesn't come from your window manager?
--
Jérôme Marant
t; emacs21_21.3+1-9.diff.gz before the debian/patches/*
> so it thinks it needs to rebuild those.
>
> In the emacs21_21.3+1-8.diff.gz file the order of the
> files was different so it did not show that problem.
Rob, do you have any idea about how to fix this?
--
Jérôme Marant
to do this automatically from the makefile
and generate a dpatch manually every we have to regenerate the
configure script.
Currently, the only file which is modified when changing configure.in
is configure, so this should be straightforward.
Cheers,
--
Jérôme Marant
Rob Browning <[EMAIL PROTECTED]> writes:
> Jérôme Marant <[EMAIL PROTECTED]> writes:
>
>> To my mind, we should avoid to do this automatically from the makefile
>> and generate a dpatch manually every we have to regenerate the
>> configure script.
>
e was because I didn't consider the problem presented by the
> timestamps of files in the debian diff and so came up with a broken
> solution.
I almost all cases, changes to 'configure.in' only change 'configure'.
In the remaining cases, changes only happen in the toplevel of the
tree. I don't think it is unreasonnable to avoid duplicating the
whole tree, isn't it?
> The way things were intended to work, the autofiles.diff should only
> have been re-built if you changed a relevant file (i.e. *.dpatch), or
> if you manually requested a rebuild during "prepare-release".
I understood that.
--
Jérôme Marant
Hi,
Is anyone taking care of this?
Thanks.
--
Jérôme Marant
ce to request pin. See my ITP for bluez-gnome which is going to
> provide a replacement.
>
> bluez-pin should be removed from unstable.
Thanks.
--
Jérôme Marant
Hi,
I recenlty updated my system and Xorg won't start.
It looks like the problem is still around.
Regard,
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Please ignore my previous mail. The culprit is libdrm2.
Regards,
- Mail Original -
De: "Debian Bug Tracking System"
À: "Jérôme Marant"
Envoyé: Samedi 28 Mars 2009 18:24:02 GMT +01:00 Amsterdam / Berlin / Berne /
Rome / Stockholm / Vienne
Objet: Bug#517005:
Package: libdrm2
Version: 2.4.5-2
Severity: serious
Hi,
After upgrading from 2.3.1-2 to 2.4.5-2, my Xorg failed to
work properly. After downgrading to 2.3.1-2, situation is
normal again.
I do use latest Xorg from unstable along with fglrx non-free
drivers, and kernel 2.6.26.
Regards,
--
To
myself and applied patches
that used to work.
Regards,
--
Jérôme Marant
stamp=1165216366&file=log
> for the full build log.
Hi,
Nothing changed in that part of the code nor in build option or anything related
and I was building just fine in 21.4a+1-1.
--
Jérôme Marant
from somewhere else though because it looks
file on other architectures.
--
Jérôme Marant
Le jeudi 07 décembre 2006 02:20, Rob Browning a écrit :
> I suppose it's possible that that changing the series order might have
> broken something if I didn't re-run "autofiles-sync" after the move,
> but I thought I did.
Hi Rob,
Are you working on it ?
--
Jérôme Marant
p you on "my" mipsel-machine, please say so.
Could you please perform a fresh unpacking of the package, and then try:
cd emacs21-21.4a+1
fakeroot debian/rules autofiles-sync
and build the package.
Thanks in advance.
--
Jérôme Marant
Le vendredi 15 décembre 2006 11:38, Andreas Barth a écrit :
> * Jérôme Marant ([EMAIL PROTECTED]) [061215 11:35]:
> > Le mardi 12 décembre 2006 16:46, Andreas Barth a écrit :
> >
> > >
> > > As described in the developers reference:
> > > http://
g I can help you on "my" mipsel-machine, please say so.
Andreas,
Have you tried anything yet w.r.t. my last reply?
--
Jérôme Marant
EEKO
> configure.in:29:AC_CONFIG_LIBOBJ_DIR(src)
> make: *** [autofiles-sync] Error 1
> zsh: exit 2 fakeroot debian/rules autofiles-sync
Hmm, some package might be missing.
--
Jérôme Marant
ny hint which one that could be? What auto* do you use yourself?
Those macros are part of autoconf.
--
Jérôme Marant
quot;FTBFS". The autofiles-sync rule is run manually before
building the package.
--
Jérôme Marant
#x27;t know. Why does it fail only on mipsel?
As I said no patch has been applied to the C code nor anything related
to it (like autotools).
Dare I question the toolchain?
--
Jérôme Marant
Le vendredi 15 décembre 2006 16:45, Martin Michlmayr a écrit :
> * Jérôme Marant <[EMAIL PROTECTED]> [2006-12-15 16:08]:
> > Then I don't know. Why does it fail only on mipsel?
> > As I said no patch has been applied to the C code nor anything related
> > to it (
n rescheduled for building yesterday and it
is still failing.
Please note that vaughan is not the build machine. It is "rem" which
is maitained by Ryan Murray.
--
Jérôme Marant
Le samedi 16 décembre 2006 19:08, Rob Browning a écrit :
> Jérôme Marant <[EMAIL PROTECTED]> writes:
>
> > It looks like it has been rescheduled for building yesterday and it
> > is still failing.
> >
> > Please note that vaughan is not the build machine. I
Le samedi 16 décembre 2006 21:09, Rob Browning a écrit :
> Jérôme Marant <[EMAIL PROTECTED]> writes:
>
> > Shall we contact Ryan?
>
> Sounds like a good idea. Though I suppose there's another difference
> between vaughan and the buildd. On vaughan I wasn't
Le jeudi 21 décembre 2006 21:34, Rob Browning a écrit :
> Jérôme Marant <[EMAIL PROTECTED]> writes:
>
> > Rob, are you taking care of this, or should I?
>
> Please do, if you have the time.
I will only available till next Saturday so I guess someone will have to
take
ipsel
machine
which seems to be available), could you please help us investigating the
problem?
Thanks in advance.
--
Jérôme Marant
Selon Andreas Barth <[EMAIL PROTECTED]>:
> * Jérôme Marant ([EMAIL PROTECTED]) [061106 07:07]:
> > [...]
>
> When do you plan to upload a fix for this bug? Or should I rather upload
> an NMU?
I've already prepared a fix plus other fixes.
Rob wants to upload the packa
39 matches
Mail list logo
