How to reduce your download traffic by 75% or more

[Andersson]

Having deltup depend on the newer bzip2 version, which is masked, makes "emerge -u world" exit with a message about "all packages that could satisfy bzip2 has been masked". I hadn't noticed any problem with bzip, so this was a bit confusing to me, trying to figure out why bzip2 was masked all of a sudden.

IMHO there is nothing wrong in depending on a ~x86 package for a package that is ~x86 itself. However, there is no other working solution for this at the moment.

Isn't there a more elegant solution to the problem? At least let the user know what is causing the problem. Deltup is one of those programs you install and forget about, and most people don't bother much with masked packages.

Have you actually read my posting above? It says exactly what is causing the problem - feel free to ask questions if something is still not clear.

I wasn't talking about the bzip2/md5 problem, I think you solved that wonderfully. My point was that your average user would have added deltup to package.keywords and installed it some time ago. Now emerge -Du world fails with no clue about why the masked version of bzip2 is needed. But never mind. I guess it'll sort itself out in the end, when bzip2-1.0.3 is marked stable.

[blackpenguin]

The problems with bzip2 and wrong filesizes/md5sum is solved

Just update to deltup-0.4.2-r1 -- this ebuild depends on bzip2-1.0.3 and will additonally install a statically linked bzip2-1.0.2 as /usr/bin/bzip_old

It seems that the best solution would be to make bzip2 slotted, so that you can have multiple versions installed simultaneously, and then have a wrapper script which calls the approprate version of bzip2. It's more the "gentoo way" I think.

You just dont need a slotted bzip2 - a full bzip2 installation is not the executable only. there is a lib too - and actually you do not need to bzip2-libraries. actually you do not need two bzip2-versions, since the only difference between them is the maximum number of bits used for huffman-codes when compressing. But the format is the same. both version will uncompress the archives the other one created. So why use a full install of 2 versions of bzip2, if you just need the executable and you just need it for deltup and for nothing else?

[blackpenguin]

Having deltup depend on the newer bzip2 version, which is masked, makes "emerge -u world" exit with a message about "all packages that could satisfy bzip2 has been masked". I hadn't noticed any problem with bzip, so this was a bit confusing to me, trying to figure out why bzip2 was masked all of a sudden.

IMHO there is nothing wrong in depending on a ~x86 package for a package that is ~x86 itself. However, there is no other working solution for this at the moment.

Isn't there a more elegant solution to the problem? At least let the user know what is causing the problem. Deltup is one of those programs you install and forget about, and most people don't bother much with masked packages.

Have you actually read my posting above? It says exactly what is causing the problem - feel free to ask questions if something is still not clear.

I wasn't talking about the bzip2/md5 problem, I think you solved that wonderfully. My point was that your average user would have added deltup to package.keywords and installed it some time ago. Now emerge -Du world fails with no clue about why the masked version of bzip2 is needed. But never mind. I guess it'll sort itself out in the end, when bzip2-1.0.3 is marked stable.

who managed to install a masked package one time will manage this a second time, too. It's not that hard - and I think people should learn to control their systems anyway.

[blackpenguin]

Don't know what happened, but while I was typing the former message, all of the sudden my 30 MB firefox donwload went down to a 900 KB dtu file

Code: Select all

Trying to download kdelibs-3.3.2.tar.bz2-kdelibs-3.4.0.tar.bz2.dtu

error: HTTP error from server: HTTP/1.1 404 Not Found
The dtu could not be fetched, downloading full file from original URL

[/quote]

In *this* case your client actually tries to download the dtu-file already, that means the server index points to a destination - if the file is not there something went wrong at server side. I will investigate that - looks like a bug that have to be fixed. If you have more of errors like this please contact me on freenode's IRC channel #dynamic-deltup-server or via mail to nlissne@linux01.gwdg.de

Apologies for the inconvenience

blackpenguin

[slycordinator]

I'm sorry - but this has *nothing* to do with the dynamic-deltup-server - it is PORTAGE-design your are speaking of. getdelta.sh uses the URL portage gives to it when falling back to download the full file. And portage actually uses your GENTOO_MIRRORS to get files - if that fails, portage takes the URL given in the ebuild itself. In any situation getdelta.sh always contacts linux01.gwdg.de and asks for a dtu-file and if it fails it tries the URL given by portage and that is exactly what portage would have used even without getdelta.
best wishes,
bp

I'm confused.

