Re: [gentoo-user] Re: Apache not starting after upgrading Apache/glibc...
Nikos Chantziaras schrieb:
>
> See which packages were built against the new glib. Do:
>$ qlop -l -d 2days
> See which packages were emerged AFTER glibc 2.28. Are they critical
> packages? If not, downgrade glibc anyway. Then rebuild those packages.
I didn't consider those packages as critical (gcc was *not* built
after the glibc upgrade!), so I succeeded to downgrade glibc at last.
But now "emerge -1 apache" doesn't work because "patch" is needed,
and "patch" is still looking for glibc 2.28. And "emerge -1 patch"
seems to need the new glibc anyway:
* patch-2.7.6.tar.xz BLAKE2B SHA512 size ;-) ...
[ ok ]
>>> Unpacking source...
>>> Unpacking patch-2.7.6.tar.xz to
>>> /var/tmp/portage/sys-devel/patch-2.7.6-r3/work
>>> Source unpacked in /var/tmp/portage/sys-devel/patch-2.7.6-r3/work
>>> Preparing source in
>>> /var/tmp/portage/sys-devel/patch-2.7.6-r3/work/patch-2.7.6 ...
* Applying patch-2.7.6-fix-test-suite.patch ...
patch: /lib/libc.so.6: version `GLIBC_2.28' not found (required by patch)
[ !! ]
* ERROR: sys-devel/patch-2.7.6-r3::gentoo failed (prepare phase):
* patch -p1 failed with
/var/tmp/portage/sys-devel/patch-2.7.6-r3/files/patch-2.7.6-fix-test-suite.patch
So it seems that I cannot emerge "patch" because I need to patch
"patch" :-( Am I stuck now??? What to do??
-Matt
[gentoo-user] lm_sensors patch borked?
The emerge of sys-apps/lm_sensors-3.1.2-r1 fails as follows: = # emerge -uDv world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] sys-apps/lm_sensors-3.1.2-r1 [3.1.2] USE="-sensord" 0 kB Total: 1 package (1 upgrade), Size of downloads: 0 kB >>> Verifying ebuild manifests >>> Emerging (1 of 1) sys-apps/lm_sensors-3.1.2-r1 * lm_sensors-3.1.2.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...[ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * CPV: sys-apps/lm_sensors-3.1.2-r1 * REPO: gentoo * USE: amd64 elibc_glibc kernel_linux multilib userland_GNU * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found kernel object directory: * /lib/modules/2.6.33-gentoo-r2/build * Found sources for kernel version: * 2.6.33-gentoo-r2 * Checking for suitable kernel configuration options...[ ok ] >>> Unpacking source... >>> Unpacking lm_sensors-3.1.2.tar.bz2 to >>> /var/tmp/portage/sys-apps/lm_sensors-3.1.2-r1/work >>> Source unpacked in /var/tmp/portage/sys-apps/lm_sensors-3.1.2-r1/work >>> Preparing source in >>> /var/tmp/portage/sys-apps/lm_sensors-3.1.2-r1/work/lm_sensors-3.1.2 ... * Applying lm_sensors-3.1.2-sensors-detect-gentoo.patch ... [ ok ] * Applying lm_sensors-3.1.2-changeset_r5835.patch ... * Failed Patch: lm_sensors-3.1.2-changeset_r5835.patch ! * ( /usr/portage/sys-apps/lm_sensors/files/lm_sensors-3.1.2-changeset_r5835.patch ) = This is what the patch.out file says: * lm_sensors-3.1.2-changeset_r5835.patch * == PATCH COMMAND: patch -p0 -g0 -E --no-backup-if-mismatch < '/usr/portage/sys-apps/lm_sensors/files/lm_sensors-3.1.2-changeset_r5835.patch' == patching file prog/sensord/rrd.c Hunk #1 FAILED at 138. Hunk #2 FAILED at 150. Hunk #3 FAILED at 161. Hunk #4 FAILED at 187. Hunk #5 FAILED at 200. 5 out of 5 hunks FAILED -- saving rejects to file prog/sensord/rrd.c.rej == PATCH COMMAND: patch -p1 -g0 -E --no-backup-if-mismatch < '/usr/portage/sys-apps/lm_sensors/files/lm_sensors-3.1.2-changeset_r5835.patch' == can't find file to patch at input line 6 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |http://bugs.gentoo.org/325083 |http://www.lm-sensors.org/changeset/5835 | |--- prog/sensord/rrd.c |+++ prog/sensord/rrd.c ------ No file to patch. Skipping patch. 5 out of 5 hunks ignored No file to patch. Skipping patch. No file to patch. Skipping patch. No file to patch. Skipping patch. * lm_sensors-3.1.2-changeset_r5835.patch * == PATCH COMMAND: patch -p0 -g0 -E --no-backup-if-mismatch < '/usr/portage/sys-ap ps/lm_sensors/files/lm_sensors-3.1.2-changeset_r5835.patch' == patching file prog/sensord/rrd.c Hunk #1 FAILED at 138. Hunk #2 FAILED at 150. Hunk #3 FAILED at 161. Hunk #4 FAILED at 187. Hunk #5 FAILED at 200. 5 out of 5 hunks FAILED -- saving rejects to file prog/sensord/rrd.c.rej == PATCH COMMAND: patch -p1 -g0 -E --no-backup-if-mismatch < '/usr/portage/sys-ap ps/lm_sensors/files/lm_sensors-3.1.2-changeset_r5835.patch' == can't find file to patch at input line 6 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |http://bugs.gentoo.org/325083 |http://www.lm-sensors.org/changeset/5835 | |--- prog/sensord/rrd.c |+++ prog/sensord/rrd.c ------ No file to patch. Skipping patch. 5 out of 5 hunks ignored == PATCH COMMAND: patch -p2 -g0 -E --no-backup-if-mismatch < '/usr/portage/sys-ap ps/lm_sensors/files/lm_sensors-3.1.2-changeset_r5835.patch' == can't find file to patch at input line 6 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |http://bugs.gentoo.org/325083 |http://www.lm-sensors.org/changeset/5835 | |--- prog/sensord/rrd.c |+++ prog/sensord/rrd.c -- No file to patch. Skipping patch. 5 out of 5 hunks ignored == Shall I delete the patch from /usr/portage/sys-apps/lm_sensors/files/lm_sensors-3.1.2-changeset_r5835.patch and resync? -- Regards, Mick
[gentoo-user] www-client/firefox-3.6.12 headers error
I noticed this error with the autoheader as shown below: * Applying xulrunner-1.9.2-gtk+-2.21.patch ... [ ok ] * Running eautoreconf in '/var/tmp/portage/www- client/firefox-3.6.12/work/mozilla-1.9.2' ... * Running autoconf ... [ ok ] * Running autoheader ... [ !! ] * Running elibtoolize in: mozilla-1.9.2/ipc/chromium/src/third_party/libevent/ * Applying install-sh-1.5.patch ... * Applying portage-1.5.10.patch ... * Applying sed-1.5.6.patch ... * Applying as-needed-1.5.26.patch ... * Running elibtoolize in: mozilla-1.9.2/js/ctypes/libffi/ * Applying install-sh-1.5.4.patch ... * Applying portage-1.5.10.patch ... * Applying sed-1.5.6.patch ... * Applying as-needed-1.5.26.patch ... * Applying uclibc-ltconf-1.3.0.patch ... * Running elibtoolize in: mozilla-1.9.2/modules/freetype2/builds/unix/ * Applying portage-2.2.patch ... * Applying sed-1.5.6.patch ... * Applying as-needed-2.2.6.patch ... * Running elibtoolize in: mozilla-1.9.2/toolkit/crashreporter/google- breakpad/autotools/ * Applying portage-2.2.patch ... * Applying sed-1.5.6.patch ... * Applying as-needed-2.2.6.patch ... * Running eautoreconf in '/var/tmp/portage/www- client/firefox-3.6.12/work/mozilla-1.9.2/js/src' ... * Running autoconf ... [ ok ] * Running autoheader ... [ !! ] >>> Source prepared. This is an amd64 box. I can't recall seeing the same on a x86 machine earlier in the week - but may have just missed it. Is it important? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Problem installing amavisd-new (Gentoo box)
Richard Fish wrote: Take a look at this file, it will have the actual error message in it. If it doesn't make sense to you, feel free to post the contents here. -Richard Richard: Thank you for your response. I haven't had much time to really look. Perhaps this evening... Ok, here are the contents of the output file: # cat amavisd-new-2.4-qmail-lf-workaround.patch-8250.out * amavisd-new-2.4-qmail-lf-workaround.patch * ===== PATCH COMMAND: patch -p0 -g0 -E --no-backup-if-mismatch < /usr/portage/mail-filter/amavisd-new/files/amavisd-new-2.4-qmail-lf-workaround.patch = patching file amavisd Hunk #1 FAILED at 12914. 1 out of 1 hunk FAILED -- saving rejects to file amavisd.rej ===== PATCH COMMAND: patch -p1 -g0 -E --no-backup-if-mismatch < /usr/portage/mail-filter/amavisd-new/files/amavisd-new-2.4-qmail-lf-workaround.patch = missing header for unified diff at line 3 of patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |--- amavisd2006-04-07 22:03:15.0 +0200 |+++ amavisd.ticho 2006-04-07 22:07:00.0 +0200 -- No file to patch. Skipping patch. 1 out of 1 hunk ignored ========= PATCH COMMAND: patch -p2 -g0 -E --no-backup-if-mismatch < /usr/portage/mail-filter/amavisd-new/files/amavisd-new-2.4-qmail-lf-workaround.patch = missing header for unified diff at line 3 of patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |--- amavisd2006-04-07 22:03:15.0 +0200 |+++ amavisd.ticho 2006-04-07 22:07:00.0 +0200 -- No file to patch. Skipping patch. 1 out of 1 hunk ignored ========= PATCH COMMAND: patch -p3 -g0 -E --no-backup-if-mismatch < /usr/portage/mail-filter/amavisd-new/files/amavisd-new-2.4-qmail-lf-workaround.patch = missing header for unified diff at line 3 of patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |--- amavisd2006-04-07 22:03:15.0 +0200 |+++ amavisd.ticho 2006-04-07 22:07:00.0 +0200 ------ No file to patch. Skipping patch. 1 out of 1 hunk ignored ========= PATCH COMMAND: patch -p4 -g0 -E --no-backup-if-mismatch < /usr/portage/mail-filter/amavisd-new/files/amavisd-new-2.4-qmail-lf-workaround.patch = missing header for unified diff at line 3 of patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |--- amavisd2006-04-07 22:03:15.0 +0200 |+++ amavisd.ticho 2006-04-07 22:07:00.0 +0200 ------ No file to patch. Skipping patch. 1 out of 1 hunk ignored Thanks, RV -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Compilation error with StructureSynth
On 11/01 04:05, David Haller wrote:
> Hello,
>
> On Wed, 01 Nov 2017, tu...@posteo.de wrote:
> [..]
> >Thanks a lot for the extensive help, SIR! :)
>
> Thanks.
>
> [..]
> >The patch itself was found (so the local thing works fine) and failed.
> >
> >The *.patch.out is attached to the email and after looking into it I
> >think you will find the problem a hundred years faster than me since
> >you created it. It seems some files are not where they are supposed to
> >be.
>
> Not quite. The "not founds" are normal for epatch/eapply trying
> various '-p' levels... But see below in the patch.out (and nice that
> you supplied that right away).
>
> >There is a glitch in the matrix...they have changed something...I
> >see Schroedingers cat twice.
> >
> >Ah! By the way: According to quantum physics the cite at the bottom of
> >you previous email is wrong :
> >"WANTED: Schroedingers Cat, dead or alive."
> >must be
> >"WANTED: Schroedingers Cat, dead and alive."
> >Heisenberg would not accept this kind of uncertainty -- in
> >principle...
> >;)
>
> *g* You're right. But it's just a quote I picked up long time ago ;)
>
> Anyway, here's the deal:
>
> [..]
> >PATCH COMMAND: patch -p1 -g0 -E --no-backup-if-mismatch --dry-run -f <
> >'/var/tmp/portage/media-gfx/structure-synth-1.5.0-r1/files/structure-synth-1.5.0-gl.patch'
> >
> >==
> >checking file SyntopiaCore/GLEngine/Raytracer/Sampler.h
> >Hunk #1 FAILED at 1 (different line endings).
> >1 out of 1 hunk FAILED
> >checking file SyntopiaCore/GLEngine/Raytracer/VoxelStepper.cpp
> >Hunk #1 FAILED at 122 (different line endings).
> >1 out of 1 hunk FAILED
> >checking file SyntopiaCore/GLEngine/Sphere.h
> >Hunk #1 FAILED at 1 (different line endings).
> >1 out of 1 hunk FAILED
> >
> >patch program exited with status 1
> >==
>
> Because this failed, epatch goes on, confusing you with more a few
> more 'not found' stuff outputs...
>
> >PATCH COMMAND: patch -p2 -g0 -E --no-backup-if-mismatch --dry-run -f <
> >'/var/tmp/portage/media-gfx/structure-synth-1.5.0-r1/files/structure-synth-1.5.0-gl.patch'
> >
> >==
> >can't find file to patch at input line 4
> [..]
>
> Thing is: the source-code of this package has CRLF line endings,
> and, while I added the CRs to my patch, via mail and saving, you
> probably saved them with "just" the LFs.
>
> a) add the '-l' / '--ignore-whitespace' option to patch, don't know if
>that works with epatch/eapply as e.g. 'epatch -l ${FILESDIR}/..', or
>
> b) reencode the line-endings of the patch to match that of the
>source-files. No idea if you can reencode the whole patch or just
>the diff. So ... I'll reattach the patch xzipped, that should keep
>your mail-client from changing the line-endings. xz -d that patch
>then into the files subdir. That's probably the easiest way.
>
> HTH,
> -dnh
>
> --
> Chemie ist auch bloß spezialisierte Physik.
> -- Jens Dittmar in drsst
Moin David,
;)
nope...currently the cat is more dead than alive...
I looked at it!
I did the following:
vim
:set ff
unix
:set ff=dos
:wq
repoman -v manifest (since file has changed)
emerge structure-synth.
BADABOOM! (The fifth element)
See my theorie of uncertainity attached to this mail...
:)
Cheers
Meino
* structure-synth-1.5.0-gl.patch *
PWD: /var/tmp/portage/media-gfx/structure-synth-1.5.0-r1/work/Structure Synth
Source Code
PATCH TOOL: patch -> /usr/bin/patch
VERSION INFO:
GNU patch 2.7.5
Copyright (C) 2003, 2009-2012 Free Software Foundation, Inc.
Copyright (C) 1988 Larry Wall
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Larry Wall and Paul Eggert
==
PATCH COMMAND: patch -p0 -g0 -E --no-backup-if-mismatch --dry-run -f <
'/var/tmp/portage/media-gfx/structure-synth-1.5.0-r1/files/structure-synth-1.5.0-gl.patch'
==
(Stripping trailing CRs from patch; use --binary to disable.)
can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|diff -x '*~' -purN a/SyntopiaCore/GLEngine/Raytracer/Sampler
[gentoo-user] net-misc/openssh-4.3_p2-r1 download error?
Hi All,
How do I overcome this (other than try again in the morning)?
===
# emerge -fDv '=net-misc/openssh-4.3_p2-r1'
Calculating dependencies... done!
>>> Emerging (1 of 1) net-misc/openssh-4.3_p2-r1 to /
>>> Previously fetched file: openssh-4.3p2.tar.gz MD5 ;-)
>>> Previously fetched file: openssh-4.3p2.tar.gz RMD160 ;-)
>>> Previously fetched file: openssh-4.3p2.tar.gz SHA1 ;-)
>>> Previously fetched file: openssh-4.3p2.tar.gz SHA256 ;-)
>>> Previously fetched file: openssh-4.3p2.tar.gz size ;-)
>>> Downloading
http://ftp.club-internet.fr/pub/mirrors/gentoo/distfiles/openssh-lpk-4.3p1-0.3.7.patch
--00:18:01--
http://ftp.club-internet.fr/pub/mirrors/gentoo/distfiles/openssh-l
pk-4.3p1-0.3.7.patch
=> `/usr/portage/distfiles/openssh-lpk-4.3p1-0.3.7.patch'
Resolving ftp.club-internet.fr... 194.158.99.22
Connecting to ftp.club-internet.fr|194.158.99.22|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location:
http://mirrors-av.club-internet.fr/pub/mirrors/gentoo/distfiles/openss
h-lpk-4.3p1-0.3.7.patch [following]
--00:18:01--
http://mirrors-av.club-internet.fr/pub/mirrors/gentoo/distfiles/op
enssh-lpk-4.3p1-0.3.7.patch
=> `/usr/portage/distfiles/openssh-lpk-4.3p1-0.3.7.patch'
Resolving mirrors-av.club-internet.fr... 194.158.97.180
Connecting to mirrors-av.club-internet.fr|194.158.97.180|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 60,451 (59K) [text/plain]
100%[>] 60,451 161.77K/s
00:18:02 (161.37 KB/s) -
`/usr/portage/distfiles/openssh-lpk-4.3p1-0.3.7.patch'
saved [60451/60451]
>>> Resuming download...
>>> Downloading
ftp://212.219.56.132/sites/www.ibiblio.org/gentoo/distfiles/open
ssh-lpk-4.3p1-0.3.7.patch
--00:18:02--
ftp://212.219.56.132/sites/www.ibiblio.org/gentoo/distfiles/openss
h-lpk-4.3p1-0.3.7.patch
=> `/usr/portage/distfiles/openssh-lpk-4.3p1-0.3.7.patch'
Connecting to 212.219.56.132:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.==> PWD ... done.
==> TYPE I ... done. ==> CWD /sites/www.ibiblio.org/gentoo/distfiles ...
done.
==> SIZE openssh-lpk-4.3p1-0.3.7.patch ... done.
==> PASV ... done.==> REST 60451 ... done.
==> RETR openssh-lpk-4.3p1-0.3.7.patch ... done.
Length: 60,451 (59K), 0 (0) remaining
100%[+] 60,451--.--K/s
00:18:06 (0.00 B/s) - `/usr/portage/distfiles/openssh-lpk-4.3p1-0.3.7.patch'
saved [60451]
>>> Resuming download...
>>> Downloading
ftp://212.219.56.133/sites/www.ibiblio.org/gentoo/distfiles/open
ssh-lpk-4.3p1-0.3.7.patch
--00:18:06--
ftp://212.219.56.133/sites/www.ibiblio.org/gentoo/distfiles/openss
h-lpk-4.3p1-0.3.7.patch
=> `/usr/portage/distfiles/openssh-lpk-4.3p1-0.3.7.patch'
Connecting to 212.219.56.133:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.==> PWD ... done.
==> TYPE I ... done. ==> CWD /sites/www.ibiblio.org/gentoo/distfiles ...
done.
==> SIZE openssh-lpk-4.3p1-0.3.7.patch ... done.
==> PASV ... done.==> REST 60451 ... done.
==> RETR openssh-lpk-4.3p1-0.3.7.patch ... done.
Length: 60,451 (59K), 0 (0) remaining
100%[+] 60,451--.--K/s
00:18:11 (0.00 B/s) - `/usr/portage/distfiles/openssh-lpk-4.3p1-0.3.7.patch'
saved [60451]
>>> Resuming download...
>>> Downloading http://194.117.143.70/distfiles/openssh-lpk-4.3p1-0.3.7.patch
--00:18:11-- http://194.117.143.70/distfiles/openssh-lpk-4.3p1-0.3.7.patch
=> `/usr/portage/distfiles/openssh-lpk-4.3p1-0.3.7.patch'
Connecting to 194.117.143.70:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
00:18:11 ERROR 403: Forbidden.
>>> Resuming download...
>>> Downloading
ftp://212.219.56.134/sites/www.ibiblio.org/gentoo/distfiles/open
ssh-lpk-4.3p1-0.3.7.patch
--00:18:11--
ftp://212.219.56.134/sites/www.ibiblio.org/gentoo/distfiles/openss
h-lpk-4.3p1-0.3.7.patch
=> `/usr/portage/distfiles/openssh-lpk-4.3p1-0.3.7.patch'
Connecting to 212.219.56.134:21.
[gentoo-user] problems emerge'ing amavis-new
i get this when i try to emerge amavis-new: >>> Unpacking amavisd-new-2.3.3.tar.gz to /var/tmp/portage/amavisd-new-2.3.3-r2/work * Patching with qmail qmqp support. * Applying amavisd-new-qmqpqq.patch ... [ ok ] * Patching with qmail lf bug workaround. * Applying amavisd-new-2.2.1-qmail-lf-workaround.patch ... * Failed Patch: amavisd-new-2.2.1-qmail-lf-workaround.patch ! * ( /usr/portage/mail-filter/amavisd-new/files/amavisd-new-2.2.1-qmail-lf-workaround.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/amavisd-new-2.3.3-r2/temp/amavisd-new-2.2.1-qmail-lf-workaround.patch-28558.out !!! ERROR: mail-filter/amavisd-new-2.3.3-r2 failed. !!! Function epatch, Line 350, Exitcode 0 !!! Failed Patch: amavisd-new-2.2.1-qmail-lf-workaround.patch! !!! If you need support, post the topmost build error, NOT this status message. here is the contents of the .out file: [14:[EMAIL PROTECTED]:[/home/nick]# cat /var/tmp/portage/amavisd-new-2.3.3-r2/temp/amavisd-new-2.2.1-qmail-lf-workaround.patch-29392.out * amavisd-new-2.2.1-qmail-lf-workaround.patch * === PATCH COMMAND: patch -p0 -g0 --no-backup-if-mismatch < /usr/portage/mail-filter/amavisd-new/files/amavisd-new-2.2.1-qmail-lf-workaround.patch === can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |--- amavisd-new-2.2.1/amavisd.chris2005-01-09 18:05:09.0 +0100 |+++ amavisd-new-2.2.1/amavisd 2005-01-09 18:05:47.360864816 +0100 -- No file to patch. Skipping patch. 1 out of 1 hunk ignored === PATCH COMMAND: patch -p1 -g0 --no-backup-if-mismatch < /usr/portage/mail-filter/amavisd-new/files/amavisd-new-2.2.1-qmail-lf-workaround.patch === patching file amavisd Hunk #1 FAILED at 3948. 1 out of 1 hunk FAILED -- saving rejects to file amavisd.rej ======= PATCH COMMAND: patch -p2 -g0 --no-backup-if-mismatch < /usr/portage/mail-filter/amavisd-new/files/amavisd-new-2.2.1-qmail-lf-workaround.patch === missing header for unified diff at line 3 of patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |--- amavisd-new-2.2.1/amavisd.chris2005-01-09 18:05:09.0 +0100 |+++ amavisd-new-2.2.1/amavisd 2005-01-09 18:05:47.360864816 +0100 ------ No file to patch. Skipping patch. 1 out of 1 hunk ignored ======= PATCH COMMAND: patch -p3 -g0 --no-backup-if-mismatch < /usr/portage/mail-filter/amavisd-new/files/amavisd-new-2.2.1-qmail-lf-workaround.patch === missing header for unified diff at line 3 of patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |--- amavisd-new-2.2.1/amavisd.chris2005-01-09 18:05:09.0 +0100 |+++ amavisd-new-2.2.1/amavisd 2005-01-09 18:05:47.360864816 +0100 ------ No file to patch. Skipping patch. 1 out of 1 hunk ignored ======= PATCH COMMAND: patch -p4 -g0 --no-backup-if-mismatch < /usr/portage/mail-filter/amavisd-new/files/amavisd-new-2.2.1-qmail-lf-workaround.patch === missing header for unified diff at line 3 of patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |--- amavisd-new-2.2.1/amavisd.chris2005-01-09 18:05:09.0 +0100 |+++ amavisd-new-2.2.1/amavisd 2005-01-09 18:05:47.360864816 +0100 ------ No file to patch. Skipping patch. 1 out of 1 hunk ignored what do i need to do to correct this? TIA Nick -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] www-client/firefox-3.6.12 headers error
Apparently, though unproven, at 20:45 on Friday 29 October 2010, Mick did opine thusly: > I noticed this error with the autoheader as shown below: > > * Applying xulrunner-1.9.2-gtk+-2.21.patch ... [ > ok ] * Running eautoreconf in '/var/tmp/portage/www- > client/firefox-3.6.12/work/mozilla-1.9.2' ... > * Running autoconf ... [ > ok ] * Running autoheader ... > [ !! ] You don't mention the version. With that firefox, I assume xulrunner-1.9.2.12 right? I'm running that here on amd64 too and it all works fine. If it breaks something, it's not visible to me at this point. > * Running elibtoolize in: > mozilla-1.9.2/ipc/chromium/src/third_party/libevent/ > * Applying install-sh-1.5.patch ... > * Applying portage-1.5.10.patch ... > * Applying sed-1.5.6.patch ... > * Applying as-needed-1.5.26.patch ... > * Running elibtoolize in: mozilla-1.9.2/js/ctypes/libffi/ > * Applying install-sh-1.5.4.patch ... > * Applying portage-1.5.10.patch ... > * Applying sed-1.5.6.patch ... > * Applying as-needed-1.5.26.patch ... > * Applying uclibc-ltconf-1.3.0.patch ... > * Running elibtoolize in: mozilla-1.9.2/modules/freetype2/builds/unix/ > * Applying portage-2.2.patch ... > * Applying sed-1.5.6.patch ... > * Applying as-needed-2.2.6.patch ... > * Running elibtoolize in: mozilla-1.9.2/toolkit/crashreporter/google- > breakpad/autotools/ > * Applying portage-2.2.patch ... > * Applying sed-1.5.6.patch ... > * Applying as-needed-2.2.6.patch ... > * Running eautoreconf in '/var/tmp/portage/www- > client/firefox-3.6.12/work/mozilla-1.9.2/js/src' ... > * Running autoconf ... [ > ok ] * Running autoheader ... > [ !! ] > > >>> Source prepared. > > This is an amd64 box. I can't recall seeing the same on a x86 machine > earlier in the week - but may have just missed it. > > Is it important? -- alan dot mckinnon at gmail dot com
[gentoo-user] Firefox 3.0.12 emerge dies
I've been unsuccessfully trying to build the latest security patch
version of Firefox 3.0. I keep getting the same error message after
3 days of re-syncing and retrying. The build dies early on in the
patch-appliaction stage, so log.txt is small. The error message also
mentioned to include the contents of the patch ".out" file, which I have
done as log2.txt. Any ideas?
--
Walter Dnes
[32;01m*[0m You are enabling official branding. You may not redistribute
this build
[32;01m*[0m to any users on your network or the internet. Doing so puts
yourself into
[32;01m*[0m a legal problem with Mozilla Foundation
[32;01m*[0m You can disable it by emerging mozilla-firefox _with_ the
bindist USE-flag
>>> Unpacking source...
>>> Unpacking xulrunner-1.9.0.12.tar.bz2 to
>>> /var/tmp/portage/www-client/mozilla-firefox-3.0.12/work
>>> Unpacking mozilla-firefox-3.0.12.tar.bz2 to
>>> /var/tmp/portage/www-client/mozilla-firefox-3.0.12/work
>>> Unpacking mozilla-firefox-3.0.12-patches-0.1.tar.bz2 to
>>> /var/tmp/portage/www-client/mozilla-firefox-3.0.12/work
>>> Source unpacked in /var/tmp/portage/www-client/mozilla-firefox-3.0.12/work
>>> Preparing source in
>>> /var/tmp/portage/www-client/mozilla-firefox-3.0.12/work/mozilla ...
[32;01m*[0m Applying various patches (bugfixes/updates) ...
[32;01m*[0m 000_flex-configure-LANG.patch ...
[A[72C [34;01m[ [32;01mok[34;01m ][0m
[32;01m*[0m 001-firefox_gentoo_install_dirs.patch ...
[A[72C [34;01m[ [32;01mok[34;01m ][0m
[32;01m*[0m 003-bz386904_config_rules_install_dist_files.patch ...
[A[72C [34;01m[ [32;01mok[34;01m ][0m
[32;01m*[0m 005-installer_shouldnt_copy_xulrunner.patch ...
[A[72C [34;01m[ [32;01mok[34;01m ][0m
[32;01m*[0m 020_noxul-mips-asm.patch ...
[A[72C [34;01m[ [32;01mok[34;01m ][0m
[32;01m*[0m 021_noxul-mips-fpic.patch ...
[A[72C [34;01m[ [32;01mok[34;01m ][0m
[32;01m*[0m 030-firefox_encode_spaces.patch ...
[A[72C [34;01m[ [32;01mok[34;01m ][0m
[32;01m*[0m 055_firefox-2.0_gfbsd-pthreads.patch ...
[A[72C [34;01m[ [32;01mok[34;01m ][0m
[32;01m*[0m 063_firefox-rpath-3.patch ...
[A[72C [34;01m[ [32;01mok[34;01m ][0m
[32;01m*[0m 064_noxul-nsplugins-v3.patch ...
[A[72C [34;01m[ [32;01mok[34;01m ][0m
[32;01m*[0m 068_noxul-nss-gentoo-fix.patch ...
[A[72C [34;01m[ [32;01mok[34;01m ][0m
[32;01m*[0m 085-arm-gcc42.patch ...
[A[72C [34;01m[ [32;01mok[34;01m ][0m
[32;01m*[0m 090-unaligned.patch ...
[A[72C [34;01m[ [32;01mok[34;01m ][0m
[32;01m*[0m 097_noxul_glibc-maxpathlen.patch ...
[31;01m*[0m Failed Patch: 097_noxul_glibc-maxpathlen.patch !
[31;01m*[0m (
/var/tmp/portage/www-client/mozilla-firefox-3.0.12/work/patch/097_noxul_glibc-maxpathlen.patch
)
[31;01m*[0m
[31;01m*[0m Include in your bugreport the contents of:
[31;01m*[0m
[31;01m*[0m
/var/tmp/portage/www-client/mozilla-firefox-3.0.12/temp/097_noxul_glibc-maxpathlen.patch-6570.out
[31;01m*[0m
[31;01m*[0m ERROR: www-client/mozilla-firefox-3.0.12 failed.
[31;01m*[0m Call stack:
[31;01m*[0m ebuild.sh, line 49: Called src_prepare
[31;01m*[0m environment, line 3291: Called epatch
'/var/tmp/portage/www-client/mozilla-firefox-3.0.12/work/patch'
[31;01m*[0m environment, line 1747: Called die
[31;01m*[0m The specific snippet of code:
[31;01m*[0m die "Failed Patch: ${patchname}!";
[31;01m*[0m The die message:
[31;01m*[0m Failed Patch: 097_noxul_glibc-maxpathlen.patch!
[31;01m*[0m
[31;01m*[0m If you need support, post the topmost build error, and the call
stack if relevant.
[31;01m*[0m A complete build log is located at
'/var/log/portage/www-client:mozilla-firefox-3.0.12:20090726-200847.log'.
[31;01m*[0m The ebuild environment file is located at
'/var/tmp/portage/www-client/mozilla-firefox-3.0.12/temp/environment'.
[31;01m*[0m
* 097_noxul_glibc-maxpathlen.patch *
====
PATCH COMMAND: patch -p0 -g0 -E --no-backup-if-mismatch <
/var/tmp/portage/www-client/mozilla-firefox-3.0.12/work/patch/097_noxul_glibc-maxpathlen.patch
patching file xpcom/build/nsXPCOMPrivate.h
Hunk #1 FAILED at 231.
1 out of 1 hunk FAILED -- saving rejects to file
xpcom/build/nsXPCOMPrivate.h.rej
====
PATCH COMMAND: patch -p1 -g0 -E --no-backup-if-mismatch <
/var/tmp/portage/www-client/mozilla-firefox-3.0.12/work/patch/097_noxul_glibc-maxpathlen.patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
[gentoo-user] Re: problems emerge'ing amavis-new
its been a couple weeks since i posted this, figured i would wait and see if this fixed itself and it hasnt, has any one got any ideas as to why im getting this error or where to start to fix it? thanks nick On 3/10/06, Nick Smith <[EMAIL PROTECTED]> wrote: > i get this when i try to emerge amavis-new: > > >>> Unpacking amavisd-new-2.3.3.tar.gz to > /var/tmp/portage/amavisd-new-2.3.3-r2/work > * Patching with qmail qmqp support. > * Applying amavisd-new-qmqpqq.patch ... > > [ ok ] > * Patching with qmail lf bug workaround. > * Applying amavisd-new-2.2.1-qmail-lf-workaround.patch ... > > * Failed Patch: amavisd-new-2.2.1-qmail-lf-workaround.patch ! > * ( > /usr/portage/mail-filter/amavisd-new/files/amavisd-new-2.2.1-qmail-lf-workaround.patch > ) > * > * Include in your bugreport the contents of: > * > * > /var/tmp/portage/amavisd-new-2.3.3-r2/temp/amavisd-new-2.2.1-qmail-lf-workaround.patch-28558.out > > > !!! ERROR: mail-filter/amavisd-new-2.3.3-r2 failed. > !!! Function epatch, Line 350, Exitcode 0 > !!! Failed Patch: amavisd-new-2.2.1-qmail-lf-workaround.patch! > !!! If you need support, post the topmost build error, NOT this status > message. > > here is the contents of the .out file: > > > [14:[EMAIL PROTECTED]:[/home/nick]# cat > /var/tmp/portage/amavisd-new-2.3.3-r2/temp/amavisd-new-2.2.1-qmail-lf-workaround.patch-29392.out > ***** amavisd-new-2.2.1-qmail-lf-workaround.patch * > > === > > PATCH COMMAND: patch -p0 -g0 --no-backup-if-mismatch < > /usr/portage/mail-filter/amavisd-new/files/amavisd-new-2.2.1-qmail-lf-workaround.patch > > === > can't find file to patch at input line 3 > Perhaps you used the wrong -p or --strip option? > The text leading up to this was: > -- > |--- amavisd-new-2.2.1/amavisd.chris2005-01-09 18:05:09.0 +0100 > |+++ amavisd-new-2.2.1/amavisd 2005-01-09 18:05:47.360864816 +0100 > ------ > No file to patch. Skipping patch. > 1 out of 1 hunk ignored > > === > > PATCH COMMAND: patch -p1 -g0 --no-backup-if-mismatch < > /usr/portage/mail-filter/amavisd-new/files/amavisd-new-2.2.1-qmail-lf-workaround.patch > > ======= > patching file amavisd > Hunk #1 FAILED at 3948. > 1 out of 1 hunk FAILED -- saving rejects to file amavisd.rej > === > > PATCH COMMAND: patch -p2 -g0 --no-backup-if-mismatch < > /usr/portage/mail-filter/amavisd-new/files/amavisd-new-2.2.1-qmail-lf-workaround.patch > > === > missing header for unified diff at line 3 of patch > can't find file to patch at input line 3 > Perhaps you used the wrong -p or --strip option? > The text leading up to this was: > -- > |--- amavisd-new-2.2.1/amavisd.chris2005-01-09 18:05:09.00000 +0100 > |+++ amavisd-new-2.2.1/amavisd 2005-01-09 18:05:47.360864816 +0100 > -- > No file to patch. Skipping patch. > 1 out of 1 hunk ignored > ======= > > PATCH COMMAND: patch -p3 -g0 --no-backup-if-mismatch < > /usr/portage/mail-filter/amavisd-new/files/amavisd-new-2.2.1-qmail-lf-workaround.patch > > === > missing header for unified diff at line 3 of patch > can't find file to patch at input line 3 > Perhaps you used the wrong -p or --strip option? > The text leading up to this was: > -- > |--- amavisd-new-2.2.1/amavisd.chris2005-01-09 18:05:09.0 +0100 > |+++ amavisd-new-2.2.1/amavisd 2005-01-09 18:05:47.360864816 +0100 > -- > No file to patch. Skipping patch. > 1 out of 1 hunk ignored > === > > PATCH COMMAND: patch -p4 -g0 --no-backup-if-mismatch < > /usr/portage/mail-filter/amavisd-new/files/amavisd-new-2.2.1-qmail-lf-workaround.patch > > === > missing header for unified diff at line 3 of patch > can't find file to patch at input line 3 > Perhaps you used the wrong -p or --strip option? > The text leading up to this was: > -- > |--- amavisd-new-2.2.1/amavisd.chris2005-01-09 18:05:09.0 +0100 > |+++ amavisd-new-2.2.1/amavisd 2005-01-09 18:05:47.360864816 +0100 > -- > No file to patch. Skipping patch. > 1 out of 1 hunk ignored > > > what do i need to do to correct this? > > TIA > > Nick > -- Linux, because I'd rather own a free OS than steal one that's not worth paying for. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: Patch via perl script in an ebuild?
On 7/1/10, Grant wrote:
> Thank you Arttu. Here is the link to the SOAP::WSDL:
>
> http://soap-wsdl.svn.sourceforge.net/viewvc/soap-wsdl/SOAP-WSDL/branches/Typemap.tar.gz?view=tar&pathrev=846
>
> from the README:
>
> http://code.google.com/p/google-api-adwords-perl/source/browse/trunk/README
Ok, I see they're shipping the same version which is available from
CPAN as the dev version (2.00.99_3). But the patch is still not made
for its code ... maybe it is for _2 or _1?
The patch keeps failing out of the box:
cpan -i Text::Patch
tar xvzf Typemap.tar.gz
tar xvzf awapi_perl_lib_1.3.2.tar.gz
~/tempski $ awapi_perl_lib_1.3.2/bin/soap_wsdl_patches.pl Typemap
Trying to patch
Typemap/lib/SOAP/WSDL/Generator/Template/XSD/Interface/POD/Operation.tt...
patch successful.
Trying to patch
Typemap/lib/SOAP/WSDL/Generator/Template/XSD/Server.tt... patch
successful.
Trying to patch
Typemap/lib/SOAP/WSDL/Generator/Template/Plugin/XSD.pm... patch
successful.
Trying to patch
Typemap/lib/SOAP/WSDL/XSD/Typelib/Builtin/anyType.pm... patch
successful.
Trying to patch
Typemap/lib/SOAP/WSDL/XSD/Typelib/ComplexType.pm...Hunk #2 failed at
line 425.
~/tempski $
Anyway, only three files' small chunks fail from the patch, and
they're short and mostly just semantically adding some formerly
non-existent subroutines and changing the return values of others.
I think with some manual labour we could turn that patch into a fixed
regular patch, which we could then apply in an ebuild for SOAP::WSDL
via a USE flag. For example, something along these lines for
dev-perl/SOAP-WSDL-2.00.99.3.ebuild (licenses etc might be wrong):
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
EAPI=2
MODULE_AUTHOR=MKUTTER
MY_P="${P:0:17}_3"
inherit eutils perl-module
DESCRIPTION="SOAP::WSDL module"
LICENSE="Artistic"
SLOT="0"
KEYWORDS="amd64 x86"
IUSE="adwords"
src_prepare() {
perl-module_src_prepare
use adwords && epatch "${FILESDIR}/${PV}-adwords.patch"
}
This SOAP-WSDL package could then in turn be made a dependency for
your real google-adwords package (dev-perl/Google-Adwords?):
RDEPENDS="dev-perl/SOAP-WSDL[adwords]"
Am I making any sense?
Theoretically (if you insist), you could still use the perl's
Text::Patch route as well, but (if I'm not entirely wrong, see the
excerpted attempted patch run above) the patch would still need to be
touched up to match properly with the _3 dev release code. And it
would add a dependency to Text::Patch, and make an odd call to perl in
the middle of the ebuild. (I assume it must be made explicitly as I
don't know if perl-module.eclass has any automation for this. Probably
not since AFAICT Text::Patch isn't even installed by default).
HTH
--
Arttu V. -- Running Gentoo is like running with scissors
Re: [gentoo-user] Re: Patch via perl script in an ebuild?
[snip] > Am I making any sense? I think all of that is right on. I need to find out why the patch isn't working though. > Theoretically (if you insist), you could still use the perl's > Text::Patch route as well, but (if I'm not entirely wrong, see the > excerpted attempted patch run above) the patch would still need to be > touched up to match properly with the _3 dev release code. And it > would add a dependency to Text::Patch, and make an odd call to perl in > the middle of the ebuild. (I assume it must be made explicitly as I > don't know if perl-module.eclass has any automation for this. Probably > not since AFAICT Text::Patch isn't even installed by default). Do you think it would be better to create a real patch than to use the perl patch (after we figure out why it isn't working)? I would think it would be easier to use the perl patch in case a different version is released so we don't have to re-create the patch each time. A Text::Patch dep wouldn't be so bad. What do you think? - Grant
Re: [gentoo-user] Re: Patch via perl script in an ebuild?
On Thu, Jul 1, 2010 at 2:40 PM, Arttu V. wrote:
> On 7/1/10, Grant wrote:
>> Thank you Arttu. Here is the link to the SOAP::WSDL:
>>
>> http://soap-wsdl.svn.sourceforge.net/viewvc/soap-wsdl/SOAP-WSDL/branches/Typemap.tar.gz?view=tar&pathrev=846
>>
>> from the README:
>>
>> http://code.google.com/p/google-api-adwords-perl/source/browse/trunk/README
>
> Ok, I see they're shipping the same version which is available from
> CPAN as the dev version (2.00.99_3). But the patch is still not made
> for its code ... maybe it is for _2 or _1?
>
> The patch keeps failing out of the box:
>
> cpan -i Text::Patch
> tar xvzf Typemap.tar.gz
> tar xvzf awapi_perl_lib_1.3.2.tar.gz
> ~/tempski $ awapi_perl_lib_1.3.2/bin/soap_wsdl_patches.pl Typemap
> Trying to patch
> Typemap/lib/SOAP/WSDL/Generator/Template/XSD/Interface/POD/Operation.tt...
> patch successful.
> Trying to patch
> Typemap/lib/SOAP/WSDL/Generator/Template/XSD/Server.tt... patch
> successful.
> Trying to patch
> Typemap/lib/SOAP/WSDL/Generator/Template/Plugin/XSD.pm... patch
> successful.
> Trying to patch
> Typemap/lib/SOAP/WSDL/XSD/Typelib/Builtin/anyType.pm... patch
> successful.
> Trying to patch
> Typemap/lib/SOAP/WSDL/XSD/Typelib/ComplexType.pm...Hunk #2 failed at
> line 425.
> ~/tempski $
>
> Anyway, only three files' small chunks fail from the patch, and
> they're short and mostly just semantically adding some formerly
> non-existent subroutines and changing the return values of others.
>
> I think with some manual labour we could turn that patch into a fixed
> regular patch, which we could then apply in an ebuild for SOAP::WSDL
> via a USE flag. For example, something along these lines for
> dev-perl/SOAP-WSDL-2.00.99.3.ebuild (licenses etc might be wrong):
>
> # Copyright 1999-2010 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Header: $
>
> EAPI=2
>
> MODULE_AUTHOR=MKUTTER
> MY_P="${P:0:17}_3"
> inherit eutils perl-module
>
> DESCRIPTION="SOAP::WSDL module"
>
> LICENSE="Artistic"
> SLOT="0"
> KEYWORDS="amd64 x86"
> IUSE="adwords"
>
> src_prepare() {
> perl-module_src_prepare
> use adwords && epatch "${FILESDIR}/${PV}-adwords.patch"
> }
>
>
> This SOAP-WSDL package could then in turn be made a dependency for
> your real google-adwords package (dev-perl/Google-Adwords?):
>
> RDEPENDS="dev-perl/SOAP-WSDL[adwords]"
>
> Am I making any sense?
>
> Theoretically (if you insist), you could still use the perl's
> Text::Patch route as well, but (if I'm not entirely wrong, see the
> excerpted attempted patch run above) the patch would still need to be
> touched up to match properly with the _3 dev release code. And it
> would add a dependency to Text::Patch, and make an odd call to perl in
> the middle of the ebuild. (I assume it must be made explicitly as I
> don't know if perl-module.eclass has any automation for this. Probably
> not since AFAICT Text::Patch isn't even installed by default).
>
> HTH
>
> --
> Arttu V. -- Running Gentoo is like running with scissors
>
>
I was thinking along the same lines, my use was "google"
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
EAPI="3"
inherit perl-module
DESCRIPTION="SOAP-WSDL provides a SOAP client with WSDL support."
HOMEPAGE="http://soap-wsdl.svn.sourceforge.net";
SRC_URI="http://soap-wsdl.svn.sourceforge.net/viewvc/soap-wsdl/SOAP-WSDL/branches/Typemap.tar.gz
-> ${P}.tar.gz"
LICENSE="Apache-2.0"
SLOT="0"
KEYWORDS="~amd64 ~x86"
IUSE="google"
DEPEND="${RDEPEND}
virtual/perl-Module-Build"
RDEPEND="dev-perl/SOAP-Lite
dev-perl/Class-Std-Fast"
src_prepare() {
if use google ; then
epatch "${FILESDIR}/${PN}.patch" | die "google patch failed"
fi
}
--
David Abbott (dabbott)
Re: [gentoo-user] Patching of ebuilds
Also check the page where you found the patch carefully. Sometimes you can find an updated ebuild that works with that patch in the same page, so you don't have to patch it yourself. You need to examine the patch and clear up whether it's a patch for the app or for the ebuild itself. If it's a patch for the ebuild you just need to copy the ebuild into an overlay and patch it. But if it's a patch for the app you need to modify the ebuild so it applies the patch to the app after unpacking it and before compiling. This is the official documentation about how to correctly alter the portage tree so you don't mess up anything. Either way you need to create an overlay. That's for sure. http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=5 -- Jesús Guerrero
[gentoo-user] thunar won't build?
What am I doing wrong? # emerge thunar Calculating dependencies... done! >>> Emerging (1 of 1) xfce-base/thunar-0.8.0-r2 to / * Thunar-0.8.0.tar.bz2 MD5 ;-) ... [ ok ] * Thunar-0.8.0.tar.bz2 RMD160 ;-) ... [ ok ] * Thunar-0.8.0.tar.bz2 SHA1 ;-) ... [ ok ] * Thunar-0.8.0.tar.bz2 SHA256 ;-) ... [ ok ] * Thunar-0.8.0.tar.bz2 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking Thunar-0.8.0.tar.bz2 ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking Thunar-0.8.0.tar.bz2 to /home/tmp/portage/xfce-base/thunar-0.8.0-r2/work * Applying thunar-0.8.0-jpeg.patch ... * Failed Patch: thunar-0.8.0-jpeg.patch ! * ( /usr/portage/xfce-base/thunar/files/thunar-0.8.0-jpeg.patch ) * * Include in your bugreport the contents of: * * /home/tmp/portage/xfce-base/thunar-0.8.0-r2/temp/thunar-0.8.0-jpeg.patch-30744.out !!! ERROR: xfce-base/thunar-0.8.0-r2 failed. Call stack: ebuild.sh, line 1614: Called dyn_unpack ebuild.sh, line 751: Called qa_call 'src_unpack' environment, line 3119: Called src_unpack thunar-0.8.0-r2.ebuild, line 68: Called epatch '/usr/portage/xfce-base/thunar/files/thunar-0.8.0-jpeg.patch' eutils.eclass, line 341: Called die !!! Failed Patch: thunar-0.8.0-jpeg.patch! !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/home/tmp/portage/xfce-base/thunar-0.8.0-r2/temp/build.log'. Here's what's in /home/tmp/portage/xfce-base/thunar-0.8.0-r2/temp/thunar-0.8.0-jpeg.patch-30744.out: * thunar-0.8.0-jpeg.patch * === PATCH COMMAND:patch -p0 -g0 -E --no-backup-if-mismatch < /usr/portage/xfce-base/thunar/files/thunar-0.8.0-jpeg.patch === can't find file to patch at input line 4 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |diff -ur Thunar-0.8.0.orig/thunar-vfs/thunar-vfs-thumb-jpeg.c Thunar-0.8.0/thunar-vfs/thunar-vfs-thumb-jpeg.c |--- Thunar-0.8.0.orig/thunar-vfs/thunar-vfs-thumb-jpeg.c2007-01-20 22:39:09.0 +0200 |+++ Thunar-0.8.0/thunar-vfs/thunar-vfs-thumb-jpeg.c 2007-02-12 20:16:29.00000 +0200 -- No file to patch. Skipping patch. 9 out of 9 hunks ignored === PATCH COMMAND:patch -p1 -g0 -E --no-backup-if-mismatch < /usr/portage/xfce-base/thunar/files/thunar-0.8.0-jpeg.patch === patching file thunar-vfs/thunar-vfs-thumb-jpeg.c Hunk #1 FAILED at 1. 1 out of 9 hunks FAILED -- saving rejects to file thunar-vfs/thunar-vfs-thumb-jpeg.c.rej === PATCH COMMAND:patch -p2 -g0 -E --no-backup-if-mismatch < /usr/portage/xfce-base/thunar/files/thunar-0.8.0-jpeg.patch === can't find file to patch at input line 4 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |diff -ur Thunar-0.8.0.orig/thunar-vfs/thunar-vfs-thumb-jpeg.c Thunar-0.8.0/thunar-vfs/thunar-vfs-thumb-jpeg.c |--- Thunar-0.8.0.orig/thunar-vfs/thunar-vfs-thumb-jpeg.c2007-01-20 22:39:09.0 +0200 |+++ Thunar-0.8.0/thunar-vfs/thunar-vfs-thumb-jpeg.c 2007-02-12 20:16:29.0 +0200 -- No file to patch. Skipping patch. 9 out of 9 hunks ignored === PATCH COMMAND:patch -p3 -g0 -E --no-backup-if-mismatch < /usr/portage/xfce-base/thunar/files/thunar-0.8.0-jpeg.patch ======= missing header for unified diff at line 4 of patch can't find file to patch at input line 4 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |diff -ur Thunar-0.8.0.orig/thunar-vfs/thunar-vfs-thumb-jpeg.c Thunar-0.8.0/thunar-vfs/thunar-vfs-thumb-jpeg.c
Re: [gentoo-user] "xyz.la seems to be moved" message
From: Michael Sullivan <[EMAIL PROTECTED]> Subject: Re: [gentoo-user] "xyz.la seems to be moved" message Date: Tue, 24 Oct 2006 11:24:31 -0500 > On Tue, 2006-10-24 at 17:31 +0200, Fabrice Delliaux wrote: > > Hi, > > > > Explanation && patch here : > > > > http://www.mail-archive.com/bug-libtool@gnu.org/msg00838.html > > I saved the patch at the above link to /root/libtool.patch, but I can't > figure out how to use it. I assume that I would need to navigate to a > directory and say "patch < /root/libtool.patch", but what directory do I > do it from? If I do it from /usr/share/libtool, I get this: > > camille libtool # patch patching file ltmain.sh > Hunk #1 FAILED at 2795. > 1 out of 1 hunk FAILED -- saving rejects to file ltmain.sh.rej > > If I do it from /, I get this: > > camille / # patch can't find file to patch at input line 3 > Perhaps you should have used the -p or --strip option? > The text leading up to this was: > -- > |--- /usr/share/libtool/ltmain.sh2005-11-22 08:18:02.0 -0500 > |+++ ltmain.sh2006-05-13 18:15:15.0 -0400 > -- > File to patch: > > > -- > gentoo-user@gentoo.org mailing list > Hi Michael, I applied the patch by hand, my be it will work with the patch-command too. If you want to try it: cd /usr/share/libtool/. and apply the patch there with patch -p0 -i If it does not work for you, please email me, I will send you the laready patched ltmain.sh attached to a private mail. Keep hacking! mcc -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Compilation error with StructureSynth
On 11/01 11:03, David Haller wrote:
> Hello Meino,
>
> On Wed, 01 Nov 2017, tu...@posteo.de wrote:
> [..]
> >But it seems, that I am doing something wrong with the local
> >overlay...
>
> I assumed you already have one. If not, drop this into your
> /etc/portage/repos.conf/ directory as e.g. local.conf:
>
> /etc/portage/repos.conf/local.conf
> [local]
> location = /usr/local/portage
> masters = gentoo
> auto-sync = no
> priority = 99
>
>
> Or, if you have a _FILE_ /etc/portage/repos.conf, add the above
> snippet as a new section in there.
>
> And create /usr/local/portage.
>
> >I copied (as root)
> >
> >cp -a /usr/portage/media-gfx/structur-synth /usr/local/portage/media-gfx/.
>
> Did you create /usr/local/portage/media-gfx/ before?
>
> Clean up /usr/local/portage/media-gfx first, then use:
>
> # mkdir -p /usr/local/portage/media-gfx/
> # cp -va /usr/portage/media-gfx/structure-synth \
> /usr/local/portage/media-gfx/
>
> Depending on your umask, you might need to make stuff explicitly
> readable for or owned by the user "portage" (usually).
>
> # chown -cR portage.portage /usr/local/portage/
>
> Anyway, this should get you a structure like:
>
> /usr/local/portage/media-gfx/structure-synth/
> /usr/local/portage/media-gfx/structure-synth/metadata.xml
> /usr/local/portage/media-gfx/structure-synth/structure-synth-1.5.0.ebuild
> /usr/local/portage/media-gfx/structure-synth/Manifest
>
> Then:
>
> # mkdir /usr/local/portage/media-gfx/structure-synth/files
>
> drop my '.patch' into that ./files/ dir, drop my -r1.ebuild into
> /usr/local/portage/media-gfx/structure-synth/
>
> and run:
>
> # pushd /usr/local/portage/media-gfx/structure-synth/
> # repoman -v manifest
> # popd
>
> (I forgot that step in my first mail)
>
> It should look like this then:
>
> /usr/local/portage/media-gfx/structure-synth/
> /usr/local/portage/media-gfx/structure-synth/structure-synth-1.5.0.ebuild
> /usr/local/portage/media-gfx/structure-synth/structure-synth-1.5.0-r1.ebuild
> /usr/local/portage/media-gfx/structure-synth/files
> /usr/local/portage/media-gfx/structure-synth/files/structure-synth-1.5.0-gl.patch
> /usr/local/portage/media-gfx/structure-synth/metadata.xml
> /usr/local/portage/media-gfx/structure-synth/Manifest
>
> (actually, you could prune the structure-synth-1.5.0.ebuild file,
> update the manifest again if you do).
>
> >then
> >
> >eix structure-synth
> >
> >* media-gfx/structure-synth
> > Available versions: (~)1.5.0
> > Homepage:http://structuresynth.sourceforge.net/
> > Description: A program to generate 3D structures by specifying
> > a design grammar
> >
> >so no *-r1 version visible.
>
> Did you run 'eix-update'??? *nudge* *nudge*
>
> Anyway: even without eix-update and eix not showing stuff,
>
> # emerge --pretend --nodeps media-gfx/structure-synth
>
> should show that it'd build media-gfx/structure-synth-1.5.0-r1::local
>
> (unless I forgot something about initializing a local overlay, it's
> been a while).
>
> >layman -l does not show up structure-synth
>
> That lists overlays. Not packages inside them.
>
> >Then I tried different permutations of "media-gfx" (w/o) and
> >structur-synth in combination with layman -a in desperation ;)
> >no success
>
> layman and your local overlay have nothing to do with each other.
> layman is "just" a tool to easily add/remove "external" public
> overlays. And eix-layman to add/remove them to/from your local
> 'eix'-DB and what is considered "local" ('eix' vs. 'eix -R').
>
> [..]
> >So I think, that the layman engine is working correctly so far.
> >But the driver behind the steering wheels needs some instructions it
> >seems ;)
> >Where can I get my license?
>
> In the handbook, IIRC :) I did read that about a local overlay in the
> official docs somewhere (and my local overlay is over 100 pkgs ;)
>
> PS: I wonder how that ebuild got into the portage-tree ... Maybe some
> weird configs present or absent in the qt4/qmake stuff about opengl...
>
> I found that 'QMAKE_LIBS_OPENGL="-lGL"' thingy I added (with the
> missing '-lGLU') to the ebuild in the qmake config files in
> /usr/share/qt4/... I hate qmake (and just about every other build
> system[1]).
>
> Ask, if stuff is still unclear. And read up a bit again on overlays
> and layman ;)
>
> HTH,
> -dnh
>
> [1] had a
Re: [gentoo-user] "xyz.la seems to be moved" message
On Tue, 2006-10-24 at 18:34 +0200, Meino Christian Cramer wrote: > From: Michael Sullivan <[EMAIL PROTECTED]> > Subject: Re: [gentoo-user] "xyz.la seems to be moved" message > Date: Tue, 24 Oct 2006 11:24:31 -0500 > > > On Tue, 2006-10-24 at 17:31 +0200, Fabrice Delliaux wrote: > > > Hi, > > > > > > Explanation && patch here : > > > > > > http://www.mail-archive.com/bug-libtool@gnu.org/msg00838.html > > > > I saved the patch at the above link to /root/libtool.patch, but I can't > > figure out how to use it. I assume that I would need to navigate to a > > directory and say "patch < /root/libtool.patch", but what directory do I > > do it from? If I do it from /usr/share/libtool, I get this: > > > > camille libtool # patch > patching file ltmain.sh > > Hunk #1 FAILED at 2795. > > 1 out of 1 hunk FAILED -- saving rejects to file ltmain.sh.rej > > > > If I do it from /, I get this: > > > > camille / # patch > can't find file to patch at input line 3 > > Perhaps you should have used the -p or --strip option? > > The text leading up to this was: > > -- > > |--- /usr/share/libtool/ltmain.sh2005-11-22 08:18:02.00000 -0500 > > |+++ ltmain.sh2006-05-13 18:15:15.0 -0400 > > -- > > File to patch: > > > > > > -- > > gentoo-user@gentoo.org mailing list > > > > Hi Michael, > > I applied the patch by hand, my be it will work with the > patch-command too. > > If you want to try it: > cd /usr/share/libtool/. and apply the patch there with > >patch -p0 -i > > If it does not work for you, please email me, I will send you the > laready patched ltmain.sh attached to a private mail. > > Keep hacking! > mcc > I think I'm doing it wrong: camille libtool # patch -p0 -i /root/libtool.patch patching file ltmain.sh Hunk #1 FAILED at 2795. 1 out of 1 hunk FAILED -- saving rejects to file ltmain.sh.rej -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] korganizer patch
Michael W. Holdeman wrote:
> OK,
> So what is wrong with this patch:
What is the error message? :)
What I normally do is: unpack the affected tarball, copy the
affected files to .orig versions, make the necessary changes,
create a patch from above the topdir with 'diff -u' between the
orig files and the changed files, stick that patch in the
${FILESDIR} in the overlay, and add its name to PATCHES.
The patch you show isn't one created with 'diff -u', 'patch' may
simply not recognize it.
Benno
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] "xyz.la seems to be moved" message
From: Michael Sullivan <[EMAIL PROTECTED]> Subject: Re: [gentoo-user] "xyz.la seems to be moved" message Date: Tue, 24 Oct 2006 14:43:37 -0500 > On Tue, 2006-10-24 at 18:34 +0200, Meino Christian Cramer wrote: > > From: Michael Sullivan <[EMAIL PROTECTED]> > > Subject: Re: [gentoo-user] "xyz.la seems to be moved" message > > Date: Tue, 24 Oct 2006 11:24:31 -0500 > > > > > On Tue, 2006-10-24 at 17:31 +0200, Fabrice Delliaux wrote: > > > > Hi, > > > > > > > > Explanation && patch here : > > > > > > > > http://www.mail-archive.com/bug-libtool@gnu.org/msg00838.html > > > > > > I saved the patch at the above link to /root/libtool.patch, but I can't > > > figure out how to use it. I assume that I would need to navigate to a > > > directory and say "patch < /root/libtool.patch", but what directory do I > > > do it from? If I do it from /usr/share/libtool, I get this: > > > > > > camille libtool # patch > > patching file ltmain.sh > > > Hunk #1 FAILED at 2795. > > > 1 out of 1 hunk FAILED -- saving rejects to file ltmain.sh.rej > > > > > > If I do it from /, I get this: > > > > > > camille / # patch > > can't find file to patch at input line 3 > > > Perhaps you should have used the -p or --strip option? > > > The text leading up to this was: > > > ------ > > > |--- /usr/share/libtool/ltmain.sh 2005-11-22 08:18:02.0 -0500 > > > |+++ ltmain.sh2006-05-13 18:15:15.00000 -0400 > > > -- > > > File to patch: > > > > > > > > > -- > > > gentoo-user@gentoo.org mailing list > > > > > > > Hi Michael, > > > > I applied the patch by hand, my be it will work with the > > patch-command too. > > > > If you want to try it: > > cd /usr/share/libtool/. and apply the patch there with > > > >patch -p0 -i > > > > If it does not work for you, please email me, I will send you the > > laready patched ltmain.sh attached to a private mail. > > > > Keep hacking! > > mcc > > > > I think I'm doing it wrong: > > camille libtool # patch -p0 -i /root/libtool.patch > patching file ltmain.sh > Hunk #1 FAILED at 2795. > 1 out of 1 hunk FAILED -- saving rejects to file ltmain.sh.rej > > > -- > gentoo-user@gentoo.org mailing list > Hi Michael, ...no, you did nothing wrong... "...hunk FAILED..." means: The file to be patched is to different from that one, from which the original patch was made. There is another way: As root edit /usr/share/libtool/ltmain.sh by hand (I did the same): In the file search for the string "seems to be moved" and then compare the context of that line with the text of the patch: There is one line to be removed and I think four or so to be added. Notging too complicate. Make a backup copy of ltmain.sh before. Make a diff afterwards and compare the output with the patch. If all fails: Mail me privately and we will find a solution. Keep hacking! mcc -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] zd1211 patch?
On Tue, 8 May 2007 17:22:32 +0200
Alan McKinnon wrote:
Hi!
> On Tuesday 08 May 2007, Arnau Bria wrote:
> > For what I understand, I must modify zd1211-83.ebuild, and rebuild
> > the ebuild with:
> > ebuild zd1211-83.ebuild digest (which worked fine)
> >
> > but, what should be the content of /tmp/net_dev.patch?¿?
>
> You list two patches.
>
> The one for the ebuild you should apply to the ebuild manually
> using 'patch', but you seem to have successfully done that already.
Yep,
> Then copy the first patch (net_dev.patch)
Ok, but, what is the content of net_dev.patch? if I put:
# cat files/net_dev.patch
EXTRA_CFLAGS += -O2 -Wall -Wstrict-prototypes -pipe
#EXTRA_CFLAGS += -Wa,-a,-ad -g
-EXTRA_CFLAGS += -DZDCONF_WE_STAT_SUPPORT=1
+EXTRA_CFLAGS += -DZDCONF_WE_STAT_SUPPORT=0
EXTRA_CFLAGS += -DHOST_IF_USB
EXTRA_CFLAGS += -DAMAC
EXTRA_CFLAGS += -DGCCK
or just
-EXTRA_CFLAGS += -DZDCONF_WE_STAT_SUPPORT=1
+EXTRA_CFLAGS += -DZDCONF_WE_STAT_SUPPORT=0
I get errorrs:
* Failed Patch: net_dev.patch !
* ( /usr/portage/net-wireless/zd1211/files/net_dev.patch )
*
* Include in your bugreport the contents of:
*
* /var/tmp/portage/net-wireless/zd1211-83/temp/net_dev.patch-14253.out
# cat /var/tmp/portage/net-wireless/zd1211-83/temp/net_dev.patch-14253.out
* net_dev.patch *
=
PATCH COMMAND: patch -p0 -g0 -E --no-backup-if-mismatch <
/usr/portage/net-wireless/zd1211/files/net_dev.patch
=
patch: Only garbage was found in the patch input.
=
> The ebuild will apply the patch itself, because of this line in the
> new ebuild:
>
> + epatch ${FILESDIR}/net_dev.patch
>
> alan
TIA!
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-user] Dirty COW, 4.4.8-hardened-r1 how to fix?
Yes you were absolutely right. On 161025-14:46-0400, Fernando Rodriguez wrote: > On Tue, Oct 25, 2016 at 07:38:01PM +0200, Miroslav Rovis wrote: > > Sorry about noticing your reply only now. > > > > Namely, thinking that people over at hardened ML would tell more about > > it, I indirectly initiated a thread over at hardened ML: > > https://archives.gentoo.org/gentoo-hardened/message/09bbf3bfe59a938f11ac044e891db77e > > > > Will surely check it! And am CC'ing hardened about this patch at the > > hardened ML. Maybe they patch and forward the 4.4.8-r1 to 4.4.8-r2 . > > --- > > Only now looked at the patch. > > > > No, you don't get it. And I'm not CC'ing this to hardened ML. Sorry about that. I was not getting it. After all if a patch isn't meant to patch something it only fails :-) . > > > > You can't just run the patch for a vanilla kernel onto a > > grsecurity-patched kernel. Look up the hardened-sources, and how they > > are patched, and what the mm.h and the gup.c in question (there are a > > few of so named files in various directories) look in the > > hardened-sources, and how they look in the vanilla-sources... > > fernan@navi /usr/src/linux-4.4.8-hardened-r1 $ sudo patch -p1 < > /home/fernan/dirtycow.patch > patching file include/linux/mm.h > Hunk #1 succeeded at 2131 (offset 19 lines). > patching file mm/gup.c > Hunk #3 succeeded at 357 (offset -5 lines). > It did work here too: # patch -p1 < /home/miro/dirtycow.patch patching file include/linux/mm.h Hunk #1 succeeded at 2131 (offset 19 lines). patching file mm/gup.c Hunk #3 succeeded at 357 (offset -5 lines). # where: # pwd /usr/src/linux # ls -l ../linux lrwxrwxrwx 1 root root 23 2016-10-23 02:37 ../linux -> linux-4.4.8-hardened-r1 # > It works so I guess you can. Never say you can't do something before > trying cause then you look like an idiot. > > And the patch says which are the files in question! > > > > > If I'm not mistaken, and I did check it. No, I'm not mistaken, you just > > sent me the Linus's patch. > > Yes you are mistaken, cause if you've tried it you wouldb't be asking > the question. And yes, that is Linus patch. Right! ... > > > > > > Did you tried it? > > > The patch attached comes straight from the git repo, just run: > > > > > > # cd /usr/src/linux > > > # patch -p1 < path/to/patch > > > > > > It'll likely work. > > > And it did, as above... > > > > Thanks for trying to help! Regards! Wrong on my part! Thanks for teaching me! And to teach an obstinate misunderstanding old man takes a little nerve. Regards! -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr signature.asc Description: Digital signature
Re: [gentoo-user] webkit-gtk-2.4.11-r200::gentoo failed (compile phase)
Hi Thelma, On Sun, 18 Feb 2018 12:01:54 -0700 the...@sys-concept.com wrote: I'm getting an error. make[1]: Leaving directory '/var/tmp/portage/net-libs/webkit-gtk-2.4.11-r200/work/webkitgtk-2.4.11' make: *** [GNUmakefile:25837: all] Error 2 * ERROR: net-libs/webkit-gtk-2.4.11-r200::gentoo failed (compile phase): * emake failed I've tried this propose patch. https://621532.bugs.gentoo.org/attachment.cgi?id=511304 save it to a file patch.patch went to directory: cd /usr/portage/net-libs/webkit-gtk/ patch -p0 < patch.patch It ask me what file I want to patch, I entered: JSStringRef.h run: ebuild /usr/portage/net-libs/webkit-gtk/webkit-gtk-2.4.11-r200.ebuild digest But it still fails to compile. Am I applying patch the same way. -- Thelma There’s no ‘JSStringRef.h’ file in ‘/usr/portage/net-libs/webkit-gtk/’, so patch must fail. Since the ebuild: /usr/portage/net-libs/webkit-gtk/webkit-gtk-2.4.11-r200.ebuild defines EAPI="6" you can just put the patch file in: /etc/portage/patches/net-libs/webkit-gtk/ with the right permissions (so that portage can read it). Don’t forget to remove the patch for newer (future) versions or be more specific and use the path: /etc/portage/patches/net-libs/webkit-gtk-2.4.11-r200/ for the patch file [1]. It seems the patch file isn’t valid because its first line: --- webkitgtk-2.4.11.orig/Source/JavaScriptCore/API/JSStringRef.h 2016-04-10 08:48:36.0 +0200 looks wrong to me (I doubt the package archive contains a ‘webkitgtk-2.4.11.orig’ subfolder underneath the patch command will find the file ‘JSStringRef.h’) After you ensured the path is fine try to re-emerge the package. References: - [1] <https://wiki.gentoo.org/wiki//etc/portage/patches> -- Regards, floyd
Re: [gentoo-user] Howto patch ebuilds?
On Thu, 29 Jun 2006 23:57:56 -0700 (PDT), Leonardo wrote: > I'm trying to apply a patch from gentoo bugzilla on a ebuild > that's in portage, but cannot find infos on how to do it. If you are trying to patch the ebuild itself: Download the patch file cd to the directory containing the ewbuild patch -p0 signature.asc Description: PGP signature
Re: [gentoo-user] korganizer patch
On Wednesday 26 October 2005 17:27, Benno Schulenberg wrote:
> Michael W. Holdeman wrote:
> > OK,
> > So what is wrong with this patch:
>
> What is the error message? :)
>
> What I normally do is: unpack the affected tarball, copy the
> affected files to .orig versions, make the necessary changes,
> create a patch from above the topdir with 'diff -u' between the
> orig files and the changed files, stick that patch in the
> ${FILESDIR} in the overlay, and add its name to PATCHES.
>
> The patch you show isn't one created with 'diff -u', 'patch' may
> simply not recognize it.
>
I shall try it.
Mike
ps.
* Applying korganizer-monthview.patch ...
* Failed Patch: korganizer-monthview.patch !
*
( /usr/local/overlays/kde-base/korganizer/files/korganizer-monthview.patch )
*
* Include in your bugreport the contents of:
*
*
/var/tmp/portage/korganizer-3.5.0_beta2/temp/korganizer-monthview.patch-25061.out
Michael W. Holdeman
Powered by Gentoo Linux www.gentoo.org |
Kernel 2.6.11-ck8 |
Win4Lin 5-1-20 netraverse.com |
Win4LinPro 6.1.1-03 win4lin.com |
|
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Soft scrolling on framebuffer consoles - with GPM handling - version of the patch for kernel 6.3 onwards.
On Wednesday, 24 January 2024 10:00:37 GMT Alan Mackenzie wrote: > I've adapted this patch for kernel 6.6.13. All of the parent post still > applies, with the exception of the version numbers. > > The main patch for the new kernel is 6.6.13-GPM.20240123.diff. > > Additionally I've attached a smaller patch which fixes what to me was a > little glitch in the gpm utility. This was that on a triple click to > select a whole line (or sequence of lines), the (last) line got a > linefeed appended to it. The effect was that if you wanted to hoik a > line out of some screen output and execute that from the bash command > line, you couldn't edit it first. So with this patch, you no longer get > that annoying linefeed, and the highlighting is adjusted accordingly. > This patch is (as far as I'm aware, without testing) independent of the > main GPM patch. Ever the star, Alan! -- Regards, Peter.
Re: [gentoo-user] emerge/python failure
2010/10/15 Fatih Tümen : > On Fri, Oct 15, 2010 at 8:29 PM, Mark Knecht wrote: >>> Got it, you hit the bug 340899 and its already fixed, just apply the patch >>> http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=c54c1af789b306a85e9d7e79fb54f02a05346616 >>> >>> -- >>> Fatih >>> >>> >> >> Thanks - I got the patch and that seems to have fixed eix-sync. >> >> Should anyone else run into this I did the following: >> >> Right click and save the patch file on the link provided by Fatih >> >> cd /usr/lib64/portage >> patch -p1 --dry-run > patch -p1 > >> and then things started working again. >> >> Note that when I finished the sync and emerged the newer version of >> portage I got messages I had not seen before about colliding with a >> couple of files. Those collisions were the files modified by the >> patch. >> >> Many thanks Fatih! >> >> Cheers, >> Mark >> > > Yw. Thanks for posting step-by-step solution for others' future reference. > And also for you or others to double check in case I wasn't doing it correctly. I wasn't sure where the portage executable was actually kept so I wasn't sure if I was patching the right thing. It was however the only place on my machine with the apparently correct patch that matched the first few lines in the patch file. Again, thanks!
[gentoo-user] Re: cannot emerge iptraf
Javier Uribe linuxchile.cl> writes: > > Hi, > > yes, cannot install iptraf in my system Yes, it fails on a p4 too: * Applying iptraf-2.7.0-atheros.patch ... [ ok ] * Applying iptraf-2.7.0-ipv6-alpha11.diff ... [ ok ] * Applying iptraf-2.7.0-2.6.patch ... * Failed Patch: iptraf-2.7.0-2.6.patch ! * ( /usr/portage/net-analyzer/iptraf/files/iptraf-2.7.0-2.6.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/iptraf-2.7.0-r1/temp/iptraf-2.7.0-2.6.patch-14025.out HTH James -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] netfilter tarpit target
Hi Daniel Daniel Iliev wrote on 03/04/07 05:13: > test ~ # cd /usr/src > test src # rm -rf linu* > test src # emerge -C gentoo-sources ; emerge gentoo-sources > test src # svn co https://svn.netfilter.org/netfilter/trunk/iptables > test iptables # cd iptables > test iptables # svn update > At revision 6786. > test src # cd .. > test src # svn co https://svn.netfilter.org/netfilter/trunk/patch-o-matic-ng > test src # cd patch-o-matic-ng > test patch-o-matic-ng # svn update > At revision 6786. > test patch-o-matic-ng # ./runme TARPIT > Hey! KERNEL_DIR is not set. > Where is your kernel source directory? [/usr/src/linux] > Hey! IPTABLES_DIR is not set. > Where is your iptables source code directory? [/usr/src/iptables] > Loading patchlet definitions. done > Welcome to Patch-o-matic ($Revision: 6736 $)! > > Kernel: 2.6.19, /usr/src/linux > Iptables: 1.3.7, /usr/src/iptables --snip-- > --------- > Do you want to apply this patch [N/y/t/f/a/r/b/w/q/?] t > Patch TARPIT applies cleanly > - > Do you want to apply this patch [N/y/t/f/a/r/b/w/q/?] y > Excellent! Source trees are ready for compilation. > test patch-o-matic-ng # cd /usr/src/linux > test linux # make menuconfig > test linux # grep tarpit -i .config > CONFIG_IP_NF_TARGET_TARPIT=m > test linux # make > --snip-- > > Root device is (3, 1) > Boot sector 512 bytes. > Setup is 4730 bytes. > System is 1622 kB > Kernel: arch/i386/boot/bzImage is ready (#1) > Building modules, stage 2. > MODPOST 159 modules > WARNING: "neigh_hh_output" [net/ipv4/netfilter/ipt_TARPIT.ko] undefined! > make[1]: *** [__modpost] Error 1 > make: *** [modules] Error 2 > test linux # Your .runme process ssem sOK, though I usually use ./runme extras to do the kernel updates. I'll try the same as you did here to see if I get the same problem. Cheers, Dave -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Compilation error with StructureSynth
Hello,
On Wed, 01 Nov 2017, tu...@posteo.de wrote:
[..]
>Thanks a lot for the extensive help, SIR! :)
Thanks.
[..]
>The patch itself was found (so the local thing works fine) and failed.
>
>The *.patch.out is attached to the email and after looking into it I
>think you will find the problem a hundred years faster than me since
>you created it. It seems some files are not where they are supposed to
>be.
Not quite. The "not founds" are normal for epatch/eapply trying
various '-p' levels... But see below in the patch.out (and nice that
you supplied that right away).
>There is a glitch in the matrix...they have changed something...I
>see Schroedingers cat twice.
>
>Ah! By the way: According to quantum physics the cite at the bottom of
>you previous email is wrong :
>"WANTED: Schroedingers Cat, dead or alive."
>must be
>"WANTED: Schroedingers Cat, dead and alive."
>Heisenberg would not accept this kind of uncertainty -- in
>principle...
>;)
*g* You're right. But it's just a quote I picked up long time ago ;)
Anyway, here's the deal:
[..]
>PATCH COMMAND: patch -p1 -g0 -E --no-backup-if-mismatch --dry-run -f <
>'/var/tmp/portage/media-gfx/structure-synth-1.5.0-r1/files/structure-synth-1.5.0-gl.patch'
>
>==
>checking file SyntopiaCore/GLEngine/Raytracer/Sampler.h
>Hunk #1 FAILED at 1 (different line endings).
>1 out of 1 hunk FAILED
>checking file SyntopiaCore/GLEngine/Raytracer/VoxelStepper.cpp
>Hunk #1 FAILED at 122 (different line endings).
>1 out of 1 hunk FAILED
>checking file SyntopiaCore/GLEngine/Sphere.h
>Hunk #1 FAILED at 1 (different line endings).
>1 out of 1 hunk FAILED
>
>patch program exited with status 1
>==
Because this failed, epatch goes on, confusing you with more a few
more 'not found' stuff outputs...
>PATCH COMMAND: patch -p2 -g0 -E --no-backup-if-mismatch --dry-run -f <
>'/var/tmp/portage/media-gfx/structure-synth-1.5.0-r1/files/structure-synth-1.5.0-gl.patch'
>
>==
>can't find file to patch at input line 4
[..]
Thing is: the source-code of this package has CRLF line endings,
and, while I added the CRs to my patch, via mail and saving, you
probably saved them with "just" the LFs.
a) add the '-l' / '--ignore-whitespace' option to patch, don't know if
that works with epatch/eapply as e.g. 'epatch -l ${FILESDIR}/..', or
b) reencode the line-endings of the patch to match that of the
source-files. No idea if you can reencode the whole patch or just
the diff. So ... I'll reattach the patch xzipped, that should keep
your mail-client from changing the line-endings. xz -d that patch
then into the files subdir. That's probably the easiest way.
HTH,
-dnh
--
Chemie ist auch bloß spezialisierte Physik.
-- Jens Dittmar in drsst
structure-synth-1.5.0-gl.patch.xz
Description: structure-synth-1.5.0-gl.patch.xz
Re: [gentoo-user] zd1211 patch?
On Tue, 8 May 2007 17:56:36 +0200 Alan McKinnon wrote: > On Tuesday 08 May 2007, Arnau Bria wrote: > > Ok, but, what is the content of net_dev.patch? > > It's right there in your original mail: [...] > That IS what the patch file looks like. It will alter your Makefile, > and the epatch function in portage is smart enough to try apply the > patch to the following files in order: > > /root/tmp-new/Makefile > tmp-new/Makefile > Makefile Ok, thanks you very much for the explanation. > If that doesn't work, the patch itself is faulty Well, following all instructions and, now, yours, I ensure patch still doens't work FOR ME. My workaround was modifying Makefile in tgz and done an ebuild digest again. I could compile the driver. > for more info "man patch" I'll take a look, thanks > alan Arnau -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] emerge/python failure
On Fri, Oct 15, 2010 at 8:29 PM, Mark Knecht wrote: >> Got it, you hit the bug 340899 and its already fixed, just apply the patch >> http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=c54c1af789b306a85e9d7e79fb54f02a05346616 >> >> -- >> Fatih >> >> > > Thanks - I got the patch and that seems to have fixed eix-sync. > > Should anyone else run into this I did the following: > > Right click and save the patch file on the link provided by Fatih > > cd /usr/lib64/portage > patch -p1 --dry-run patch -p1 > and then things started working again. > > Note that when I finished the sync and emerged the newer version of > portage I got messages I had not seen before about colliding with a > couple of files. Those collisions were the files modified by the > patch. > > Many thanks Fatih! > > Cheers, > Mark > Yw. Thanks for posting step-by-step solution for others' future reference. -- Fatih
Re: [gentoo-user] how to apply a patch to ebuild?
On Wed, 2006-03-22 at 08:56 -0300, Allan Spagnol Comar wrote: > Hi I was reading the bug report 114915 at gentoo bugzilla and it > mentions a patch to ebuid, I had downloaded the patch but I don't have > any clue about how can I apply it to current ebuid. well, how confident are you at having a go? Search the wiki for "portage overlay". Essentially it involves making a directory (like /usr/local/portage) and putting modified ebuilds in there. You only have to copy as much or as little of /usr/portage as you like, that may only be 2 or 3 files. The patching itself is done with the `patch` command line tool. man patch will give you more help there. Usually its `patch -px Genius is one percent inspiration and ninety-nine percent perspiration. -- Thomas Alva Edison -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] How to get source of emerge to patch?
On Tue, 11 Jul 2006 21:46:05 -0700 (PDT), Jim John wrote: > Hi. I want to patch cyrus-imapd. I have the diff file, but no source > because I emerged from the repository. How do I get the source and > ebuild it? Thanks. The best way to do this is to modify the ebuild to apply the patch. Copy the existing cyrus-imapd directory from /usr/portage to your overlay. Copy the patch to the files subdirectory of that new directory Open the copied ebuild in your text editor. you'll see an epatch line in the src_unpack section, add another one with the name of your patch. Run "ebuild cyrus-imapd-version.ebuild digest" Emerge it. If the patch may be useful to others, file a report on bugs.g.o. -- Neil Bothwick "That trick NEVER works!" signature.asc Description: PGP signature
Re: [gentoo-user] webkit-gtk-2.4.11-r200::gentoo failed (compile phase)
On Sun, 18 Feb 2018 12:01:54 -0700, the...@sys-concept.com wrote: > I've tried this propose patch. > https://621532.bugs.gentoo.org/attachment.cgi?id=511304 > > save it to a file patch.patch > went to directory: > cd /usr/portage/net-libs/webkit-gtk/ > patch -p0 < patch.patch > > It ask me what file I want to patch, I entered: > JSStringRef.h > > run: > ebuild /usr/portage/net-libs/webkit-gtk/webkit-gtk-2.4.11-r200.ebuild > digest > > But it still fails to compile. > Am I applying patch the same way. The patch is to be applied to the source files, not the ebuild mkdir /etc/portage/patches/net-libs/webkit-gtk/webkit-gtk-2.4.11-r200 then copy the patch file to that directory and portage will apply it to the source after unpacking. -- Neil Bothwick Where do forest rangers go to "get away from it all?" pgp7HFx9JU0aV.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Portage Patch failed to apply - System will no longer upgrade
On Sunday 07 June 2009 19:02:54 Rod wrote: > Hi. > > This issue is really pissing me off, I have ried almost all the > fixes, even to the point of booting and copying a Stage3 tarball over > the running system and doing a Stage3 Install. > > No matter what I do, and for almost ALL packages I get .. > * Portage patch failed to apply (ltmain.sh version 1.5.24)! > * Please bug azarah or vapier to add proper patch. > * > * ERROR: dev-libs/gmp-4.3.1 failed. > * Call stack: > * ebuild.sh, line 49: Called src_unpack > * environment, line 2811: Called elibtoolize > * environment, line 1065: Called die > * The specific snippet of code: > * die "Portage patch failed to apply!"; > * The die message: > * Portage patch failed to apply! > > For this package and everything else I wish to apply, this is > locking my system in time so I can no longer upgrade any software ;o( Assuming that this is a problem on your end (no-one else is reporting portage problems), let's look at why patch is failing. If you manually unpack the distfile and try to patch it, what errors do you get? -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Adding realtime-prempt kernel patches to gentoo-sources
Hi, One more question if I might. What does this message mean? I'm guessing that a patch in my patch file has already been applied in gentoo-sources? If so then it would seem that I'd want to skip it. Is that correct? Skipping the patch would seem reasonable if that's what this means. Or am I misunderstanding this? Thanks, Mark patching file include/asm-i386/string.h Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 9 out of 9 hunks ignored -- saving rejects to file include/asm-i386/string.h.rej -- gentoo-user@gentoo.org mailing list
[gentoo-user] [SOLVED] Re: nvidia-drivers-340.76 failed with gentoo-sources-4.0.5
2015-06-18 13:03 GMT+02:00 Jacques Montier : > Hi all, > > Because of an old graphic card, i have to compile nvidia-drivers-340.76. > nvidia-drivers-340.76 does not compile with the new 4.0.5 kernel. > Here is the output error : > /var/tmp/portage/x11-drivers/nvidia-drivers-340.76/work/kernel/nv-pat.o] > Error 1 > > I saw a topic about that problem on Gentoo forum : > https://forums.gentoo.org/viewtopic-p-7754020.html?sid=3b9fed3069c0b6644c1a41e839455b85 > I tried to apply the patch > /etc/portage/patches/x11-drivers/nvidia-drivers/nvidia-drivers-340.76.patch > > *--- a/kernel/nv-pat.c.orig * > *+++ b/kernel/nv-pat.c * > *@@ -35,8 +35,13 @@ * > * unsigned long cr0 = read_cr0(); * > * write_cr0(((cr0 & (0xdfff)) | 0x4000)); * > * wbinvd(); * > *+if LINUX_VERSION_CODE < KERNEL_VERSION(3, 20, 0) * > * *cr4 = read_cr4(); * > * if (*cr4 & 0x80) write_cr4(*cr4 & ~0x80); * > *+else * > *+*cr4 = __read_cr4(); * > *+if (*cr4 & 0x80) __write_cr4(*cr4 & ~0x80); * > *+endif * > * __flush_tlb(); * > * } * > > *@@ -46,7 +51,11 @@ * > * wbinvd(); * > * __flush_tlb(); * > * write_cr0((cr0 & 0x9fff)); * > *+if LINUX_VERSION_CODE < KERNEL_VERSION(3, 20, 0) * > * if (cr4 & 0x80) write_cr4(cr4); * > *+else * > *+if (cr4 & 0x80) __write_cr4(cr4); * > *+endif * > * } * > > * static int nv_determine_pat_mode(void)* > > This patch does not work ; i get the error > > * Failed Patch: nvidia-drivers-340.76.patch ! > * ( > /etc/portage/patches//x11-drivers/nvidia-drivers/nvidia-drivers-340.76.patch > ) > > > Any idea ? > > Thanks a lot, > > > Cheers, > > > > > > > *--* > *Jacques* > Hello again, I think there were some typo in the patch line. I downloaded a tar.gz patch archive from gentoo forum : http://dev.gentoo.org/~gienah/unsupported/etc-portage-patches-x11-drivers-nvidia-drivers-340.76-for-kernel-gt-3.14.tar.gz Now nvidia-drivers compiles fine and everything is ok. Sorry for the noise, Cheers, *--* *Jacques*
[gentoo-user] elibtoolize Portage patch requested, but failed to apply!
Hi all, I just did an emerge -sync and a porting update on two gentoo. Some packages do not want to compile anymore. Exemples gcc : * updating multilib directories to be: ../lib64 ../lib32 * Running elibtoolize in: gcc-4.9.4/ * Portage patch requested, but failed to apply! * Please file a bug report to add a proper patch. * ERROR: sys-devel/gcc-4.9.4::gentoo failed (prepare phase): * Portage patch requested, but failed to apply! php-5.6.30 : Running elibtoolize in: apr-1.5.2/build/ * Portage patch failed to apply (ltmain.sh version 2.4.6)! * Please file a bug report to add a proper patch. * ERROR: dev-libs/apr-1.5.2::gentoo failed (prepare phase): * Portage patch failed to apply! * * Call stack: * ebuild.sh, line 115: Called src_prepare * environment, line 2726: Called eautoreconf * environment, line 864: Called elibtoolize '--force' '/var/tmp/portage/dev-libs/apr-1.5.2/work/apr-1.5.2' * environment, line 1116: Called die * The specific snippet of code: * die "Portage patch failed to apply!"; * * If you need support, post the output of `emerge --info '=dev-libs/apr-1.5.2::gentoo'`, * the complete build log and the output of `emerge -pqv '=dev-libs/apr-1.5.2::gentoo'`. * The complete build log is located at '/var/tmp/portage/dev-libs/apr-1.5.2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-libs/apr-1.5.2/temp/environment'. * Working directory: '/var/tmp/portage/dev-libs/apr-1.5.2/work/apr-1.5.2' * S: '/var/tmp/portage/dev-libs/apr-1.5.2/work/apr-1.5.2' I tried many things without success. Does anyone have any idea what I could do? Thank you
[gentoo-user] how to patch the asterisk ebuild
Title: how to patch the asterisk ebuild Hi all, somebody know how to patch the software via ebuild. i need to patch the asterisk.1.2.13 in part of chan_sip.c for correct the silencesupp in the huawei softswitch. but i dont know how to correct in the ebuild Thanks, kitti huawei.patch Description: huawei.patch
Re: [gentoo-user] Gentoo system crumbling, reports of gcc death
On 6/13/06, Richard Fish <[EMAIL PROTECTED]> wrote:
On 6/13/06, Kevin O'Gorman <[EMAIL PROTECTED]> wrote:
> Start digging. It completed just fine.
Ok, do this and send me the result.
# emerge --debug =dev-libs/glib-1.2.10-r5 >~/glib-merge.txt 2>&1
-Richard
PS. Please post further replies in plain-text. The multi-part
HTML/text messages are making it difficult for me to reply and
maintain correct levels of '>'. In gmail, just click the 'Plain text'
link above the composition box.
--
gentoo-user@gentoo.org mailing list
Done. Results attached. Sorry about the HTML. I hadn't noticed it
was turned on. And I generally oppose HTML mail.
++ kevin
--
Kevin O'Gorman, PhD
myaction None
myopts ['--debug', '--buildpkg']
Calculating dependencies
Parent:None
Depstring: =dev-libs/glib-1.2.10-r5
Candidates: ['=dev-libs/glib-1.2.10-r5']
ebuild: dev-libs/glib-1.2.10-r5
binpkg: None
+ dyn_clean
+ '[' -z /var/tmp/portage/glib-1.2.10-r5 ']'
+ type -p chflags
+ rm -rf /var/tmp/portage/glib-1.2.10-r5/image
/var/tmp/portage/glib-1.2.10-r5/homedir
+ hasq keeptemp autoconfig buildpkg distlocks metadata-transfer sandbox sfperms
strict
+ [[ autoconfig buildpkg distlocks metadata-transfer sandbox sfperms strict
== *\ \k\e\e\p\t\e\m\p\ * ]]
+ rm -rf /var/tmp/portage/glib-1.2.10-r5/temp
+ hasq keepwork autoconfig buildpkg distlocks metadata-transfer sandbox sfperms
strict
+ [[ autoconfig buildpkg distlocks metadata-transfer sandbox sfperms strict
== *\ \k\e\e\p\w\o\r\k\ * ]]
+ rm -rf /var/tmp/portage/glib-1.2.10-r5/.unpacked
+ rm -rf /var/tmp/portage/glib-1.2.10-r5/.compiled
+ rm -rf /var/tmp/portage/glib-1.2.10-r5/.tested
+ rm -rf /var/tmp/portage/glib-1.2.10-r5/.installed
+ rm -rf /var/tmp/portage/glib-1.2.10-r5/.packaged
+ rm -rf /var/tmp/portage/glib-1.2.10-r5/build-info
+ rm -rf /var/tmp/portage/glib-1.2.10-r5/work
+ '[' -f /var/tmp/portage/glib-1.2.10-r5/.unpacked ']'
+ rm -rf /var/tmp/portage/glib-1.2.10-r5/distdir
++ find /var/tmp/portage/glib-1.2.10-r5 -mindepth 1 -maxdepth 1
+ '[' -z '' ']'
+ rmdir /var/tmp/portage/glib-1.2.10-r5
+ true
+ set +x
Parent:ebuild / dev-libs/glib-1.2.10-r5 merge
Depstring:
Exiting... None
... done!
>>> Emerging (1 of 1) dev-libs/glib-1.2.10-r5 to /
>>> checking ebuild checksums ;-)
>>> checking auxfile checksums ;-)
>>> checking miscfile checksums ;-)
>>> checking glib-1.2.10.tar.gz ;-)
+ dyn_setup
++ type -t pre_pkg_setup
+ '[' '' == function ']'
+ pkg_setup
+ return
++ type -t post_pkg_setup
+ '[' '' == function ']'
+ set +x
+ dyn_unpack
+ trap abort_unpack SIGINT SIGQUIT
++ type -t pre_src_unpack
+ '[' '' == function ']'
+ local newstuff=no
+ '[' -e /var/tmp/portage/glib-1.2.10-r5/work ']'
+ '[' -e /var/tmp/portage/glib-1.2.10-r5/work ']'
+ '[' '!' -d /var/tmp/portage/glib-1.2.10-r5/work ']'
+ install -m0700 -d /var/tmp/portage/glib-1.2.10-r5/work
+ cd /var/tmp/portage/glib-1.2.10-r5/work
+ vecho '>>> Unpacking source...'
+ [[ '' == \1 ]]
+ echo '>>> Unpacking source...'
>>> Unpacking source...
+ src_unpack
+ unpack glib-1.2.10.tar.gz
+ local x
+ local y
+ local myfail
+ local tarvars
+ '[' GNU == BSD ']'
+ tarvars=--no-same-owner
+ '[' -z glib-1.2.10.tar.gz ']'
+ for x in '"$@"'
+ vecho '>>> Unpacking glib-1.2.10.tar.gz to
/var/tmp/portage/glib-1.2.10-r5/work'
+ [[ '' == \1 ]]
+ echo '>>> Unpacking glib-1.2.10.tar.gz to
/var/tmp/portage/glib-1.2.10-r5/work'
>>> Unpacking glib-1.2.10.tar.gz to /var/tmp/portage/glib-1.2.10-r5/work
+ y=glib-1.2.10.tar
+ y=tar
+ myfail='glib-1.2.10.tar.gz does not exist'
+ '[' gl = ./ ']'
+ srcdir=/var/tmp/portage/glib-1.2.10-r5/distdir/
+ [[ glib-1.2.10.tar.gz == /var/tmp/portage/glib-1.2.10-r5/distdir* ]]
+ '[' '!' -s /var/tmp/portage/glib-1.2.10-r5/distdir/glib-1.2.10.tar.gz ']'
+ myfail='failure unpacking glib-1.2.10.tar.gz'
+ case "${x##*.}" in
+ '[' tar == tar ']'
+ tar zxf /var/tmp/portage/glib-1.2.10-r5/distdir/glib-1.2.10.tar.gz
--no-same-owner
+ chmod -Rf a+rX,u+w,g-w,o-w .
+ cd /var/tmp/portage/glib-1.2.10-r5/work/glib-1.2.10
+ epatch /usr/portage/dev-libs/glib/files/glib-1.2.10-m4.patch
+ local PIPE_CMD=
+ local STDERR_TARGET=/var/tmp/portage/glib-1.2.10-r5/temp/3567.out
+ local PATCH_TARGET=/var/tmp/portage/glib-1.2.10-r5/temp/3567.patch
+ local PATCH_SUFFIX=
+ local SINGLE_PATCH=no
+ local x=
+ unset P4CONFIG P4PORT P4USER
+ '[' 1 -gt 1 ']'
+ '['
Re: [gentoo-user] Compilation error with StructureSynth
On 11/01 04:44, tu...@posteo.de wrote:
> On 11/01 04:05, David Haller wrote:
> > Hello,
> >
> > On Wed, 01 Nov 2017, tu...@posteo.de wrote:
> > [..]
> > >Thanks a lot for the extensive help, SIR! :)
> >
> > Thanks.
> >
> > [..]
> > >The patch itself was found (so the local thing works fine) and failed.
> > >
> > >The *.patch.out is attached to the email and after looking into it I
> > >think you will find the problem a hundred years faster than me since
> > >you created it. It seems some files are not where they are supposed to
> > >be.
> >
> > Not quite. The "not founds" are normal for epatch/eapply trying
> > various '-p' levels... But see below in the patch.out (and nice that
> > you supplied that right away).
> >
> > >There is a glitch in the matrix...they have changed something...I
> > >see Schroedingers cat twice.
> > >
> > >Ah! By the way: According to quantum physics the cite at the bottom of
> > >you previous email is wrong :
> > >"WANTED: Schroedingers Cat, dead or alive."
> > >must be
> > >"WANTED: Schroedingers Cat, dead and alive."
> > >Heisenberg would not accept this kind of uncertainty -- in
> > >principle...
> > >;)
> >
> > *g* You're right. But it's just a quote I picked up long time ago ;)
> >
> > Anyway, here's the deal:
> >
> > [..]
> > >PATCH COMMAND: patch -p1 -g0 -E --no-backup-if-mismatch --dry-run -f <
> > >'/var/tmp/portage/media-gfx/structure-synth-1.5.0-r1/files/structure-synth-1.5.0-gl.patch'
> > >
> > >==
> > >checking file SyntopiaCore/GLEngine/Raytracer/Sampler.h
> > >Hunk #1 FAILED at 1 (different line endings).
> > >1 out of 1 hunk FAILED
> > >checking file SyntopiaCore/GLEngine/Raytracer/VoxelStepper.cpp
> > >Hunk #1 FAILED at 122 (different line endings).
> > >1 out of 1 hunk FAILED
> > >checking file SyntopiaCore/GLEngine/Sphere.h
> > >Hunk #1 FAILED at 1 (different line endings).
> > >1 out of 1 hunk FAILED
> > >
> > >patch program exited with status 1
> > >==
> >
> > Because this failed, epatch goes on, confusing you with more a few
> > more 'not found' stuff outputs...
> >
> > >PATCH COMMAND: patch -p2 -g0 -E --no-backup-if-mismatch --dry-run -f <
> > >'/var/tmp/portage/media-gfx/structure-synth-1.5.0-r1/files/structure-synth-1.5.0-gl.patch'
> > >
> > >==
> > >can't find file to patch at input line 4
> > [..]
> >
> > Thing is: the source-code of this package has CRLF line endings,
> > and, while I added the CRs to my patch, via mail and saving, you
> > probably saved them with "just" the LFs.
> >
> > a) add the '-l' / '--ignore-whitespace' option to patch, don't know if
> >that works with epatch/eapply as e.g. 'epatch -l ${FILESDIR}/..', or
> >
> > b) reencode the line-endings of the patch to match that of the
> >source-files. No idea if you can reencode the whole patch or just
> >the diff. So ... I'll reattach the patch xzipped, that should keep
> >your mail-client from changing the line-endings. xz -d that patch
> >then into the files subdir. That's probably the easiest way.
> >
> > HTH,
> > -dnh
> >
> > --
> > Chemie ist auch bloß spezialisierte Physik.
> >-- Jens Dittmar in drsst
>
> Moin David,
>
> ;)
>
> nope...currently the cat is more dead than alive...
> I looked at it!
>
>
> I did the following:
>
> vim
> :set ff
> unix
> :set ff=dos
> :wq
> repoman -v manifest (since file has changed)
>
> emerge structure-synth.
>
> BADABOOM! (The fifth element)
>
> See my theorie of uncertainity attached to this mail...
>
> :)
>
> Cheers
> Meino
>
>
Hi,
did the following after the failed CRLF-fix:
(using zsh)
export PATCH_OPTS=-I; emerge structure-synth
which fails the same way...
Cheers
Meino
Re: [gentoo-user] Dirty COW, 4.4.8-hardened-r1 how to fix?
On Tue, Oct 25, 2016 at 07:38:01PM +0200, Miroslav Rovis wrote: > Sorry about noticing your reply only now. > > Namely, thinking that people over at hardened ML would tell more about > it, I indirectly initiated a thread over at hardened ML: > https://archives.gentoo.org/gentoo-hardened/message/09bbf3bfe59a938f11ac044e891db77e > > Will surely check it! And am CC'ing hardened about this patch at the > hardened ML. Maybe they patch and forward the 4.4.8-r1 to 4.4.8-r2 . > --- > Only now looked at the patch. > > No, you don't get it. And I'm not CC'ing this to hardened ML. > > You can't just run the patch for a vanilla kernel onto a > grsecurity-patched kernel. Look up the hardened-sources, and how they > are patched, and what the mm.h and the gup.c in question (there are a > few of so named files in various directories) look in the > hardened-sources, and how they look in the vanilla-sources... fernan@navi /usr/src/linux-4.4.8-hardened-r1 $ sudo patch -p1 < /home/fernan/dirtycow.patch patching file include/linux/mm.h Hunk #1 succeeded at 2131 (offset 19 lines). patching file mm/gup.c Hunk #3 succeeded at 357 (offset -5 lines). It works so I guess you can. Never say you can't do something before trying cause then you look like an idiot. And the patch says which are the files in question! > > If I'm not mistaken, and I did check it. No, I'm not mistaken, you just > sent me the Linus's patch. Yes you are mistaken, cause if you've tried it you wouldb't be asking the question. And yes, that is Linus patch. > > No, wrong. But thanks for trying to help! > > On 161025-13:16-0400, Fernando Rodriguez wrote: > > On Tue, Oct 25, 2016 at 07:11:54AM +0200, Miroslav Rovis wrote: > > > On 161021-11:04-0400, Rich Freeman wrote: > > > > On Fri, Oct 21, 2016 at 10:49 AM, Mick > > > > wrote: > > > > > https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails > > > > > > > > Not yet: > > > > https://bugs.gentoo.org/show_bug.cgi?id=597624 > > > > > > > > > > We are talking grsecurity-patched (kind of stable[*]) kernel sources, > > > the =sys-kernel/hardened-sources-4.4.8-r1 package [**]. > > > > > > I read most of the discussion, and I could easily patch the gup.c and > > > mm.h in question, but those files need to be patched before application > > > of the grsecurity patch, and that is a little more complex work. > > > > Did you tried it? > > The patch attached comes straight from the git repo, just run: > > > > # cd /usr/src/linux > > # patch -p1 < path/to/patch > > > > It'll likely work. > > > > > > > > Has anybody done this, as I have limited time available to practice user > > > patching (which in its simplest form, I was able to do here: > > > >=dev-libs/nss-3.24 - Add USE flag to enable SSL key > > > https://bugs.gentoo.org/show_bug.cgi?id=587116#c2 ), in case it can be > > > done with user patching, of course. > > > > > > Anyone? > > > > > > Regards! > > > --- > > > [*] kind of stable, because there are, since about 1 yrs ago, only > > > testing kernel available for the non-paying users ;-( > > > > > > [**] I have to use 4.4.8.r1 because recent kernel all crash with libirt > > > and qemu which I am trying to use: > > > https://bugs.gentoo.org/show_bug.cgi?id=597554 > > > -- > > > Miroslav Rovis > > > Zagreb, Croatia > > > http://www.CroatiaFidelis.hr > > > > > > > > -- > > Fernando Rodriguez > > > commit 1294d355881cc5c3421d24fee512f16974addb6c > > Author: Linus Torvalds > > Date: Thu Oct 13 13:07:36 2016 -0700 > > > > mm: remove gup_flags FOLL_WRITE games from __get_user_pages() > > > ... > > Thanks for trying to help! Regards! > -- > Miroslav Rovis > Zagreb, Croatia > http://www.CroatiaFidelis.hr -- Fernando Rodriguez signature.asc Description: Digital signature
Re: [gentoo-user] Re: Patch via perl script in an ebuild?
>> David, you mentioned in the bug that you couldn't get the patch to >> work clean. I thought you got it working before when you posted the >> patched Typemap for me to download. Did it work then but not now? >> >> http://bugs.gentoo.org/show_bug.cgi?id=305621 >> >> - GrantSOAP-WSDL >> >> > The patched Typemap created by hand works fine, but when you attempt > to use a downloaded SOAP-WSDL and patch it failed for me, may need to > manually create a patch for SOAP-WSDL. > > -- > David Abbott (dabbott) I'm sure I'm confused because of my weak understanding of this. I thought Typemap was a component of the downloaded SOAP-WSDL. If not, what is Typemap and how did you patch it by hand? - Grant
Re: [gentoo-user] Adding realtime-prempt kernel patches to gentoo-sources
Mark Knecht wrote: > Hi, >One more question if I might. What does this message mean? I'm > guessing that a patch in my patch file has already been applied in > gentoo-sources? If so then it would seem that I'd want to skip it. Is > that correct? Skipping the patch would seem reasonable if that's what > this means. > >Or am I misunderstanding this? > > Thanks, > Mark > > patching file include/asm-i386/string.h > Reversed (or previously applied) patch detected! Assume -R? [n] > Apply anyway? [n] > Skipping patch. > 9 out of 9 hunks ignored -- saving rejects to file > include/asm-i386/string.h.rej Yup, thats exactly the meaning of that message :) Christian -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] ltmain.sh version 1.5.22
On Saturday 24 January 2009 12:11:41 Rod wrote: >I'm getting the following error too much, many packages are no longer > insalling with this problem ;o( > * Running elibtoolize in: libmcrypt-2.5.8 > * Applying install-sh-1.5.patch ... > > * Portage patch failed to apply (ltmain.sh version 1.5.22)! > * Please bug azarah or vapier to add proper patch. That patch applies just fine here, both 2.5.8 and 2.5.8-r1. In case it helps, my system is ~amd64 The emerge output is very sparse, I can't see the reason for the patch failing. Try unpacking and patching manually to get a descriptive error message. Also, is your emerge --sync up to date? -- alan dot mckinnon at gmail dot com
[gentoo-user] Checksum error
Hi,
I am currently doing a python-updater run. While the rebuilding
of the several packages the process failed with
>>> Downloading
'http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patch.4.7.25.4'
--2009-10-11 10:57:48--
http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patch.4.7.25.4
Resolving www.oracle.com... 80.157.150.10, 80.157.150.33
Connecting to www.oracle.com|80.157.150.10|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5647 (5.5K) [application/octet-stream]
Saving to: `/usr/portage/distfiles/patch.4.7.25.4'
100%[>]
5,647 --.-K/s in 0.04s
2009-10-11 10:57:48 (135 KB/s) - `/usr/portage/distfiles/patch.4.7.25.4'
saved [5647/5647]
('Filesize does not match recorded size', 5647L, 5500)
!!! Fetched file: patch.4.7.25.4 VERIFY FAILED!
!!! Reason: Filesize does not match recorded size
!!! Got: 5647
!!! Expected: 5500
Refetching... File renamed to
'/usr/portage/distfiles/patch.4.7.25.4._checksum_failure_.B3kSP2'
How can I proceed?
Have a nice weekend!
Best regards,
mcc
--
Please don't send me any Word- or Powerpoint-Attachments
unless it's absolutely neccessary. - Send simply Text.
See http://www.gnu.org/philosophy/no-word-attachments.html
In a world without fences and walls nobody needs gates and windows.
Re: [gentoo-user] ltmain.sh version 1.5.22
Alan McKinnon wrote: On Saturday 24 January 2009 12:11:41 Rod wrote: I'm getting the following error too much, many packages are no longer insalling with this problem ;o( * Running elibtoolize in: libmcrypt-2.5.8 * Applying install-sh-1.5.patch ... * Portage patch failed to apply (ltmain.sh version 1.5.22)! * Please bug azarah or vapier to add proper patch. That patch applies just fine here, both 2.5.8 and 2.5.8-r1. In case it helps, my system is ~amd64 The emerge output is very sparse, I can't see the reason for the patch failing. Try unpacking and patching manually to get a descriptive error message. Also, is your emerge --sync up to date? Yes my sync is up to date, I'm not sure why I can no longer use `emerge --sync` more interested in getting the ltmain problem fixed first. # emerge-webrsync Fetching most recent snapshot ... Trying to retrieve 20090125 snapshot from http://distfiles.gentoo.org ... Fetching file portage-20090125.tar.lzma.md5sum ... Fetching file portage-20090125.tar.lzma.gpgsig ... Fetching file portage-20090125.tar.lzma ... I'm running ~x64 (32bit) Would you be able to tell me how to do this patch & build manually please?
[gentoo-user] Patch file for cdrtools to allow --duplicates-once
Is there a patch file to patch mkisofs to use the --duplicates-once option during generation of iso9960/UDF images? The problem is that the one that exists right now, the patch (against the official sources) cannot be found because the original site (bootcd.ru) is permanently down. Or do I need to make a table of SHA-1s to weed out the identical files? -- Andrey Vul
Re: [gentoo-user] how to apply a patch to ebuild?
On Wed, 22 Mar 2006 08:56:17 -0300, Allan Spagnol Comar wrote: > Hi I was reading the bug report 114915 at gentoo bugzilla and it > mentions a patch to ebuid, I had downloaded the patch but I don't have > any clue about how can I apply it to current ebuid. As root: cd /usr/portage/x11-libs/gtkDPS patch -p0 signature.asc Description: PGP signature
Re: [gentoo-user] OO fails with useless 65280 error on unoxml
> > Somewhere in this thread was a mention of a failed patch. > > Where version of patch are you using? If it's 2.6, downgrade it as 2.6 is > horribly broken > > http://blog.flameeyes.eu/2009/12/01/gentoo-service-announcement-keep-clear-of- > gnu-patch-2-6 > There was some patching things that caught my eye related to redland. However, I found out that it was applied in both OO.o-3.0.0 and OO.o-3.1.1 and so I assumed it was not to blame. I can't remember if I actually posted about it in my brainstorming. In any case, I have not modified patch since dealing with the OO.o problems, and: Calculating dependencies... done! [ebuild R ] sys-devel/patch-2.5.9 USE="-static" 0 kB Thanks for the notice, though. ~daid
Re: [gentoo-user] Re: Failing to compile hydrogen
Am 15/02/2012 04:59, schrieb meino.cra...@gmx.de: »Q« [12-02-14 18:12]: On Tue, 14 Feb 2012 17:58:49 +0100 meino.cra...@gmx.de wrote: How can I circumvent the problem? I can't vouch for it, but there's a patch attached to the bug. <https://bugs.gentoo.org/show_bug.cgi?id=372003> Hi, thank you for your help and the patch! :) How can I include this patch into the normal build process of gentoo ? Thank you very much in advance for any help! create a local overlay, copy the hydrogen dir, copy the patch, edit the ebuild to include the patch, compile. sounds a lot more comlicated than it actually is and it should be easy to find tutorials for the individual steps :)
[gentoo-user] Advice sought on the use of a VCS (specifically git) to keep track of my Softscroll patch.
Hello, Gentoo. Over the last few months I've posted several versions of my kernel patch which re-enables soft scrollback. I thought at the time I could just keep a few files informally in my home directory. But I'm already getting confused about what is where, what applies to which kernel versions and so on. Clearly I need to put the patch into a version control system. I would appreciate some advice on this. I think I need to get a clone of the kernel's git repository, and maintain the patch in it as a branch or several branches. Or would it be feasible just to maintain the patch in a VCS? My feeling is that I really need the full repository. Where would I find a suitable kernel git repository to clone? An "official" repository, whatever that means? Ideally, I want one with just the various kernel releases, not one containing gigabytes of intermediate versions. Where would I even start searching to find this out? Once I've got this far, I'll need to think about a versioning scheme for the patch - there are irritating little differences in the console code between versions of the kernel, as recently pointed out by Jorge Almeida, so there would be irritating differences between versions of the patch. Maybe I could put it onto the Gentoo wiki, but that's not in the near future. Thanks for the help! -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] 3 - ERRORS
On Sun, 2005-06-12 at 20:31 +0200, Holly Bostick wrote: > Thanks for the info, but I notice that there's also a patch to > portage.py attached to the bug. Is it correct to just patch it with the > standard "patch -p1 blah blah blah" (patch syntax doesn't roll > trippingly off my typing finger, but I'll look it up before proceeding)? > > Is this "safe" (insofar as it's patching a portage file, unlike > revdep-rebuild itself)? You don't have to add the portage.py patch (although it shouldn't hurt anything if you do). Those changes are there for adding support into portage for the package maintainers. Once that support is there, then package maintainers will be able to automatically set the appropriate variables to revdep-rebuild for their packages. Regards, Paul -- gentoo-user@gentoo.org mailing list
[gentoo-user] Message from gtk+ ebuild:
I've got a perplexing message from the ebuild: I says there's a file/scipt/program at /etc/X11/gtk/gtkrc that I should remove. I have no such file. The message itself looks a bit garbled, so I'm wondering if I need to do anything. ++ kevin = Message begins: INFO: unpack Applying gtk+-1.2.10-m4.patch ... Applying gtk+-1.2.10-r8-gentoo.diff.bz2 ... Applying gtk+-1.2-locale_fix.patch ... Running elibtoolize in: gtk+-1.2.10 Applying portage-1.3.4.patch ... Applying sed-1.5.6.patch ... Applying tmp-1.3.5.patch ... Applying uclibc-ltconf-1.3.0.patch ... INFO: postinst The old gtkrc is available through the new Gentoo gtk theme. WARN: postinst Older versions added /etc/X11/gtk/gtkrc which changed settings for all themes it seems. Please remove it manually as it will not due to /env protection. -- Kevin O'Gorman, PhD -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: Patch via perl script in an ebuild?
On Thu, Jul 1, 2010 at 11:45 PM, Grant wrote:
> [snip]
>
>> # Copyright 1999-2010 Gentoo Foundation
>> # Distributed under the terms of the GNU General Public License v2
>> # $Header: $
>>
>> EAPI="3"
>>
>> inherit perl-module
>>
>> DESCRIPTION="SOAP-WSDL provides a SOAP client with WSDL support."
>> HOMEPAGE="http://soap-wsdl.svn.sourceforge.net";
>> SRC_URI="http://soap-wsdl.svn.sourceforge.net/viewvc/soap-wsdl/SOAP-WSDL/branches/Typemap.tar.gz
>> -> ${P}.tar.gz"
>> LICENSE="Apache-2.0"
>> SLOT="0"
>> KEYWORDS="~amd64 ~x86"
>> IUSE="google"
>>
>> DEPEND="${RDEPEND}
>> virtual/perl-Module-Build"
>> RDEPEND="dev-perl/SOAP-Lite
>> dev-perl/Class-Std-Fast"
>>
>> src_prepare() {
>> if use google ; then
>> epatch "${FILESDIR}/${PN}.patch" | die "google patch failed"
>> fi
>> }
>
> David, you mentioned in the bug that you couldn't get the patch to
> work clean. I thought you got it working before when you posted the
> patched Typemap for me to download. Did it work then but not now?
>
> http://bugs.gentoo.org/show_bug.cgi?id=305621
>
> - GrantSOAP-WSDL
>
>
The patched Typemap created by hand works fine, but when you attempt
to use a downloaded SOAP-WSDL and patch it failed for me, may need to
manually create a patch for SOAP-WSDL.
--
David Abbott (dabbott)
Re: [gentoo-user] 3 - ERRORS
Holly Bostick wrote:
> Rumen Yotov schreef:
>
>>Joseph wrote:
>>
>>
>>
>>>How do you replace revdep-rebuild, it is not in ebuild?
>>>I solved the problem by recompiling OO from source instead of binary.
>>>
>>>
>>>
>>
>>Hi,
>>Revdep-rebuild is in portage-package, as '/usr/bin/revdep-rebuild'.
>>It's a shell-script, no need to compile it, just to unpack/place it.
>>You could copy the new one over the old one (make a backup first).
>>Later check the flags/permissions etc.
>>HTH. Rumen
>
>
> Thanks for the info, but I notice that there's also a patch to
> portage.py attached to the bug. Is it correct to just patch it with the
> standard "patch -p1 blah blah blah" (patch syntax doesn't roll
> trippingly off my typing finger, but I'll look it up before proceeding)?
>
> Is this "safe" (insofar as it's patching a portage file, unlike
> revdep-rebuild itself)?
>
> Holly
Hi Holly,
Safe? If you use the patch -b option it will automatically make a backup called
portage.py.orig in case you want to reverse the changes.
cd /usr/lib/portage/pym
patch -b -p0 < /tmp/revdep-rebuild-portage.py.patch
python -c "import compileall; compileall.compile_dir('`pwd`')"
python -O -c "import compileall; compileall.compile_dir('`pwd`')"
Zac
--
gentoo-user@gentoo.org mailing list
[gentoo-user] nvidia-drivers-340.76 failed with gentoo-sources-4.0.5
Hi all, Because of an old graphic card, i have to compile nvidia-drivers-340.76. nvidia-drivers-340.76 does not compile with the new 4.0.5 kernel. Here is the output error : /var/tmp/portage/x11-drivers/nvidia-drivers-340.76/work/kernel/nv-pat.o] Error 1 I saw a topic about that problem on Gentoo forum : https://forums.gentoo.org/viewtopic-p-7754020.html?sid=3b9fed3069c0b6644c1a41e839455b85 I tried to apply the patch /etc/portage/patches/x11-drivers/nvidia-drivers/nvidia-drivers-340.76.patch *--- a/kernel/nv-pat.c.orig * *+++ b/kernel/nv-pat.c * *@@ -35,8 +35,13 @@ * * unsigned long cr0 = read_cr0(); * * write_cr0(((cr0 & (0xdfff)) | 0x4000)); * * wbinvd(); * *+if LINUX_VERSION_CODE < KERNEL_VERSION(3, 20, 0) * * *cr4 = read_cr4(); * * if (*cr4 & 0x80) write_cr4(*cr4 & ~0x80); * *+else * *+*cr4 = __read_cr4(); * *+if (*cr4 & 0x80) __write_cr4(*cr4 & ~0x80); * *+endif * * __flush_tlb(); * * } * *@@ -46,7 +51,11 @@ * * wbinvd(); * * __flush_tlb(); * * write_cr0((cr0 & 0x9fff)); * *+if LINUX_VERSION_CODE < KERNEL_VERSION(3, 20, 0) * * if (cr4 & 0x80) write_cr4(cr4); * *+else * *+if (cr4 & 0x80) __write_cr4(cr4); * *+endif * * } * * static int nv_determine_pat_mode(void)* This patch does not work ; i get the error * Failed Patch: nvidia-drivers-340.76.patch ! * ( /etc/portage/patches//x11-drivers/nvidia-drivers/nvidia-drivers-340.76.patch ) Any idea ? Thanks a lot, Cheers, *--* *Jacques*
Re: [gentoo-user] Howto patch ebuilds?
Leonardo wrote:
> Thanks Rumen,
> that was it; now I have problems applying the patch, but I think
> I can figure it out.
>
> Thanks to Neil too.
>
> Ciao, Leo
>
> --- Rumen Yotov <[EMAIL PROTECTED]> wrote:
>> Hi,
>> If you don't have portage-overlay configured:
>> #mkdir /usr/local/portage
>> #echo "PORTDIR_OVERLAY=/usr/local/portage" >> /etc/make.conf
>> ...SKIP ABOVE... if PORTDIR_OVERLAY etc. already there
>> category=category package belongs to (e.g. sys-apps)
>> package=package-name (e.g. 'acl')
>> #mkdir /usr/local/portage/$category
>> #mkdir /usr/local/portage/$category/$package
>> #cp -arv /usr/portage/$category/$package/*
>> /usr/local/portage/$category/$package
>> copy "patch-name..." in
>> /usr/local/portage/$category/$package/files
>> Edit
>>
> /usr/local/portage/$category/$package/$package-version-rev.ebuild
>> adding in src_unpack() function:
>> epatch ${FILESDIR}/"patch-name..."
>> Save&exit
>> #ebuild
>>
> /usr/local/portage/$category/$package/$package-version-rev.ebuild
>> digest
>> #emerge $category/$package -av
>> Hope i didn't screwed something so check it again (some things
>> might be
>> made shorter though).
>> HTH.Rumen
>>
>
>
> __
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
Hi,
To trouble-shoot the patching process try the following:
1.Comment the "epatch ..." line in src_unpack();
#ebuild /usr/local/portage/$category/$package-version-rev.ebuild unpack
#cd /var/tmp/portage/$package-version-rev./work/$package-version-rev./
patch -pX[0|1|2] --dry-run -i /path/to/patch/file/file-patch
Watch for errors, if any.
If patching is successful run:
#ebuild /usr/local/portage/$category/$package-version-rev.ebuild compile
#ebuild /usr/local/portage/$category/$package-version-rev.ebuild install
#ebuild /usr/local/portage/$category/$package-version-rev.ebuild qmerge
#ebuild /usr/local/portage/$category/$package-version-rev.ebuild clean
Last one is optional (it just cleans the WORKDIR under /var/tmp/portage)
Replace "epatch ..." with patch...-optional(watch out for path issues).
PS: please don't top-post (preferred ML-policy).
HTH.Rumen
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [gentoo-user] lm_sensors patch borked?
The patch was borked. Either bump to latest sys-devel/patch-2.6.1 or resync later. It is fixed now. signature.asc Description: OpenPGP digital signature
[gentoo-user] Portage Patch failed to apply - System will no longer upgrade
Hi. This issue is really pissing me off, I have ried almost all the fixes, even to the point of booting and copying a Stage3 tarball over the running system and doing a Stage3 Install. No matter what I do, and for almost ALL packages I get .. * Portage patch failed to apply (ltmain.sh version 1.5.24)! * Please bug azarah or vapier to add proper patch. * * ERROR: dev-libs/gmp-4.3.1 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 2811: Called elibtoolize * environment, line 1065: Called die * The specific snippet of code: * die "Portage patch failed to apply!"; * The die message: * Portage patch failed to apply! For this package and everything else I wish to apply, this is locking my system in time so I can no longer upgrade any software ;o(
Re: [gentoo-user] Software Suspend2 using Gentoo Ebuilds - New Magazine MyOSS Mag
On Mon, 2005-04-18 at 14:18 +0200, Robert Svoboda wrote: > * Nick Rout <[EMAIL PROTECTED]> [2005-04-17 04:40]: > > - is it possible to patch the gentoo-sources kernel with the suspend2 > > patch? Or will it only apply cleanly to a vanilla kernel? > > I patched my standard gentoo kernel this way: > > http://onyon.net/index.php/2005-02-18_16.00.28_swsuspondelllatituded800 > > When you run apply and it complains about not being able to > patch kernel cleanly move that patch out of the way and rerun > apply, repeat this until all working patches are applied. Not everything will patch completely or cleanly. Some manual intervention will need to be done. > > Robert -- Ow Mun Heng Gentoo/Linux on DELL D600 1.4Ghz 98% Microsoft(tm) Free!! Neuromancer 11:29:59 up 20:05, 5 users, load average: 0.10, 0.33, 0.39 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] can't build gnome 3.2 (3.0 was ok)
On Wed, Oct 12 2011, David Abbott wrote: > Here is the patch to fix totem-pl-parser with the new quvi api > https://386651.bugs.gentoo.org/attachment.cgi?id=289447&action=diff&collapsed=&context=patch&format=raw&headers=1 > HTH > David Thank you. I follow that bug and know about the patch. Since I don't need totem on that machine, at least for now, I am waiting for this or another patch to make it into the official tree. thanks again, allan
Re: [gentoo-user] "xyz.la seems to be moved" message
On Tue, 2006-10-24 at 17:31 +0200, Fabrice Delliaux wrote: > Hi, > > Explanation && patch here : > > http://www.mail-archive.com/bug-libtool@gnu.org/msg00838.html I saved the patch at the above link to /root/libtool.patch, but I can't figure out how to use it. I assume that I would need to navigate to a directory and say "patch < /root/libtool.patch", but what directory do I do it from? If I do it from /usr/share/libtool, I get this: camille libtool # patch
Re: [gentoo-user] Nvidia Drivers. =(
Looks like a good patch but can you link to instructions for applying this patch? Fabio Scaccabarozzi wrote: > > Hi Alan, > > That is expected with 4.10 kernels. > You can grab a patch from my /etc/portage repository: > https://github.com/fsvm88/gentoo-portage_etc/blob/master/patches/x11-drivers/nvidia-drivers/378.09-4.10-rc8.patch > > I took it from the NVidia forums, you can also find it there, I just > rebased it for portage. > -- Strange Game. The only winning move is not to play. Powers are not rights.
Re: [gentoo-user] Dirty COW, 4.4.8-hardened-r1 how to fix?
Sorry about noticing your reply only now. Namely, thinking that people over at hardened ML would tell more about it, I indirectly initiated a thread over at hardened ML: https://archives.gentoo.org/gentoo-hardened/message/09bbf3bfe59a938f11ac044e891db77e Will surely check it! And am CC'ing hardened about this patch at the hardened ML. Maybe they patch and forward the 4.4.8-r1 to 4.4.8-r2 . --- Only now looked at the patch. No, you don't get it. And I'm not CC'ing this to hardened ML. You can't just run the patch for a vanilla kernel onto a grsecurity-patched kernel. Look up the hardened-sources, and how they are patched, and what the mm.h and the gup.c in question (there are a few of so named files in various directories) look in the hardened-sources, and how they look in the vanilla-sources... If I'm not mistaken, and I did check it. No, I'm not mistaken, you just sent me the Linus's patch. No, wrong. But thanks for trying to help! On 161025-13:16-0400, Fernando Rodriguez wrote: > On Tue, Oct 25, 2016 at 07:11:54AM +0200, Miroslav Rovis wrote: > > On 161021-11:04-0400, Rich Freeman wrote: > > > On Fri, Oct 21, 2016 at 10:49 AM, Mick wrote: > > > > https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails > > > > > > Not yet: > > > https://bugs.gentoo.org/show_bug.cgi?id=597624 > > > > > > > We are talking grsecurity-patched (kind of stable[*]) kernel sources, > > the =sys-kernel/hardened-sources-4.4.8-r1 package [**]. > > > > I read most of the discussion, and I could easily patch the gup.c and > > mm.h in question, but those files need to be patched before application > > of the grsecurity patch, and that is a little more complex work. > > Did you tried it? > The patch attached comes straight from the git repo, just run: > > # cd /usr/src/linux > # patch -p1 < path/to/patch > > It'll likely work. > > > > > Has anybody done this, as I have limited time available to practice user > > patching (which in its simplest form, I was able to do here: > > >=dev-libs/nss-3.24 - Add USE flag to enable SSL key > > https://bugs.gentoo.org/show_bug.cgi?id=587116#c2 ), in case it can be > > done with user patching, of course. > > > > Anyone? > > > > Regards! > > --- > > [*] kind of stable, because there are, since about 1 yrs ago, only > > testing kernel available for the non-paying users ;-( > > > > [**] I have to use 4.4.8.r1 because recent kernel all crash with libirt > > and qemu which I am trying to use: > > https://bugs.gentoo.org/show_bug.cgi?id=597554 > > -- > > Miroslav Rovis > > Zagreb, Croatia > > http://www.CroatiaFidelis.hr > > > > -- > Fernando Rodriguez > commit 1294d355881cc5c3421d24fee512f16974addb6c > Author: Linus Torvalds > Date: Thu Oct 13 13:07:36 2016 -0700 > > mm: remove gup_flags FOLL_WRITE games from __get_user_pages() > ... Thanks for trying to help! Regards! -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr signature.asc Description: Digital signature
Re: [gentoo-user] Re: Patch via perl script in an ebuild?
Grant wrote:Grant wrote: >> I need to install the google-api-adwords-perl library, and it requires >> that SOAP-WSDL is patched with the soap_wsdl_patches.pl perl script. >> Can I have SOAP-WSDL patched via the perl script in an ebuild? >> >> - Grant >> > Here is the perl script: > > http://pastebin.com/YM3G5sKn > > Can anyone with perl and ebuild knowledge determine if the script > could be incorporated into an ebuild? David Abbott and I are working > on getting google-api-adwords-perl into portage and this is a > dependency. (Some preliminary setup work, like cpan -i Text::Patch SOAP::WSDL.) Running the patch after fixing its paths ... will result invariably in: Trying to patch /usr/lib64/perl5/site_perl/5.10.1/SOAP/WSDL/XSD/Typelib/Builtin/anySimpleType.pm...Hunk #1 failed at line 13. I'm no authority on perl, but AFAICT that patch does not match against either SOAP::WSDL latest stable sources nor latest SOAP::WSDL dev release code from CPAN. Actually, I couldn't find tarballs from CPAN which would match with the failing lines of that patch. There might've been some earlier 2.00-series releases, but they're ... long gone? Any idea of the version of SOAP::WSDL they are using for this at Google? -- Arttu V. -- Running Gentoo is like running with scissors
Re: [gentoo-user] Adding an extra patch to an ebuild
On Wed, Nov 21, 2012 at 9:46 AM, Helmut Jarausch wrote: > On 11/21/2012 09:38:26 AM, Adam Carter wrote: >> >> It looks like i have hit this gcc 4.7 build bug: >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113 >> >> Theres a patch attached to the bug i'd like to apply. Unfortunately the >> gcc >> 4.7.2 ebuild doesnt have "epatch_user", so i need to take the other >> approach listed in the handbook. It suggests i use a custom environment >> but >> i dont understand how i would apply a patch by setting an environment >> variable. Can anyone explain? >> > > Please have a look at > > http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&chap=6 > > /etc/portage/patches > > Helmut. > This requires the ebuild to use epatch_user. Adam, I don't it is possible to use the 'evn' file to patch an ebuild. Either edit the ebuild directly and add your patch or open a bug asking the toolchain maintainers to add epatch_user to gcc. But I have to say, it is easier if you just edit the ebuild, add the epatch_user line there, run ebuild digest and then place your patch in /etc/portage/patches. You should then be able to build gcc just fine. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-user] webkit-gtk-2.4.11-r200::gentoo failed (compile phase)
On 02/18/2018 12:14 PM, Neil Bothwick wrote: > On Sun, 18 Feb 2018 12:01:54 -0700, the...@sys-concept.com wrote: > >> I've tried this propose patch. >> https://621532.bugs.gentoo.org/attachment.cgi?id=511304 >> >> save it to a file patch.patch >> went to directory: >> cd /usr/portage/net-libs/webkit-gtk/ >> patch -p0 < patch.patch >> >> It ask me what file I want to patch, I entered: >> JSStringRef.h >> >> run: >> ebuild /usr/portage/net-libs/webkit-gtk/webkit-gtk-2.4.11-r200.ebuild >> digest >> >> But it still fails to compile. >> Am I applying patch the same way. > > The patch is to be applied to the source files, not the ebuild > > mkdir /etc/portage/patches/net-libs/webkit-gtk/webkit-gtk-2.4.11-r200 > then copy the patch file to that directory and portage will apply it to > the source after unpacking. Did not work. ll /etc/portage/patches/net-libs/webkit-gtk/webkit-gtk-2.4.11-r200 total 4 -rw-r--r-- 1 thelma thelma 525 Feb 18 10:54 patch.patch emerge webkit-gtk produces same error message. make[1]: Leaving directory '/var/tmp/portage/net-libs/webkit-gtk-2.4.11-r200/work/webkitgtk-2.4.11' make: *** [GNUmakefile:25837: all] Error 2 * ERROR: net-libs/webkit-gtk-2.4.11-r200::gentoo failed (compile phase): * emake failed Thelma
Re: [gentoo-user] netqmail fails to do CNAME lookup for lists.gentoo.org
Am Sonntag, 24. März 2013, 01:39:17 schrieb Sascha Cunz:
> Am Sonntag, 24. März 2013, 00:46:56 schrieb Sascha Cunz:
> [...]
>
> I've meanwhile found out that it might be related to a DNS lookup bug inside
> qmail and found an old patch that should addresses this issue. The patch is
> short and looking innocent to me, so I've now setup a local overlay and am
> trying to send this out without the smtproute, once again.
>
> Sascha
Okay, this last mail went through smoothly and without any trouble in log
files.
Since I got private mails from others having the same problem, here's exactly
what I did to solve this:
- Create a local overlay
- copy the mail-mta/netmail directory from portage tree
- wget http://www.ckdhr.com/ckd/qmail-103.patch
to the files directory.
- copy netmail-1.06.ebuild to netmail-1.06-r1.ebuild
- insert "epatch "${FILESDIR}"/qmail-103.patch" before the first epatch in
src_unpack()
- rebuild manifest, add the overlay and rebuild netmail
- restart svscan.
This patch from Christopher Davis is actually dated back to 1998; I'm not sure
about copyright issues on the patch, but it seems trivially simple.
Though, I'm wondering why such a simple fix isn't already part of the netmail
ebuild.
Sascha
Re: [gentoo-user] lm_sensors patch borked?
On 28 June 2010 15:40, justin wrote: > The patch was borked. Either bump to latest sys-devel/patch-2.6.1 or > resync later. It is fixed now. Thanks, will have another go. -- Regards, Mick
Re: [gentoo-user] zd1211 patch?
On Tue, 8 May 2007, Arnau Bria wrote: > On Tue, 8 May 2007 17:22:32 +0200 > Alan McKinnon wrote: > > Hi! > > > On Tuesday 08 May 2007, Arnau Bria wrote: > > > For what I understand, I must modify zd1211-83.ebuild, and rebuild > > > the ebuild with: > > > ebuild zd1211-83.ebuild digest (which worked fine) > > > > > > but, what should be the content of /tmp/net_dev.patch > > > > You list two patches. > > > > The one for the ebuild you should apply to the ebuild manually > > using 'patch', but you seem to have successfully done that already. > Yep, > > > Then copy the first patch (net_dev.patch) > Ok, but, what is the content of net_dev.patch? if I put: > # cat files/net_dev.patch > EXTRA_CFLAGS += -O2 -Wall -Wstrict-prototypes -pipe > #EXTRA_CFLAGS += -Wa,-a,-ad -g > -EXTRA_CFLAGS += -DZDCONF_WE_STAT_SUPPORT=1 > +EXTRA_CFLAGS += -DZDCONF_WE_STAT_SUPPORT=0 > EXTRA_CFLAGS += -DHOST_IF_USB > EXTRA_CFLAGS += -DAMAC > EXTRA_CFLAGS += -DGCCK You need to copy the whole patch file exactly, including whitespace. Go to https://bugs.gentoo.org/attachment.cgi?id=108347 and save as netdev.patch. (This paragraph isn't critical, but if you want to understand patch/diff...) In particular, you seem to have lost the "diff" line, the --- and +++ lines (which tell it what file to patch), the @@ ... @@ line (which tells it where to look for the thing to change), the blank line that shouldn't be changed, and the space characters in the first columns of the context lines that tell it that those are context instead of changes. So "patch" has decided that the contents of that file are too damaged for it to use. In particular, it has no chance without any of the first three lines, because it doesn't know what file to use and can't guess. -Daniel *This .sig left intentionally blank*
[gentoo-user] Fwd: Re: PATCH: "postfix start" master initialization status
when this patch is going to get into the portage?? thanks Eliezer Original Message Subject: Re: PATCH: "postfix start" master initialization status Date: Wed, 7 Mar 2012 11:56:38 +0200 From: Eray Aslan To: postfix-us...@postfix.org On Tue, Mar 06, 2012 at 08:00:58PM -0500, Wietse Venema wrote: This works around a problem on some Linux systems. These don't use "postfix status" to find out if the mail system still runs. Fixed. # /etc/init.d/postfix status * postfix/postfix-script: the Postfix mail system is running: PID: 26257 [ ok ] Even worse, they refuse to start Postfix when the problem is fixed, claiming that Postfix is still running! Fixed as well. The feature patch addresses only the start-up side of the issue. Location on the source code mirrors: postfix-release/experimental/feature-patches/20120206-master-monitor-patch postfix-release/experimental/feature-patches/20120206-master-monitor-patch.sig I had to use the attached patch (on top of the above) to avoid erroring out during compile. FYI. The patch behaves as expected. postfix start waits for master to initialize before returning with the correct return code. There is no noticeable delay during startup with a correct configuration. Differences are within margin of error. There is less incentive to start master directly. Thanks again. -- Eray Aslan --- src/master/Makefile.in 2012-01-22 17:55:16.0 +0200 +++ src/master/Makefile.in 2012-03-07 11:10:55.255442235 +0200 @@ -2,10 +2,12 @@ SRCS = master.c master_conf.c master_ent.c master_sig.c master_avail.c \ master_spawn.c master_service.c master_status.c master_listen.c \ master_proto.c single_server.c multi_server.c master_vars.c \ - master_wakeup.c master_flow.c master_watch.c mail_flow.c + master_wakeup.c master_flow.c master_watch.c mail_flow.c \ + master_monitor.c OBJS = master.o master_conf.o master_ent.o master_sig.o master_avail.o \ master_spawn.o master_service.o master_status.o master_listen.o \ - master_vars.o master_wakeup.o master_watch.o master_flow.o + master_vars.o master_wakeup.o master_watch.o master_flow.o \ + master_monitor.o LIB_OBJ= single_server.o multi_server.o trigger_server.o master_proto.o \ mail_flow.o event_server.o HDRS = mail_server.h master_proto.h mail_flow.h
Re: [gentoo-user] Intel HDA soundcard, microphones and skype
On 10/11/06, Matthew R. Lee <[EMAIL PROTECTED]> wrote: The arecord apeared to work, but when I played it back with aplay - silence! At this point you may want to try the patch that you found on the forums. Unfortunately it doesn't apply cleanly against 1.0.13, and the original patch author didn't release it under any defined licensing terms, so it isn't legal for me to update it for 1.0.13 and publish it. So you will either have to downgrade to 1.0.11 and use his patch as-is, or pester him for an update to .13, or even better re-publish his patch under the GPL like the rest of alsa. If you want to use the patch as-is, copy and save it to a file, such as conexant.patch. Then download alsa-driver-1.0.11.tar.bz2 from [1], and put it in the same directory as the patch. Then run (as root): tar -xjf alsa-driver-1.0.11.tar.bz2 cd alsa-driver-1.0.11 patch -p1 --ignore-whitespace < ../conexant.patch patching file alsa-kernel/pci/hda/hda_patch.h patching file alsa-kernel/pci/hda/Makefile patching file alsa-kernel/pci/hda/patch_conexant.c patching file pci/hda/patch_conexant.c ./configure --with-cards=hda-intel [configure output omitted] make && make install && /etc/init.d/alsasound restart [make output omitted] This should work, but if you have problems (like crashes, devices not being found, etc), you might need to downgrade alsa-lib, alsa-plugins, alsa-firmware, alsa-headers, alsa-tools, and alsa-utils to version 1.0.11 as well with /etc/portage/package.mask. HTH, -Richard [1] ftp://ftp.alsa-project.org/pub/driver/ -- gentoo-user@gentoo.org mailing list
[gentoo-user] Help applying a qt patch
I've set the ebuild up in an overlay and added:
epatch ${FILESDIR}/qt-4.3.1-r1_gcc3.4_compile_fix.diff
to the ebuild alongside other patches, but the patch always fails with this:
^[[31;01mACCESS DENIED^[[0m rename:
/usr/portage/x11-libs/qt/qt-4.3.1-r1.ebuild
patch: Can't rename file
/var/tmp/portage/x11-libs/qt-4.3.1-r1/temp/poIOMqJi to
/usr/portage/x11-libs/qt/qt-4.3.1-r1.ebuild : Permission denied
Here is the patch which reportedly works great:
http://bugs.gentoo.org/attachment.cgi?id=131080&action=view
Could someone tell me what I'm doing wrong?
- Grant
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-user] Patch file for cdrtools to allow --duplicates-once
Andrey Vul wrote: > Is there a patch file to patch mkisofs to use the --duplicates-once > option during generation of iso9960/UDF images? > The problem is that the one that exists right now, the patch (against > the official sources) cannot be found because the original site > (bootcd.ru) is permanently down. > Or do I need to make a table of SHA-1s to weed out the identical files? > I found this link: http://www.911cd.net/forums/lofiversion/index.php/t15282-350.html I'm not sure it will help but may be worth a look. Dale :-) :-)
Re: [gentoo-user] Software Suspend2 using Gentoo Ebuilds - New Magazine MyOSS Mag
* Nick Rout <[EMAIL PROTECTED]> [2005-04-17 04:40]: > - is it possible to patch the gentoo-sources kernel with the suspend2 > patch? Or will it only apply cleanly to a vanilla kernel? I patched my standard gentoo kernel this way: http://onyon.net/index.php/2005-02-18_16.00.28_swsuspondelllatituded800 When you run apply and it complains about not being able to patch kernel cleanly move that patch out of the way and rerun apply, repeat this until all working patches are applied. Robert -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Nvidia-drivers fails to patch
On Thu, Apr 20, 2023 at 3:36 PM Dale wrote: > * patch -p1 failed with > /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch You know I don't run Gentoo, right? That looks weird to me - building 470.182.03 but patching it with 470.141.03. Just looks weird... I think the other day someone - maybe Thelma? - had a problem where there was something left over in some 'patch' directory. Possibly you have something like that going on? You know I don't run Gentoo, right? ;-) Cheers, Mark
[gentoo-user] Re: VIA K8M890/K8M880 (VT8251) supported?
>> Googling revealed, that the SATA-ports in the VT8251 _should_ be >> AHCI-compliant and therefor supported by Linux. > > vt8251 *is* ahci-compliant, and in bios there is option to set > up sata controller as ide, or ahci. But no matter what you set, > vt8251/sata is not recognised with standard 2.6.15 kernel... > > But there is unofficial patch/mod for ahci.c, and right now > I'm testing it. BTW, I have read on via forum that kernel-dev's > refused to include this patch in official kernel tree, because > there is something peculiar about it (some fix they do not like). > BTW, it's made by via and modified by some developers... IMHO, the patch should only include the PCI-Id or something like that - well, but the patch doesn't seem to be as simple as that. Do you have a link to the patch? or even a link to the discussion in the LKML? Thanks Sven signature.asc Description: OpenPGP digital signature
[gentoo-user] Re: /etc/portage/bashrc - patches
On 15/04/18 03:30, the...@sys-concept.com wrote: I'm trying to patch audacity-2.1.3-r1 (as it fails to compile) with the patch provided in Gentoo-Bug forum: https://bugs.gentoo.org/show_bug.cgi?id=618326 I've edited the /etc/portage/bashrc: https://wiki.gentoo.org/wiki//etc/portage/patches#Enabling_.2Fetc.2Fportage.2Fpatches_for_all_ebuilds You don't need that. In fact I wouldn't be surprised if you broke something by doing that. Undo the change. Putting the patch into: /etc/portage/patches/media-sound/audacity-2.1.3-r1/TrackPanel-Track-GetRate.patch is enough. The user patches are applied automatically when the ebuild in question uses EAPI 6, or it inherits eutils. audacity-2.1.3-r1.ebuild does the latter. When emerging, you will see this in the log: Applying user patches TrackPanel-Track-GetRate.patch That's how you know it's working. If the build still fails, it's not due to the patch not having been applied. It's that the patch didn't actually fix your issue.
Re: [gentoo-user] Checksum error
meino.cra...@gmx.de wrote:
> Hi,
>
> I am currently doing a python-updater run. While the rebuilding
> of the several packages the process failed with
>
> >>> Downloading
> 'http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patch.4.7.25.4'
> --2009-10-11 10:57:48--
> http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patch.4.7.25.4
> Resolving www.oracle.com... 80.157.150.10, 80.157.150.33
> Connecting to www.oracle.com|80.157.150.10|:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 5647 (5.5K) [application/octet-stream]
> Saving to: `/usr/portage/distfiles/patch.4.7.25.4'
>
>
> 100%[>]
> 5,647 --.-K/s in 0.04s
>
> 2009-10-11 10:57:48 (135 KB/s) - `/usr/portage/distfiles/patch.4.7.25.4'
> saved [5647/5647]
>
> ('Filesize does not match recorded size', 5647L, 5500)
> !!! Fetched file: patch.4.7.25.4 VERIFY FAILED!
> !!! Reason: Filesize does not match recorded size
> !!! Got: 5647
> !!! Expected: 5500
> Refetching... File renamed to
> '/usr/portage/distfiles/patch.4.7.25.4._checksum_failure_.B3kSP2'
>
>
>
> How can I proceed?
>
> Have a nice weekend!
> Best regards,
> mcc
>
>
>
You may want to re-sync. Sometimes that works and is easy enough to do.
I guess files sort of cross paths and don't match. Otherwise, check man
emerge. There is a way to redigest the file. Only do this if you trust
the source tho. The reason for that check is to make sure you get a
unaltered file.
You could also try downloading from a different server too. Could be
that the file is bad or corrupt in some way.
Dale
:-) :-)
Re: [gentoo-user] Howto patch ebuilds?
--- Rumen Yotov <[EMAIL PROTECTED]> wrote: > Hi, > To trouble-shoot the patching process try the following: > 1.Comment the "epatch ..." line in src_unpack(); > #ebuild > /usr/local/portage/$category/$package-version-rev.ebuild > unpack > #cd > /var/tmp/portage/$package-version-rev./work/$package-version-rev./ > patch -pX[0|1|2] --dry-run -i /path/to/patch/file/file-patch > Watch for errors, if any. > If patching is successful run: > #ebuild > /usr/local/portage/$category/$package-version-rev.ebuild > compile > #ebuild > /usr/local/portage/$category/$package-version-rev.ebuild > install > #ebuild > /usr/local/portage/$category/$package-version-rev.ebuild > qmerge > #ebuild > /usr/local/portage/$category/$package-version-rev.ebuild clean > Last one is optional (it just cleans the WORKDIR under > /var/tmp/portage) > Replace "epatch ..." with patch...-optional(watch out for path > issues). > PS: please don't top-post (preferred ML-policy). > HTH.Rumen > Hi Rumen, thanks, the patch was supposed to be applied to a previous version of the ebuild; by masking and emerging the correct version it worked. Sorry for top-posting (I should have read the policy ;P ) Bo, thanks to you too. Now please, stop it, is it possible that a such simple post gives so much feedback!!? No, kidding, thanks again, it's nice to get in contact with you all. Ciao, Leo __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] netqmail fails to do CNAME lookup for lists.gentoo.org
On Mar 24, 2013 5:30 PM, "Sascha Cunz" wrote:
>
> Am Sonntag, 24. März 2013, 01:39:17 schrieb Sascha Cunz:
> > Am Sonntag, 24. März 2013, 00:46:56 schrieb Sascha Cunz:
> > [...]
> >
> > I've meanwhile found out that it might be related to a DNS lookup bug
inside
> > qmail and found an old patch that should addresses this issue. The
patch is
> > short and looking innocent to me, so I've now setup a local overlay and
am
> > trying to send this out without the smtproute, once again.
> >
> > Sascha
>
> Okay, this last mail went through smoothly and without any trouble in log
> files.
>
> Since I got private mails from others having the same problem, here's
exactly
> what I did to solve this:
>
> - Create a local overlay
>
> - copy the mail-mta/netmail directory from portage tree
>
> - wget http://www.ckdhr.com/ckd/qmail-103.patch
> to the files directory.
>
> - copy netmail-1.06.ebuild to netmail-1.06-r1.ebuild
>
> - insert "epatch "${FILESDIR}"/qmail-103.patch" before the first epatch in
> src_unpack()
>
> - rebuild manifest, add the overlay and rebuild netmail
>
> - restart svscan.
>
> This patch from Christopher Davis is actually dated back to 1998; I'm not
sure
> about copyright issues on the patch, but it seems trivially simple.
>
> Though, I'm wondering why such a simple fix isn't already part of the
netmail
> ebuild.
>
> Sascha
>
Thanks for posting the fix! :-)
Now, how about filling a bug... ;-)
Rgds,
--
Re: [gentoo-user] Re: Apache not starting after upgrading Apache/glibc...
Matthias Hanft wrote: > > So it seems that I cannot emerge "patch" because I need to patch > "patch" :-( Am I stuck now??? What to do?? I copied "/usr/bin/patch" from another (glibc-2.27) Gentoo system. Patching now works, but at every emerge (for example, binutils), I get something like checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking for i686-pc-linux-gnu-gcc... i686-pc-linux-gnu-gcc checking whether the C compiler works... no configure: error: in `/var/tmp/portage/sys-devel/patch-2.7.6-r3/work/patch-2.7.6': configure: error: C compiler cannot create executables See `config.log' for more details Despite gcc was *not* recompiled after the glibc upgrade, it now tells $ gcc -o hello hello.c /usr/lib/gcc/i686-pc-linux-gnu/8.2.0/../../../../i686-pc-linux-gnu/bin/as: /lib/libc.so.6: version `GLIBC_2.28' not found (required by /usr/lib/binutils/i686-pc-linux-gnu/2.31.1/libbfd-2.31.1.gentoo-sys-devel-binutils-st.so) Argh!!! I *do* have another working Gentoo system (with the old glibc 2.27 and Apache 2.4.38 and all binutils and all that - everything is still fine there). Can I use this just to copy some files (libs) to the "sick" system? Just until I can re-emerge everything into a consistent state there? -Matt
[gentoo-user] Acer SmartBattery support
Hi list, just now my Acer TM2313 is emerging system at home. If I return home from work I plan to complete the installation. My question: Is gentoo-sources patched with the acpi_sbs patch or will I need to get it somewhere and patch it myself? Googling around I found (on the Gentoo forum ;) that the latest release is acpi_sbs-20050119. Well I got acpi_sbs-20050120 right now. The posts on the forum are quite old. The patch is for a linux-2.6.10 kernel. Has anyone experiences with a recent kernel in portage and this patch? Thanks in advance Frank -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Out of portage
On Wed, 9 Nov 2005 10:23:31 +0200, Eray Aslan wrote: > > You'll just have to keep an eye for upgrades, because they > > will probably come without this patch. If you want this patch to be > > included in postfix create a bug in bugzilla with the request. > > I don't think it is a good idea. I would not second guess Wietse > (author of postfix) for the suitability of the patch for general > consumption. The patch could be made optional, enabled by a USE flag. -- Neil Bothwick "It compiled? The first screen came up? Ship it!" -- Bill Gates signature.asc Description: PGP signature
Re: [gentoo-user] custom ebuilds
On 9/16/06, David Relson <[EMAIL PROTECTED]> wrote: Greetings, I recently noticed a keyboard problem (ctrl left arrow moves a word to the _right_ when using the numeric keypad) and now have a patch for GTK, specifically file gtk+-2.8.19/gtk/gtktextview.c. What's the best way to create a personalized ebuild to include this fix when I build? http://gentoo-wiki.com/HOWTO_Create_an_Updated_Ebuild You can use the current -xinerama.patch for gtk as a model for creating/applying your patch. What's the best way to get this patch included in the official ebuild? File a new bug report on bugs.gentoo.org, and attach your patch to it. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] zd1211 patch?
On Tuesday 08 May 2007, Arnau Bria wrote: > Ok, but, what is the content of net_dev.patch? It's right there in your original mail: diff -Naur /root/tmp-old/Makefile /root/tmp-new/Makefile --- /root/tmp-old/Makefile 2007-01-28 06:41:03.0 + +++ /root/tmp-new/Makefile 2007-01-28 06:39:54.0 + @@ -55,7 +55,7 @@ EXTRA_CFLAGS += -O2 -Wall -Wstrict-prototypes -pipe #EXTRA_CFLAGS += -Wa,-a,-ad -g -EXTRA_CFLAGS += -DZDCONF_WE_STAT_SUPPORT=1 +EXTRA_CFLAGS += -DZDCONF_WE_STAT_SUPPORT=0 EXTRA_CFLAGS += -DHOST_IF_USB EXTRA_CFLAGS += -DAMAC EXTRA_CFLAGS += -DGCCK That IS what the patch file looks like. It will alter your Makefile, and the epatch function in portage is smart enough to try apply the patch to the following files in order: /root/tmp-new/Makefile tmp-new/Makefile Makefile If that doesn't work, the patch itself is faulty for more info "man patch" alan -- Optimists say the glass is half full, Pessimists say the glass is half empty, Developers say wtf is the glass twice as big as it needs to be? Alan McKinnon alan at linuxholdings dot co dot za +27 82, double three seven, one nine three five -- [EMAIL PROTECTED] mailing list
[gentoo-user] ipset needs to patch the kernel?
Hi, this morning I was trying to emerge ipset (in order to use with sidmat) and got this instead of the executable: >>> Unpacking source... >>> Unpacking ipset-6.20.1.tar.bz2 to >>> /var/tmp/portage/net-firewall/ipset-6.20.1/work >>> Source unpacked in /var/tmp/portage/net-firewall/ipset-6.20.1/work >>> Preparing source in >>> /var/tmp/portage/net-firewall/ipset-6.20.1/work/ipset-6.20.1 ... * Sorry, but you have to patch kernel sources with the following patch: * # cd /usr/src/linux * # patch -i /var/tmp/portage/net-firewall/ipset-6.20.1/work/ipset-6.20.1/netlink.patch -p1 * You should recompile and run new kernel to avoid runtime errors. * ERROR: net-firewall/ipset-6.20.1::gentoo failed (prepare phase): * Unpatched kernel * I am runnung Linux 4.1.4 vanilla and asking myself, whether this patch is still be needed and whether there are other ways to accomplish what ipset would do ... I dont like the idea of patching the kernel in order to get some minor user land tools to run... Are there any other ways to acchieve the same ? Best regards, Meino
Re: [gentoo-user] Re: Patch via perl script in an ebuild?
>>> I need to install the google-api-adwords-perl library, and it requires >>> that SOAP-WSDL is patched with the soap_wsdl_patches.pl perl script. >>> Can I have SOAP-WSDL patched via the perl script in an ebuild? >>> >>> - Grant >>> >> Here is the perl script: >> >> http://pastebin.com/YM3G5sKn >> >> Can anyone with perl and ebuild knowledge determine if the script >> could be incorporated into an ebuild? David Abbott and I are working >> on getting google-api-adwords-perl into portage and this is a >> dependency. > > (Some preliminary setup work, like cpan -i Text::Patch SOAP::WSDL.) > > Running the patch after fixing its paths ... will result invariably in: > Trying to patch > /usr/lib64/perl5/site_perl/5.10.1/SOAP/WSDL/XSD/Typelib/Builtin/anySimpleType.pm...Hunk > #1 failed at line 13. > > I'm no authority on perl, but AFAICT that patch does not match against > either SOAP::WSDL latest stable sources nor latest SOAP::WSDL dev release > code from CPAN. Actually, I couldn't find tarballs from CPAN which would > match with the failing lines of that patch. There might've been some earlier > 2.00-series releases, but they're ... long gone? > > Any idea of the version of SOAP::WSDL they are using for this at Google? Thank you Arttu. Here is the link to the SOAP::WSDL: http://soap-wsdl.svn.sourceforge.net/viewvc/soap-wsdl/SOAP-WSDL/branches/Typemap.tar.gz?view=tar&pathrev=846 from the README: http://code.google.com/p/google-api-adwords-perl/source/browse/trunk/README - Grant
Re: [gentoo-user] Missing file so DIE; Seriously?!?!?!?
On Thursday, 24 January 2019 04:28:06 GMT Davyd McColl wrote: > On January 24, 2019 6:25:48 AM Alan Grimes wrote: > > 99.999% sure this is not my fault yet my build gets killed dead by it, > > no "Okay, let's see what other things we can build", just DIE!!! > > Have you tried --keep-going? > > > ## > > > >>>> Verifying ebuild manifests > > > > !!! A file listed in the Manifest could not be found: > > /usr/portage/dev-python/pygments/files/pygments-2.2.0-sphinx17.patch > > > > !!! A file listed in the Manifest could not be found: > > /usr/portage/dev-lang/ruby/files/2.4/012-openssl_1.1.patch > > > > !!! A file listed in the Manifest could not be found: > > /usr/portage/dev-lang/ruby/files/2.4/012-openssl_1.1.patch > > > > !!! A file listed in the Manifest could not be found: > > /usr/portage/dev-lang/ruby/files/2.4/012-openssl_1.1.patch > > > > !!! A file listed in the Manifest could not be found: > > /usr/portage/app-text/libetonyek/files/libetonyek-0.1.8-no-parentheses.pat > > ch !!! A file is not listed in the Manifest: > > '/usr/portage/kde-apps/kde-dev-utils/files/kde-dev-utils-18.04.3-ki18n-5.4 > > 8.patch' !!! A file is not listed in the Manifest: > > '/usr/portage/kde-apps/kwrite/files/kwrite-18.04.3-root-user.patch' > > > > !!! A file listed in the Manifest could not be found: > > /usr/portage/media-video/obs-studio/files/obs-studio-22.0.3-fdk-build-fix. > > patch rm -Rf /usr/portage/* emerge --sync Then repeat your world update. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Advice sought on the use of a VCS (specifically git) to keep track of my Softscroll patch.
On Thursday, 23 September 2021 20:23:57 CEST Alan Mackenzie wrote: > Where would I find a suitable kernel git repository to clone? An > "official" repository, whatever that means? Ideally, I want one with > just the various kernel releases, not one containing gigabytes of > 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 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 commits from upstream. However, this rewrites git history so you'd have to force push the branch to whatever remote you're tracking it in, so keep that in mind. You could do this though and additionally have another branch where you track the patch files themselves that are rebased onto a certain kernel commit (you can export them with "git format-patch upstream/master" if upstream/master is whatever branch the patch is currently rebased on). That of course you don't have to then force push. I hope this helps :P -Marco signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Shell echo missing after ctrl+c
Hello, Kai. On Sun, Mar 19, 2017 at 09:49:50 +0100, Kai Krakow wrote: > Hello! > More and more of my Gentoo systems are exhibiting the following > strange and unexpected behavior: > After ctrl+c'ing out of programs like tailf, SSH password prompts, in > the middle of a shell scripts, the shell echo is not restored - that > is: If I type characters I no longer see the characters (but they are > received and can be executed by "enter"). If experiencing this, I have > to ctrl+c again to discard what I was typing, the blindly type "reset" > to reset the terminal, then echo is enabled again. > I'm not sure which update or configuration is causing this. It started > out on our Gentoo servers some years ago (which I'm only SSH'ed into, > no physical access), now since a few weeks, also my desktop machines are > affected. I have no explanation for this. > But maybe anyone? > BTW: I know from the old times (some 15-20 years ago) that ctrl+c out > of a program (i.e. rsync) that starts a subshell (i.e. ssh) that in > turn shows a password prompt, will leave you with an echoless shell. > But it shows up on almost any occasion now. It's been happening to me increasingly often in the last few months/years. I don't like it. Here is a recipe for reproducing the phenomenon. A typical way of invoking patch is by supplying the patch file to standard input: $ patch --dry-run < some-patch-file.diff . However if you accidentally omit the "<", like this: $ patch --dry-run some-patch-file.diff , the terminal will await you typing in the patch file. Instead, do a ctrl-c. This leaves the terminal not echoing keystrokes. By the way, thanks for educating me about the existence of the command `reset'. :-) > -- > Regards, > Kai > Replies to list-only preferred. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: Any recent LVM changes?
On Tue, Jul 06, 2010 at 11:12:09AM -0700, walt wrote:
> I'm using all the same versions on my ~amd64 and having no problems.
> I just re-merged util-linux without errors, so it's worrisome that the
> patch fails. Filesystem corruption?
>
> Smells to me like hardware or even driver problems. Did you just
> recently update the kernel? Are the backup drives in a different
> enclosure or connected to a different controller? Cable problems?
> Flakey power supply? Machine overheating? Flakey memory? Overclocking?
I rebooted and everything is working again. I was on pins and needles
while waiting, but a backup went fine last night.
util-linux still complains:
>>> Preparing source in
/var/tmp/portage/sys-apps/util-linux-2.18/work/util-linux-ng-2.18 ...
* Applying util-linux-ng-2.17.1-20100308.diff ...
* Failed Patch: util-linux-ng-2.17.1-20100308.diff !
* (
/var/tmp/portage/sys-apps/util-linux-2.18/work/util-linux-ng-2.17.1-20100308.diff
)
*
* Include in your bugreport the contents of:
*
*
/var/tmp/portage/sys-apps/util-linux-2.18/temp/util-linux-ng-2.17.1-20100308.diff.out
and that log says
* util-linux-ng-2.17.1-20100308.diff *
======
PATCH COMMAND: patch -p0 -g0 -E --no-backup-if-mismatch <
'/var/tmp/portage/sys-apps/util-linux-2.18/work/util-linux-ng-2.17.1-20100308.diff'
======
can't find file to patch at input line 13
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|If this patch does not apply cleanly to newer version of util-linux-ng, try
|replacing original lomount.c lomount.h loop.h losetup.8 files in mount
|subdirectory with versions from util-linux-ng that the patch is for. And
|then apply this patch.
|
|mount/Makefile.in is a generated file. You can ignore patch failures on
that
|file if you generate it again by running the ./autogen.sh script. That
|./autogen.sh script needs recent versions of autohell tools.
|
|diff -urN util-linux-ng-2.17.1/mount/Makefile.am
util-linux-ng-2.17.1-AES/mount/Makefile.am
|--- util-linux-ng-2.17.1/mount/Makefile.am 2010-02-04 13:53:56.0
+0200
|+++ util-linux-ng-2.17.1-AES/mount/Makefile.am 2010-03-08
08:44:02.0 +0200
So I suppose I should open a bug on it. If it can't even find the
file, I don't think replacing existing files from elsewhere will do
any good. That also implies upstream will get things straightened out
sooner or later anyway.
--
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & rocket surgeon / fe...@crowfix.com
GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o
[gentoo-user] RE: elibtoolize Portage patch requested, but failed to apply!
Hi all, It's solved and it was my fault. I have had to put elt-patches in /etc/portage/profile/package.provided to compile new version of portage with success two days ago and I forget it . Have a good days ! Easy Service Informatique Erwan Rigollot Intervenant technique Easy Service Informatique 8 rue Saint Augustin - 75002 Paris Email: er...@easy-info.com Tel: +33 (0)1 42 96 06 71 Fax: +33 (0)1 42 96 41 72 De : Erwan RIGOLLOT [mailto:er...@rigollot.eu] Envoyé : lundi 27 mars 2017 13:41 À : gentoo-user@lists.gentoo.org Objet : [gentoo-user] elibtoolize Portage patch requested, but failed to apply! Hi all, I just did an emerge -sync and a porting update on two gentoo. Some packages do not want to compile anymore. Exemples gcc : * updating multilib directories to be: ../lib64 ../lib32 * Running elibtoolize in: gcc-4.9.4/ * Portage patch requested, but failed to apply! * Please file a bug report to add a proper patch. * ERROR: sys-devel/gcc-4.9.4::gentoo failed (prepare phase): * Portage patch requested, but failed to apply! php-5.6.30 : Running elibtoolize in: apr-1.5.2/build/ * Portage patch failed to apply (ltmain.sh<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinkprotect.cudasvc.com%2Furl%3Fa%3Dhttps%3A%2F%2Fltmain.sh%26c%3DE%2C1%2C16DTwNxy3YTGURrFc6wVEn8qZSLArBJvWH5tMbW0moijBdAXsKGPVC92sCyxqhbc578V3QHDRIagR6EIPL_9z6_zfYBC5cB1QqjLmqlh9UI%2C%26typo%3D1&data=01%7C01%7Cerwan%40easy-info.com%7C8bef349dc9494c768d1008d47506300b%7C2e79289e517d41d6bf83ced4b4db8b5f%7C1&sdata=c2REbQk61biAKDcf4LbOnV7e6jsfaR3e0X3B%2FcIEwxg%3D&reserved=0> version 2.4.6)! * Please file a bug report to add a proper patch. * ERROR: dev-libs/apr-1.5.2::gentoo failed (prepare phase): * Portage patch failed to apply! * * Call stack: * ebuild.sh<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinkprotect.cudasvc.com%2Furl%3Fa%3Dhttps%3A%2F%2Febuild.sh%26c%3DE%2C1%2CPfUVUENYIkC7vp24r3ga_tO6NFcfCI6HSuMDbd6teLOj6aTr-CSW8qi9VNAxdeMhdjRfy6mVRn0xQZvu45d3bffm-He5ZpqvInAbEU6E0fw%2C%26typo%3D1&data=01%7C01%7Cerwan%40easy-info.com%7C8bef349dc9494c768d1008d47506300b%7C2e79289e517d41d6bf83ced4b4db8b5f%7C1&sdata=8j4jbc4sOqKQ8KyOdvuS8TOhms0Eh%2FWTf4tgsfqkhJw%3D&reserved=0>, line 115: Called src_prepare * environment, line 2726: Called eautoreconf * environment, line 864: Called elibtoolize '--force' '/var/tmp/portage/dev-libs/apr-1.5.2/work/apr-1.5.2' * environment, line 1116: Called die * The specific snippet of code: * die "Portage patch failed to apply!"; * * If you need support, post the output of `emerge --info '=dev-libs/apr-1.5.2::gentoo'`, * the complete build log and the output of `emerge -pqv '=dev-libs/apr-1.5.2::gentoo'`. * The complete build log is located at '/var/tmp/portage/dev-libs/apr-1.5.2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-libs/apr-1.5.2/temp/environment'. * Working directory: '/var/tmp/portage/dev-libs/apr-1.5.2/work/apr-1.5.2' * S: '/var/tmp/portage/dev-libs/apr-1.5.2/work/apr-1.5.2' I tried many things without success. Does anyone have any idea what I could do? Thank you
Re: [gentoo-user] modifying locally an ebuild
On Wed, 2005-08-31 at 02:56 -0300, Fernando Canizo wrote:
> El 31/ago/2005 a las 00:23 -0300, Nick me decía:
> > 2. Fernando might like to note that the way to introduce a patch to a
> > package (rather than an amendment to the ebuild) is to use the epatch
> > command. Commonly the line looks like this:
>
> You're saying that i can emerge mutt, run epatch command and then
> re-emerge and assumes the patch? It sounds crazy for me, maybe i don't
> understand.
no no, you put the epatch command in your ebuild file (your own version
that you put in PORTAGE_OVERLAY.) Then the patch gets applied to the
mutt source file before compilation.
>
> > epatch ${FILESDIR}/cool-all-mutt.patch
>
> I see that command in ebuilds, but where is it? I can't find it in my
> installation, but somewhere must be since it gets used.
>
epatch is internal to portage, it is the gentoo version of the patch
command. If you want to see some examples look in portage, eg:
grep epatch /usr/portage/* -r
> > If the patch is large or publicly available, you are better NOT to put
> > it in the portage tree but have it downloaded from a mirror with e
> > SRC_URI command. If you want an example of this take a look at the
> > vlc-0.8.2-r1 ebuild (chosen by me cos I was unsuccessfully hacking it
> > the other day)
>
> I don't understand this either, if i put something un *my* portage
> tree the mirrors get infested?
>
no. lets start again.
there are two places that portage can get the patch from.
1. If it is small you can put it in ${FILESDIR} which is, in our case:
/usr/local/portage/mail-client/mutt/files/cool-all-mutt.patch
Then it is only on your system. If your revised ebuild gets accepted
into portage then the patch file will also get in the portage tree and
every gentooista will eventually get it via emerge sync.
2. If it is large, or if it is, for example, a commonly available public
patch (for example that some third party has published) then you can
instruct portage to download it from the net by specifying a SRC_URI,
viz:
SRC_URI="http://some.place.net/pub/patches/mutt/cool-all-mutt.patch";
You can do that in your private OVERLAY ebuild, and as you say you found
the patch on the net, that may be the best way to do it.
Again, if your revised ebuild gets accepted and if the "powers that be"
get with it, the patch file might also get into the gentoo mirrors,
meaning that it is easier to get with more redundancy.
> (hum... better get some sleep now, i'm understanding less after each
> minute)
>
> --
> Fernando Canizo - http://www.lugmen.org.ar/~conan/
> lighthouse, n.:
> A tall building on the seashore in which the government
> maintains a lamp and the friend of a politician.
--
Nick Rout <[EMAIL PROTECTED]>
--
gentoo-user@gentoo.org mailing list
[gentoo-user] webkit-gtk-2.4.11-r200::gentoo failed (compile phase)
I'm getting an error. make[1]: Leaving directory '/var/tmp/portage/net-libs/webkit-gtk-2.4.11-r200/work/webkitgtk-2.4.11' make: *** [GNUmakefile:25837: all] Error 2 * ERROR: net-libs/webkit-gtk-2.4.11-r200::gentoo failed (compile phase): * emake failed I've tried this propose patch. https://621532.bugs.gentoo.org/attachment.cgi?id=511304 save it to a file patch.patch went to directory: cd /usr/portage/net-libs/webkit-gtk/ patch -p0 < patch.patch It ask me what file I want to patch, I entered: JSStringRef.h run: ebuild /usr/portage/net-libs/webkit-gtk/webkit-gtk-2.4.11-r200.ebuild digest But it still fails to compile. Am I applying patch the same way. -- Thelma
Re: [gentoo-user] Gentoo system crumbling, reports of gcc death
On 6/13/06, Richard Fish <[EMAIL PROTECTED]> wrote: On 6/13/06, Richard Fish <[EMAIL PROTECTED]> wrote:> Well this is a bit confusing, because the command that configure uses> for the compiler test is: Something else that might give me some more ideas:find /usr/local/portage /etc/portage-Richard--gentoo-user@gentoo.org mailing list That was a bit more productive: [EMAIL PROTECTED] ~ # find /usr/local/portage/ /etc/portage /usr/local/portage/ /usr/local/portage/sys-kernel /usr/local/portage/sys-kernel/win4lin-sources /usr/local/portage/sys-kernel/win4lin-sources/Manifest /usr/local/portage/sys-kernel/win4lin-sources/files /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.28.brk-locked.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.CAN-2004-1137.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.CAN-2004-1016.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.81295.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.PaX-84167.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.81106.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.28.arpFix.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.vma.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.82201.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.78362.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.CAN-2004-1056.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.77666.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.81195.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.77094.patch /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.78363.patch /usr/local/portage/sys-kernel/win4lin-sources/files/digest-gentoo-sources-2.4.28-r9 /usr/local/portage/sys-kernel/win4lin-sources/files/digest-gentoo-sources-2.6.11-r11 /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.cmdlineLeak.patch /usr/local/portage/sys-kernel/win4lin-sources/files/digest-win4lin-sources-2.6.11-r11 /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.binfmt_a.out.patch /usr/local/portage/sys-kernel/win4lin-sources/files/Changelog-2.4.bz2 /usr/local/portage/sys-kernel/win4lin-sources/files/digest-gentoo-sources-2.6.1-r2 /usr/local/portage/sys-kernel/win4lin-sources/files/digest-gentoo-sources-2.6.9-r9 /usr/local/portage/sys-kernel/win4lin-sources/files/gentoo-sources-2.4.28.77181.patch /usr/local/portage/sys-kernel/win4lin-sources/files/digest-gentoo-sources-2.6.10-r6 /usr/local/portage/sys-kernel/win4lin-sources/files/digest-gentoo-sources-2.6.10-r7 /usr/local/portage/sys-kernel/win4lin-sources/files/digest-gentoo-sources-2.6.11-r7 /usr/local/portage/sys-kernel/win4lin-sources/files/digest-gentoo-sources-2.6.11-r8 /usr/local/portage/sys-kernel/win4lin-sources/files/digest-gentoo-sources-2.6.11-r9 /usr/local/portage/sys-kernel/win4lin-sources/files/digest-gentoo-sources-2.6.7-r19 /usr/local/portage/sys-kernel/win4lin-sources/ChangeLog /usr/local/portage/sys-kernel/win4lin-sources/metadata.xml /usr/local/portage/sys-kernel/win4lin-sources/win4lin-sources-2.6.11-r11.ebuild/usr/local/portage/packages /usr/local/portage/Parallels-workstation.ebuild.tar.gz /usr/local/portage/app-emulation /usr/local/portage/app-emulation/parallels-workstation /usr/local/portage/app-emulation/parallels-workstation/files /usr/local/portage/app-emulation/parallels-workstation/files/2.0 /usr/local/portage/app-emulation/parallels-workstation/files/2.0/parallels.rc /usr/local/portage/app-emulation/parallels-workstation/files/parallels.rc /usr/local/portage/app-emulation/parallels-workstation/files/digest-parallels-workstation-2.0.1514 /usr/local/portage/app-emulation/parallels-workstation/files/digest-parallels-workstation-2.1.1598 /usr/local/portage/app-emulation/parallels-workstation/files/digest-parallels-workstation-2.1.1622 /usr/local/portage/app-emulation/parallels-workstation/files/digest-parallels-workstation-2.1.1634 /usr/local/portage/app-emulation/parallels-workstation/files/digest-parallels-workstation-2.1.1650 /usr/local/portage/app-emulation/parallels-workstation/files/digest-parallels-workstation-2.1.1658 /usr/local/portage/app-emulation/parallels-workstation/files/digest-parallels-workstation-2.1.1670 /usr/local/portage/app-emulation/parallels-workstation/parallels-workstation-2.0.1514.ebuild /usr/local/portage/app-emulation/parallels-workstation/Manifest /usr/local/portage/app-emulation/parallels-workstation/parallels-workstation-2.1.1622.ebuild /usr/local/portage/app-emulation/parallels-workstation/parallels-workstation-2.1.1598.ebuild /usr/local/portage/app-emulation/parallels-workstation/parallels-workstation-2.1.1634.ebuild /usr/local/portage/app-emulation/par
Re: [gentoo-user] netfilter tarpit target
Ryan Curtin wrote: > Instead of using iptables, you may want to try DenyHosts > (app-admin/denyhosts). It's a simple Python script that parses through > /var/log/secure (or whatever your sshd logs to) and finds IPs who have > failed authentication a certain number of times, then adds those IPs to > /etc/hosts.deny. Naturally, the threshold for blocking a host can be > configured, and many other options can too. It's worked great for me, > and I've used it for about half a year now. > > The website for the DenyHosts project is: > http://denyhosts.sourceforge.net/ > > I hope that I read your question right and that this will help. > > Ryan Curtin > [EMAIL PROTECTED] > > > Thanks, Ryan, but I really want to stick with the tar pit solution. I had already solved the real problem when I asked for help here. I want to play with the tar pit module for..let's say "academic purposes" ;-) Unfortunately I had no luck. Clean kernel, the latest patch-o-matic, the latest iptables and the same result. Obviously gentoo-sources is incompatible with tar pit module. ;-( I'm attaching here a file called "tarpit.txt" containing the commands I issued and the relevant output from them in hope that someone could show a mistake I'm repeating. -- Best regards, Daniel test ~ # cd /usr/src test src # rm -rf linu* test src # emerge -C gentoo-sources ; emerge gentoo-sources test src # svn co https://svn.netfilter.org/netfilter/trunk/iptables test iptables # cd iptables test iptables # svn update At revision 6786. test src # cd .. test src # svn co https://svn.netfilter.org/netfilter/trunk/patch-o-matic-ng test src # cd patch-o-matic-ng test patch-o-matic-ng # svn update At revision 6786. test patch-o-matic-ng # ./runme TARPIT Hey! KERNEL_DIR is not set. Where is your kernel source directory? [/usr/src/linux] Hey! IPTABLES_DIR is not set. Where is your iptables source code directory? [/usr/src/iptables] Loading patchlet definitions. done Welcome to Patch-o-matic ($Revision: 6736 $)! Kernel: 2.6.19, /usr/src/linux Iptables: 1.3.7, /usr/src/iptables Each patch is a new feature: many have minimal impact, some do not. Almost every one has bugs, so don't apply what you don't need! --- Already applied: Testing TARPIT... not applied The TARPIT patch: Author: "Aaron Hopkins" <[EMAIL PROTECTED]> Status: Works for me Adds a TARPIT target to iptables, which captures and holds incoming TCP connections using no local per-connection resources. Connections are accepted, but immediately switched to the persist state (0 byte window), in which the remote side stops sending data and asks to continue every 60-240 seconds. Attempts to close the connection are ignored, forcing the remote side to time out the connection in 12-24 minutes. This offers similar functionality to LaBrea <http://www.hackbusters.net/LaBrea/> but doesn't require dedicated hardware or IPs. Any TCP port that you would normally DROP or REJECT can instead become a tarpit. To tarpit connections to TCP port 80 destined for the current machine: iptables -A INPUT -p tcp -m tcp --dport 80 -j TARPIT To significantly slow down Code Red/Nimda-style scans of unused address space, forward unused ip addresses to a Linux box not acting as a router (e.g. "ip route 10.0.0.0 255.0.0.0 ip.of.linux.box" on a Cisco), enable IP forwarding on the Linux box, and add: iptables -A FORWARD -p tcp -j TARPIT iptables -A FORWARD -j DROP You probably don't want the conntrack module loaded while you are using TARPIT, or you will be using resources per connection. - Do you want to apply this patch [N/y/t/f/a/r/b/w/q/?] t Patch TARPIT applies cleanly - Do you want to apply this patch [N/y/t/f/a/r/b/w/q/?] y Excellent! Source trees are ready for compilation. test patch-o-matic-ng # cd /usr/src/linux test linux # make menuconfig test linux # grep tarpit -i .config CONFIG_IP_NF_TARGET_TARPIT=m test linux # make --snip-- Root device is (3, 1) Boot sector 512 bytes. Setup is 4730 bytes. System is 1622 kB Kernel: arch/i386/boot/bzImage is ready (#1) Building modules, stage 2. MODPOST 159 modules WARNING: "neigh_hh_output" [net/ipv4/netfilter/ipt_TARPIT.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 test linux #
Re: [gentoo-user] Checksum error
On Sonntag 11 Oktober 2009, meino.cra...@gmx.de wrote:
> Hi,
>
> I am currently doing a python-updater run. While the rebuilding
> of the several packages the process failed with
>
> >>> Downloading
> >>> 'http://www.oracle.com/technology/products/berkeley-db/db/update/4.
> >>>7.25/patch.4.7.25.4'
>
> --2009-10-11 10:57:48--
> http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/pat
> ch.4.7.25.4 Resolving www.oracle.com... 80.157.150.10, 80.157.150.33
> Connecting to www.oracle.com|80.157.150.10|:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 5647 (5.5K) [application/octet-stream]
> Saving to: `/usr/portage/distfiles/patch.4.7.25.4'
>
>
> 100%[=
> ===>] 5,647 --.-K/s in
> 0.04s
>
> 2009-10-11 10:57:48 (135 KB/s) -
> `/usr/portage/distfiles/patch.4.7.25.4' saved [5647/5647]
>
> ('Filesize does not match recorded size', 5647L, 5500)
> !!! Fetched file: patch.4.7.25.4 VERIFY FAILED!
> !!! Reason: Filesize does not match recorded size
> !!! Got: 5647
> !!! Expected: 5500
> Refetching... File renamed to
> '/usr/portage/distfiles/patch.4.7.25.4._checksum_failure_.B3kSP2'
>
>
>
> How can I proceed?
>
> Have a nice weekend!
> Best regards,
> mcc
>
sometimes upstream changes a packet without renaming it
sometimes a dowload is just corrupted.
sometimes a dev screwed up
what you can do:
remove the file, retry.
resync, remove the file and retry
