On Thu, 2023-12-28 at 18:38 +, stefan1 wrote:
>
> Anyway, at least I don't have many ebuilds to patch to support python
> 3.12.
If you're comfortable with git, you could switch your ::gentoo repo to
a git checkout and edit/commit your changes there. Then when you git
pull/rebas
Hi all,
i don't know if it is a bug oder a missing dependency for
gnome-extra/evolution-data-server-2.26.3, that i recently tried to
install. the error i got was like
/bin/sh: line 1: gtkdoc-rebase: command not found
so i emerge -av1 dev-util/gtk-doc and everything worked fine.
emerge --info
On Thu, 12 Feb 2009 16:36:31 -0600
Joseph Davis jos...@uh.edu wrote:
I looked as you suggested, and this is what I found - I'm still clueless.
which: no gtkdoc-rebase in
(/usr/local/sbin:/sbin:/usr/sbin:/usr/lib/portage/bin:/usr/local/bin:/bin:/usr/bin:/opt/bin:/usr/i486-pc-linux-gnu/gcc
Maximilian Bräutigam writes:
i don't know if it is a bug oder a missing dependency for
gnome-extra/evolution-data-server-2.26.3, that i recently tried to
install. the error i got was like
/bin/sh: line 1: gtkdoc-rebase: command not found
so i emerge -av1 dev-util/gtk-doc and everything
and installed in /etc/init.d -- except for
net.lo.
Now net.lo and the symlink net.eth0 can't be found, fail to start etc.
I used /var/git/openrc/git pull --rebase to do the deed. Is there a
way to focus the command on just the one service?
Maxim
/gtkdoc-rebase --
relative --dest-dir=/var/tmp/portage/dev-libs/dbus-glib-0.88/image/ --html-
dir=${installdir}
I don't really know where to start looking.
I just know Google is going to give me millions of useless hits with that
search, but I'll hope over to b.g.o. meanwhile and poke around
. Whoever writes external module
should merge it into mainline or rebase every release.
branch which is some
commit of Linux with your patch applied, and rebase your changes onto
whichever release you want to target (might need to use git rebase --
onto).
> I don't envisage any upstream accepting my patch. The powers that be
> were adamant that the soft scrolling be removed
Am Dienstag, den 21.07.2009, 13:19 +0200 schrieb Alex Schuster:
Maximilian Bräutigam writes:
i don't know if it is a bug oder a missing dependency for
gnome-extra/evolution-data-server-2.26.3, that i recently tried to
install. the error i got was like
/bin/sh: line 1: gtkdoc-rebase
reading the thread already?
The only people left are ancient codgers like me who take delight in penning
witty responses, dripping with sarcasm, designed to highlight just how idiotic
behaviour on the intartubes can be
you want to help? answer me this: why did # /var/git/openrc/git pull
--rebase
-glib fails similarly:
/bin/sh: line 21: 1084 Illegal instruction /usr/bin/gtkdoc-rebase --
relative --dest-dir=/var/tmp/portage/dev-libs/dbus-glib-0.88/image/ --html-
dir=${installdir}
I don't really know where to start looking.
I just know Google is going to give me millions
/sh: line 21: 1084 Illegal instruction /usr/bin/gtkdoc-rebase --
relative --dest-dir=/var/tmp/portage/dev-libs/dbus-glib-0.88/image/ --html-
dir=${installdir}
I don't really know where to start looking.
I just know Google is going to give me millions of useless hits with that
search
what package prevents emerging in previous messages in
terminal near first make [Error 1] etc. When I tried to compile
kcontrol for amarok, I have got similar messages until reemerging kde-libs.
I looked as you suggested, and this is what I found - I'm still clueless.
which: no gtkdoc-rebase
should be /var/git/openrc# git pull --rebase
On 12/1/09, Maxim Wexler maxim.wex...@gmail.com wrote:
so tell me how come none of you quarter-brights have responded to the
email where I say this problem has been fixed?
you want to help? answer me this: why did # /var/git/openrc/git pull
Feb 2009 16:36:31 -0600
Joseph Davis jos...@uh.edu wrote:
I looked as you suggested, and this is what I found - I'm still clueless.
which: no gtkdoc-rebase in
(/usr/local/sbin:/sbin:/usr/sbin:/usr/lib/portage/bin:/usr/local/bin:/bin:/usr/bin:/opt/bin:/usr/i486-pc-linux-gnu/gcc-bin/4.1.2)
make[5
time. That's all the message,
nothing else:
$ genlop -t portage
Illegal instruction
Now emerge dbus-glib fails similarly:
/bin/sh: line 21: 1084 Illegal instruction /usr/bin/gtkdoc-rebase --
relative --dest-dir=/var/tmp/portage/dev-libs/dbus-glib-0.88/image/
--html- dir
,
nothing else:
$ genlop -t portage
Illegal instruction
Now emerge dbus-glib fails similarly:
/bin/sh: line 21: 1084 Illegal instruction /usr/bin/gtkdoc-rebase --
relative --dest-dir=/var/tmp/portage/dev-libs/dbus-glib-0.88/image/
--html- dir=${installdir}
I don't
with the mysterious error Illegal
instruction, and it's consistent - every time. That's all the message,
nothing else:
$ genlop -t portage
Illegal instruction
Now emerge dbus-glib fails similarly:
/bin/sh: line 21: 1084 Illegal instruction /usr/bin/gtkdoc-rebase --
relative
and breaking whatever
needed in order to be in better shape. Whoever writes external module
should merge it into mainline or rebase every release.
Well, it seemt that you are confusing user-interfaces with
kernel-internal-interfaces :-(
I was of course writing about a kernel - user interface
as the originals,
but would want to see the updated files straight before remaking my
modifications.
I looked through man pages, git pull --rebase didn't work; I got error
messages. Should I do git reset or should I git checkout each modified
file one-by-one before git pull?
There is a lot
not disagreeing at all with many of the gripes about git. I still
share most of them, but now I feel like I'm the one in control and the
fact that git pull doesn't rebase by default is just an annoyance and
not a source of arcane behavior.
Like I said, beautiful design, horrible interface.
--
Rich
git reset`, but what you really want is `git checkout`.
>
> * Want to merge your changes with upstream? There's `git merge`,
> but chances are, you want `git pull --rebase`.
>
> * Want to commit a new file? There's `git commit`, but it won't work.
>
> ...and so on.
So, i
merge your changes with upstream? There's `git merge`,
but chances are, you want `git pull --rebase`.
* Want to commit a new file? There's `git commit`, but it won't work.
...and so on.
That said, after my bicycle, git is probably the most useful piece of
technology I use on a daily basis.
el.org/pub/scm/linux/kernel/git/torvalds/linux.git/.
What I would do is apply your patch on top of that, and then to update
it, rebase the patch onto the new upstream commit you want to update to.
This leads to your patches always being at the tip of the commit history
and not somewhere buried betwe
intermediate versions. Where would I even start searching to find
> this out?
Hey Alan,
The official repository I think is
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/.
What I would do is apply your patch on top of that, and then to update
it, rebase the patch onto th
found and a new patch is created or an
existing one changes, then all of a sudden we get conflicts. If we
apply the new one first, then (say) patches two through five might
apply cleanly, but patches six through eighteen will fail. Now we have
to manually rebase thirteen patches? That just will no
somewhere for safekeeping, as well as the originals,
but would want to see the updated files straight before remaking my
modifications.
I looked through man pages, git pull --rebase didn't work; I got error
messages. Should I do git reset or should I git checkout each modified
file
one-by-one
ant to reset the modifications you've made to a file? There's
> `git reset`, but what you really want is `git checkout`.
>
> * Want to merge your changes with upstream? There's `git merge`,
> but chances are, you want `git pull --rebase`.
>
> * Want to commit a new file? T
so tell me how come none of you quarter-brights have responded to the
email where I say this problem has been fixed?
you want to help? answer me this: why did # /var/git/openrc/git pull
--rebase update all init.d services except net.lo? That's today's
scintillating question.
On 12/1/09, Joshua
hances are, you want `git pull --rebase`.
* Want to commit a new file? There's `git commit`, but it won't work.
...and so on.
That said, after my bicycle, git is probably the most useful piece of
technology I use on a daily basis. All of the time I spent banging my
head on my desk turned out to b
torvalds/linux.git/.
> What I would do is apply your patch on top of that, and then to update
> it, rebase the patch onto the new upstream commit you want to update to.
> This leads to your patches always being at the tip of the commit history
> and not somewhere buried between co
ideas and at best it
will be the thing i've been looking for!
Why keep bare repo at all? That's certainly not a prequisite with
distributed VCS like git.
You can fetch / merge / rebase / cherry-pick commits with git via ssh
just as easy as with rsync, using some intermediate media only if
machines
/bin/glib-genmarshal
checking for glib-mkenums... /usr/bin/glib-mkenums
checking for x86_64-pc-linux-gnu-pkg-config... no
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for gtkdoc-check... /usr/bin/gtkdoc-check
checking for gtkdoc-rebase
checking for gtkdoc-rebase... /usr/bin/gtkdoc-rebase
checking for gtkdoc-mkpdf... /usr/bin/gtkdoc-mkpdf
checking whether to build gtk-doc documentation... no
checking for strptime... yes
checking for _NL_MEASUREMENT_MEASUREMENT... yes
checking locale.h usability... yes
checking locale.h
... no
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for gtkdoc-check... /usr/bin/gtkdoc-check
checking for gtkdoc-rebase... /usr/bin/gtkdoc-rebase
checking for gtkdoc-mkpdf... /usr/bin/gtkdoc-mkpdf
checking whether to build gtk-doc
-check
checking for gtkdoc-rebase... /usr/bin/gtkdoc-rebase
checking for gtkdoc-mkpdf... /usr/bin/gtkdoc-mkpdf
checking for GTKDOC_DEPS... yes
checking whether to build gtk-doc documentation... yes
checking for ANSI C header files... (cached) yes
checking fcntl.h usability... yes
checking fcntl.h
36 matches
Mail list logo