Without getdelta, when I run emerge package_name it first tries downloading from my GENTOO_MIRRORS and only then uses the URL that the ebuild has.

But with getdelta, it does those in reverse.

[blackpenguin]

I'm confused.

Without getdelta, when I run emerge package_name it first tries downloading from my GENTOO_MIRRORS and only then uses the URL that the ebuild has.

But with getdelta, it does those in reverse.

Actually this is really confusing - and IMHO impossible. getdelta.sh is just used as FETCHCOMMAND it gets exactly the same URL that wget would get if used as FETCHCOMMAND - and getdelta.sh does not know any other URLs - what getdelta does, it submits the original URL taken from ebuild to the server (as a hint where to find the archive) - but that does not mean it connects to that host, it just connects to linux01.gwdg.de - asks for a dtu-file and only fallsback to the url given as parameter from portage.

[opensas]

Could you please tell me how to configure getdelta.sh ro work with other download program

In my make.conf I've got the following

Code: Select all

# wget
#FETCHCOMMAND="/usr/bin/wget -t 5 --passive-ftp \${URI} -P \${DISTDIR}"
#RESUMECOMMAND="/usr/bin/wget -c -t 5 --passive-ftp \${URI} -P \${DISTDIR}"

# DELTUP
FETCHCOMMAND="/usr/bin/getdelta.sh \${URI}"

# Snarf
# FETCHCOMMAND="/usr/bin/snarf -b \${URI} \${DISTDIR}/\${FILE}"
# RESUMECOMMAND="/usr/bin/snarf -rb \${URI} \${DISTDIR}/\${FILE}"

# Axel
# FETCHCOMMAND="/usr/bin/axel -a -S10 \${URI} -o \${DISTDIR}"
# RESUMECOMMAND="/usr/bin/axel -a -S10 \${URI} -o \${DISTDIR}"

# Curl
# FETCHCOMMAND="/usr/bin/curl --ftp-pasv -# -o \${DISTDIR}/\${FILE} \${URI}"
# RESUMECOMMAND="/usr/bin/curl --ftp-pasv -# -C -  -o \${DISTDIR}/\${FILE} \${URI}"
 
# PROZILLA
# FETCHCOMMAND='/usr/bin/proz --no-getch -s ${URI} -P ${DISTDIR}'

and in my /etc/deltup/getdelta.rc

Code: Select all

# wget
FETCH="/usr/bin/wget -t 1 --passive-ftp"

# snarf - SAS
# FETCH="/usr/bin/snarf -b "

I tried with the commented snarf setting, but it didn't work.

Besides, I noticed that the getdelta.rc FETCH var differs with the make.conf FETCHCOMMAND var in the "\${URI} -P \${DISTDIR}"" part


Il be glad if anybody can tell me how to configure the FETCH var in getdelta.rc to work with snarf, axel, curl, prozilla, etc.


Saludos and thanks

Sas

P.S. Blackpenguin: Is there something we can do to support your portage proposal??? Having this marvellous thing included in the official distribution will let many battered dial-up users enjoy gentoo

[blackpenguin]

Could you please tell me how to configure getdelta.sh ro work with other download program

....and in my /etc/deltup/getdelta.rc

Code: Select all

# wget
FETCH="/usr/bin/wget -t 1 --passive-ftp"

# snarf - SAS
# FETCH="/usr/bin/snarf -b "

I tried with the commented snarf setting, but it didn't work.

Besides, I noticed that the getdelta.rc FETCH var differs with the make.conf FETCHCOMMAND var in the "\${URI} -P \${DISTDIR}"" part

I'm not sure what the "-b" you used with snarf does. As a general rule just put a command as FETCH that download to the current working dir. (my snarf does not have a -b switch?) just "7usr/bin/snarf" might be enough.

The reason why the "-P \$(DISTDIR}" is left away is because getdelta.sh does not download to the distfiles-directory directly but to a temporary directory. It does that to be able to delete any garbarge in case the user breaks with ctrl-c

best wishes,
bp

[opensas]

Thanks BP

BTW, your work is marvellous.

I never though I could even try to do an emerge -f world with my humble dial-up

Have you received any answer concerning your proposal for a gentoo updating package system?

Is there anything we can do to support it?

For those willing to have a look at the proposal: http://deltup.sourceforge.net/glep.html

Saludos

Sas

PS: Don't know either what the -b in snarf mean, I just copied it from a thread in this forum

[Master One]

I am just analyzing the getdelta.sh script, because I want it to cooperate with http-replicator, which is kind of tricky due to the distfiles not being in /user/portage/distfiles, but in the defined http-replicator-cache-dir.

I think there is something wrong with this part of the script for handling xdelta files from kde.org:

Code: Select all

                        FILEEXT=$(rev <<< $GOTFILE | cut -c 1-11 | rev)
                        if [ $FILEEXT = ".tar.xdelta" ]
                        then
                                # we haven't received a dtu-file, but an xdelta instead
                                # this means the deltup-server redirected us to ftp.kde.org
                                # to get the official delta-file from there
                                output "${GREEN}This is an xdelta from ftp.kde.org...\n"
                                output "${GREEN}Applying...\n"

                                bunzip2 ${DISTDIR}/${best_candidate}
                                xdelta patch $GOTFILE
                                if ${REMOVE_OLD}
                                then
                                        remove "$(rev <<< ${best_candidate} | cut -c 5- | rev)"
                                else
                                        bzip2 $(rev <<< ${best_candidate} | cut -c 5- | rev)
                                fi
                                bzip2 $(rev <<< $NEW_FILE | cut -c 5- | rev)
                                rm -f $GOTFILE
                                mv -f ${NEW_FILE} ${DISTDIR}
                                output "${GREEN}Succesfully done\n"
                        fi

The problem is, that bunzip is not extracting and replacing the desired archive to the present working dir, but the dir the archive is in. At this point we are still in $tmp_dwn_dest (= "${DISTDIR}/.getdelta-`date +%N`-tmp"), but the script is unzipping $best_candidate in $DISTDIR, so the next line with "xdelta patch" can not proceed because the unzipped $best_candidate is not there. Then if the old file should not get removed, it is trying to zip the the extracted $best_candidate again, which is not in tmp_dwn_dest.

If I am right, this is how that part of the getdelta.sh script should look like:

Code: Select all

                        FILEEXT=$(rev <<< $GOTFILE | cut -c 1-11 | rev)
                        if [ $FILEEXT = ".tar.xdelta" ]
                        then
                                # we haven't received a dtu-file, but an xdelta instead
                                # this means the deltup-server redirected us to ftp.kde.org
                                # to get the official delta-file from there
                                output "${GREEN}This is an xdelta from ftp.kde.org...\n"
                                output "${GREEN}Applying...\n"

                                cp ${DISTDIR}/${best_candidate} .
                                bunzip2 ${best_candidate}
                                xdelta patch $GOTFILE
                                if ${REMOVE_OLD}
                                then
                                        remove "${best_candidate}"
                                fi
                                bzip2 $(rev <<< $NEW_FILE | cut -c 5- | rev)
                                mv -f ${NEW_FILE} ${DISTDIR}
                                output "${GREEN}Succesfully done\n"
                        fi

Any comments?

[Master One]

BTW It seems the deltup server is working on a special port-range for providing the files, which seems to cause troubles with my shorewall settings (strict also for outgoing connections, except those specified in rules).

Can somesome please tell me, which port range I have to open, to make deltup work?

[Master One]

I have now managed to setup the cooperation of http-replicator and deltup, but for some reason I don't get any deltup files. My test was with update from clamav 0.83 to 0.84:

Code: Select all

# emerge world -uDN && repcacheman
Calculating world dependencies ...done!
>>> emerge (1 of 1) app-antivirus/clamav-0.84 to /
>>> Downloading http://gentoo.inode.at/distfiles/clamav-0.84.tar.gz
Searching for a previously downloaded file in /mnt/tbraid/.var/http-replicator

We have following candidates to choose from
clamav-0.83.tar.gz

The best of all is ... clamav-0.83.tar.gz

Checking if this file is OK.

Trying to download clamav-0.83.tar.gz-clamav-0.84.tar.gz.dtu

--18:42:55--  http://linux01.gwdg.de/%7Enlissne/deltup.php?have=clamav-0.83.tar.gz&want=clamav-0.84.tar.gz&url=http://ovh.dl.sourceforge.net/sourceforge/clamav/clamav-0.84.tar.gz&version=0.6
           => `deltup.php?have=clamav-0.83.tar.gz&want=clamav-0.84.tar.gz&url=http:%2F%2Fovh.dl.sourceforge.net%2Fsourceforge%2Fclamav%2Fclamav-0.84.tar.gz&version=0.6'
Auflösen des Hostnamen »localhost«.... 127.0.0.1
Verbindungsaufbau zu localhost[127.0.0.1]:8080... verbunden.
Proxy Anforderung gesendet, warte auf Antwort... 302 Found
Platz: http://134.76.13.21/~nlissne/deltas/clamav-0.83.tar.gz-clamav-0.84.tar.gz.failed[folge]
--18:42:56--  http://134.76.13.21/%7Enlissne/deltas/clamav-0.83.tar.gz-clamav-0.84.tar.gz.failed
           => `clamav-0.83.tar.gz-clamav-0.84.tar.gz.failed'
Verbindungsaufbau zu localhost[127.0.0.1]:8080... verbunden.
Proxy Anforderung gesendet, warte auf Antwort... 200 OK
LÃ?nge: 40

100%[=================================================================================================================>] 40            --.--K/s

18:42:56 (390.62 KB/s) - »clamav-0.83.tar.gz-clamav-0.84.tar.gz.failed« gespeichert [40/40]

GOT clamav-0.83.tar.gz-clamav-0.84.tar.gz.failed


The server could not build the dtu-file for clamav-0.84.tar.gz

reason:
sorry, could not get clamav-0.84.tar.gz

The dtu could not be fetched, downloading full file from original URL

--18:42:56--  http://gentoo.inode.at/distfiles/clamav-0.84.tar.gz
           => `clamav-0.84.tar.gz'
Auflösen des Hostnamen »localhost«.... 127.0.0.1
Verbindungsaufbau zu localhost[127.0.0.1]:8080... verbunden.
Proxy Anforderung gesendet, warte auf Antwort... 200 OK
LÃ?nge: 4,006,624 [text/plain]

100%[=================================================================================================================>] 4,006,624    235.67K/s    ETA 00:00

18:43:12 (236.36 KB/s) - »clamav-0.84.tar.gz« gespeichert [4006624/4006624]

Is the deltup server down?
Any ideas?

I just checked http://linux01.gwdg.de/~nlissne/deltup-status.name.html, but it is not showing any cached delta files.

[prymitive]

Will this work with amd64?

yes and no. Actually it is not trivial to use it on amd64 - the applications build well, but the dtu-files built on a 32bit-machine cannot be used on a 64bit machine and vice versa.

But fortunately A user reported to Build it successfully with -m32 and a little change in the building process.

Have a look at http://giuly.de/xdelta/ to find an ebuild and feel free to contact Giuly on Freenode's IRC in channel #dynamic-deltup-server if you have any questions about or problems with this inofficial ebuild.

good luck!

I could not build it with -m32, it want to link with libraries that I have only in 64 bits, but it's simple to get in working under amd64:

1)get xdelta binary, the most simple way is to download rpm (ftp://fr2.rpmfind.net/linux/PLD/dists/r ... 2.i686.rpm)
2)convert rpm to tar.bz2 or tar.gz archive (it's as simple as running rpm2targz <rpmname>)
3)unpack tar archive and copy xdelta binary from it to /usr/local/bin
4)unmerge xdelta from portage

hmmm, wait a while and i'll write ebuild for it so You don;t have to inject xdelta

<few minutes passes>

Code: Select all

# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/dev-util/xdelta/xdelta-1.1.3.ebuild,v 1.16 2005/04/27 16:46:50 corsair Exp $

inherit rpm eutils

DESCRIPTION="Computes changes between binary or text files and creates deltas"
SRC_URI="ftp://fr2.rpmfind.net/linux/PLD/dists/ra/PLD/i686/PLD/RPMS/xdelta-1.1.3-2.i686.rpm"
HOMEPAGE="http://xdelta.sourceforge.net"

SLOT="0"
LICENSE="GPL-2"
KEYWORDS="~amd64"
IUSE=""

DEPEND="=dev-libs/glib-1.2*
	>=sys-libs/zlib-1.1.4"

RESTRICT="nostrip nomirror"

inherit eutils rpm

src_compile() { :; }

src_install() {
	cd "${WORKDIR}"

	insinto /usr/share/doc
	doins -r ./usr/share/doc/xdelta-1.1.3

	insinto /usr/share/man
	doins -r ./usr/share/man/man1

	dodir /usr/lib
	insinto /usr/lib32
	doins ./usr/lib/*

	dobin ./usr/bin/xdelta
}

it worked for me. I guess we can make xdelta-bin ebuild and make it amd64 only, mask xdelta source ebuild under amd64 until we can solve building it under that arch and make dependencies in other ebuild pointing to xdelta or xdelta-bin with ||(dev-utils/xdelta dev-utils/xdelta-bin) so it will pull xdelta-bin on amd64, that should work, shouldn't it??

[opensas]

Is there some workaround to resume interrupted dtu downloaded files???

I mean, reight now I'm donwloading
mono-0.28.tar.gz-mono-1.0.5-tar-gz-dt

to a temp directory in my distfiles dir

If the connection hangs up, I'll have to start it all over again.

Is there some way to resume the downloading of this file???

It would be really great to have this feature integrated into the getdelta.sh script

Thanks in advance

Sas

[opensas]

Hey, I found the following...

When I tried to download openoffice-bin-1.1.3 (77 Mb) I've got the following:

Code: Select all

---skiped---
The best of all is ... OOo_1.1.2_LinuxIntel_install.tar.gz

Checking if this file is OK.

Trying to download 
---skiped---
OOo_1.1.2_LinuxIntel_install.tar.gz-OOo_1.1.3_LinuxIntel_install.tar.gz.dtu
Connecting to 134.102.120.44:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD /deltup ... done.
==> PASV ... done.    ==> RETR OOo_1.1.2_LinuxIntel_install.tar.gz-OOo_1.1.3_LinuxIntel_install.tar.gz.dtu ... done.

    [                                                                                                            <=>             ] 30,435,680     8.01K/s             

01:36:33 (7.99 KB/s) - Control connection closed.
Giving up.

The dtu could not be fetched, downloading full file from original URL
^C

A: How to resolve this situation and to get not the full sources tarball in such case?
Q:
- Resume downloading by your preffered method. Ex.:

Code: Select all

# cd /usr/portage/distfiles
# ncftpget ftp://134.102.120.44/deltup/OOo_1.1.2_LinuxIntel_install.tar.gz-OOo_1.1.3_LinuxIntel_install.tar.gz.dtu

- Then do:

Code: Select all

# deltup -p -v OOo_1.1.2_LinuxIntel_install.tar.gz-OOo_1.1.3_LinuxIntel_install.tar.gz.dtu
OOo_1.1.2_LinuxIntel_install.tar.gz -> OOo_1.1.3_LinuxIntel_install.tar.gz: OK
cleaning up

- Checking:

Code: Select all

# md5sum  OOo_1.1.3_LinuxIntel_install.tar.gz
1d87f6c730b6fa5252d7dfd4d2c69de4  OOo_1.1.3_LinuxIntel_install.tar.gz
# cat /usr/portage/app-office/openoffice-bin/files/digest-openoffice-bin-1.1.3
MD5 1d87f6c730b6fa5252d7dfd4d2c69de4 OOo_1.1.3_LinuxIntel_install.tar.gz 80123557

MD5 sum's are equal.

I wonder if all these steps could be handled by the getdelta script

(Unfortunately, I'm really new to bash )

Saludos

Sas

[slycordinator]

Actually this is really confusing - and IMHO impossible. getdelta.sh is just used as FETCHCOMMAND it gets exactly the same URL that wget would get if used as FETCHCOMMAND - and getdelta.sh does not know any other URLs - what getdelta does, it submits the original URL taken from ebuild to the server (as a hint where to find the archive) - but that does not mean it connects to that host, it just connects to linux01.gwdg.de - asks for a dtu-file and only fallsback to the url given as parameter from portage.

As an update--

Apparently, it was doing what I wanted all along but I just wasn't looking close enough. At first glance it appeared to be doing things differently.

Either that or something got updated in the time I made this reinstall of gentoo.

[Ibn al-Hazardous]

I could not build it with -m32, it want to link with libraries that I have only in 64 bits, but it's simple to get in working under amd64:

1)get xdelta binary, the most simple way is to download rpm (ftp://fr2.rpmfind.net/linux/PLD/dists/r ... 2.i686.rpm)
2)convert rpm to tar.bz2 or tar.gz archive (it's as simple as running rpm2targz <rpmname>)
3)unpack tar archive and copy xdelta binary from it to /usr/local/bin
4)unmerge xdelta from portage

hmmm, wait a while and i'll write ebuild for it so You don;t have to inject xdelta

<few minutes passes>

Code: Select all

---8<---   cut ebuild, see above

it worked for me. I guess we can make xdelta-bin ebuild and make it amd64 only, mask xdelta source ebuild under amd64 until we can solve building it under that arch and make dependencies in other ebuild pointing to xdelta or xdelta-bin with ||(dev-utils/xdelta dev-utils/xdelta-bin) so it will pull xdelta-bin on amd64, that should work, shouldn't it??

I copied and pasted your ebuild, and put it in /usr/local/portage/dev-util/xdelta-bin, and I masked the ordinary xdelta and unmerged it. Xdelta-bin installed quite nicely, and I can see that /usr/bin/xdelta is there. But when I try to run it (and by extension - when I try to run getdelta) it complains that the "file or catalogue does not exist". Any idea what's up?

[prymitive]

I copied and pasted your ebuild, and put it in /usr/local/portage/dev-util/xdelta-bin, and I masked the ordinary xdelta and unmerged it. Xdelta-bin installed quite nicely, and I can see that /usr/bin/xdelta is there. But when I try to run it (and by extension - when I try to run getdelta) it complains that the "file or catalogue does not exist". Any idea what's up?

Check permissions of /usr/bin/xdelta, I can't think of anything else.

[Ibn al-Hazardous]

I copied and pasted your ebuild, and put it in /usr/local/portage/dev-util/xdelta-bin, and I masked the ordinary xdelta and unmerged it. Xdelta-bin installed quite nicely, and I can see that /usr/bin/xdelta is there. But when I try to run it (and by extension - when I try to run getdelta) it complains that the "file or catalogue does not exist". Any idea what's up?

Check permissions of /usr/bin/xdelta, I can't think of anything else.

Nothing strange with permissions. Something I did solved the problem though. I unmerged xdelta-bin, and tried to emerge the -m32 build, but it couldn't handle the dtu's. So I thought I'd try xdelta-bin some more, and re-emerged it - and now it works like a charm! Could it be that the ordinary xdelta generated some config-file, or something like that?

Anyway, it works now. Kudos!

[grunthus]

Anyone else seeing this now - seems to choke on emerge of bdelta? Cheers

emerge -v getdelta
>>> emerge (1 of 2) dev-util/bdelta-0.1.0 to /
...snip...
>>> Source unpacked.
cc bpatch.cpp -o bpatch -O2 -lstdc++
cc -shared -fPIC -O2 libbdelta.cpp -o libbdelta.so
cc bdelta.cpp -o bdelta -O2 -L. -lbdelta -lstdc++
/usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.5-20050130/../../../../i386-pc-linux-gnu/bin/ld: cannot find -lbdelta
collect2: ld returned 1 exit status
...snip...

OK. blackpenguin sorted this for me on #dynamic-deltup-server on irc.freenode.net

Code: Select all

cd /var/tmp/portage/bdelta-0.1.0/work/bdelta-0.1.0 ; make ; touch /var/tmp/portage/bdelta-0.1.0/.compiled ; ebuild /usr/portage/dev-util/bdelta/bdelta-0.1.0.ebuild merge

Thanks blackpenguin

[Ibn al-Hazardous]

Thanks for getdelta-7.0 with bdelta-support! Now getdelta works on my amd64 without problems.

One thing confuses me though:
Why is xdelta still a dependecy of these packages? I went right away and unmerged it, and it happily remerged itself at the first "emerge -auvD world". If I unmerge it and add it to /etc/portage/profile/package.provided, everything still works right nicely, so I guess it should not be needed anymore? Or is there a difference for other platforms?

[prymitive]

Thanks for getdelta-7.0 with bdelta-support! Now getdelta works on my amd64 without problems.

One thing confuses me though:
Why is xdelta still a dependecy of these packages? I went right away and unmerged it, and it happily remerged itself at the first "emerge -auvD world". If I unmerge it and add it to /etc/portage/profile/package.provided, everything still works right nicely, so I guess it should not be needed anymore? Or is there a difference for other platforms?

I don't know if getdelta-0.7 depends on xdelta but if you have kdexdelta USE flag then it's gonna want to install xdelta.

[Ibn al-Hazardous]

I don't know if getdelta-0.7 depends on xdelta but if you have kdexdelta USE flag then it's gonna want to install xdelta.

That was it.

[thomasa88]

Sweet prg

(kernel-6.8.2 -> 6.8.11-r8 = 5 MB instead of 36 )
(I had kernel 6.8.11-r6 b4 )

[prymitive]

Sweet prg

(kernel-6.8.2 -> 6.8.11-r8 = 5 MB instead of 36 )
(I had kernel 6.8.11-r6 b4 )

where did You get that stuff?? Did Linus send You a beta of 6.8.11 kernel that he is developing in secret? (or did You ment 2.6.8 -> 2.6.11 but numers are not Your domain )??