Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
How to reduce your download traffic by 75% or more
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 8, 9, 10, 11  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
Andersson
Guru
Guru


Joined: 12 Jul 2003
Posts: 525
Location: Göteborg, Sweden

PostPosted: Fri Apr 29, 2005 1:27 pm    Post subject: Reply with quote

blackpenguin wrote:
Andersson wrote:
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.
Andersson wrote:
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.
_________________
Must...resist...posting....
One...step...closer...to...getting...stupid...l33t...ranking...
Back to top
View user's profile Send private message
blackpenguin
n00b
n00b


Joined: 09 Mar 2004
Posts: 43
Location: Germany

PostPosted: Fri Apr 29, 2005 5:35 pm    Post subject: Re: bzip2 issues are solved - please update to getdelta-0.4. Reply with quote

chunderbunny wrote:
blackpenguin wrote:
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?
Back to top
View user's profile Send private message
blackpenguin
n00b
n00b


Joined: 09 Mar 2004
Posts: 43
Location: Germany

PostPosted: Fri Apr 29, 2005 5:37 pm    Post subject: Reply with quote

Andersson wrote:
blackpenguin wrote:
Andersson wrote:
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.
Andersson wrote:
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.
Back to top
View user's profile Send private message
blackpenguin
n00b
n00b


Joined: 09 Mar 2004
Posts: 43
Location: Germany

PostPosted: Fri Apr 29, 2005 5:46 pm    Post subject: Reply with quote

opensas wrote:
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 :lol: :lol: :lol:
[code]
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



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
Back to top
View user's profile Send private message
slycordinator
Advocate
Advocate


Joined: 31 Jan 2004
Posts: 3065
Location: Korea

PostPosted: Fri Apr 29, 2005 7:32 pm    Post subject: Reply with quote

blackpenguin wrote:


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.
Back to top
View user's profile Send private message
blackpenguin
n00b
n00b


Joined: 09 Mar 2004
Posts: 43
Location: Germany

PostPosted: Fri Apr 29, 2005 9:30 pm    Post subject: Reply with quote

slycordinator wrote:


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.
Back to top
View user's profile Send private message
opensas
Guru
Guru


Joined: 24 Nov 2004
Posts: 408
Location: Buenos Aires - Argentina

PostPosted: Sun May 01, 2005 9:47 pm    Post subject: Reply with quote

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:

# 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:

# 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 :wink:
Back to top
View user's profile Send private message
blackpenguin
n00b
n00b


Joined: 09 Mar 2004
Posts: 43
Location: Germany

PostPosted: Tue May 03, 2005 4:27 pm    Post subject: Reply with quote

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

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

Code:

# 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
Back to top
View user's profile Send private message
opensas
Guru
Guru


Joined: 24 Nov 2004
Posts: 408
Location: Buenos Aires - Argentina

PostPosted: Wed May 04, 2005 8:59 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Master One
l33t
l33t


Joined: 25 Aug 2003
Posts: 754
Location: Austria

PostPosted: Thu May 05, 2005 9:20 am    Post subject: Reply with quote

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:
                        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:
                        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?
_________________
Las torturas mentales de la CIA
Back to top
View user's profile Send private message
Master One
l33t
l33t


Joined: 25 Aug 2003
Posts: 754
Location: Austria

PostPosted: Thu May 05, 2005 10:32 am    Post subject: Reply with quote

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?
_________________
Las torturas mentales de la CIA
Back to top
View user's profile Send private message
Master One
l33t
l33t


Joined: 25 Aug 2003
Posts: 754
Location: Austria

PostPosted: Thu May 05, 2005 4:49 pm    Post subject: Reply with quote

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:
# 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.
_________________
Las torturas mentales de la CIA
Back to top
View user's profile Send private message
prymitive
Apprentice
Apprentice


Joined: 13 Jun 2004
Posts: 260

PostPosted: Thu May 05, 2005 5:46 pm    Post subject: Reply with quote

blackpenguin wrote:
leighgiles wrote:
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/ra/PLD/i686/PLD/RPMS/xdelta-1.1.3-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:

# 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??
Back to top
View user's profile Send private message
opensas
Guru
Guru


Joined: 24 Nov 2004
Posts: 408
Location: Buenos Aires - Argentina

PostPosted: Fri May 06, 2005 6:31 am    Post subject: Reply with quote

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 :lol:

Thanks in advance

Sas
Back to top
View user's profile Send private message
opensas
Guru
Guru


Joined: 24 Nov 2004
Posts: 408
Location: Buenos Aires - Argentina

PostPosted: Fri May 06, 2005 6:37 am    Post subject: Reply with quote

Hey, I found the following...

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

---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:
# 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:
# 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:
# 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 :oops: )

Saludos

Sas
Back to top
View user's profile Send private message
slycordinator
Advocate
Advocate


Joined: 31 Jan 2004
Posts: 3065
Location: Korea

PostPosted: Fri May 06, 2005 7:53 am    Post subject: Reply with quote

blackpenguin wrote:


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.
Back to top
View user's profile Send private message
Ibn al-Hazardous
Tux's lil' helper
Tux's lil' helper


Joined: 02 Sep 2004
Posts: 133
Location: Somewhere deep in the desert.

PostPosted: Mon May 09, 2005 10:43 am    Post subject: Reply with quote

prymitive wrote:


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/ra/PLD/i686/PLD/RPMS/xdelta-1.1.3-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:

---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?
_________________
/Ibn
Back to top
View user's profile Send private message
prymitive
Apprentice
Apprentice


Joined: 13 Jun 2004
Posts: 260

PostPosted: Mon May 09, 2005 3:13 pm    Post subject: Reply with quote

Ibn al-Hazardous wrote:

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.
Back to top
View user's profile Send private message
Ibn al-Hazardous
Tux's lil' helper
Tux's lil' helper


Joined: 02 Sep 2004
Posts: 133
Location: Somewhere deep in the desert.

PostPosted: Mon May 09, 2005 7:04 pm    Post subject: Reply with quote

prymitive wrote:
Ibn al-Hazardous wrote:

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! :)
_________________
/Ibn
Back to top
View user's profile Send private message
grunthus
Apprentice
Apprentice


Joined: 21 Apr 2005
Posts: 194
Location: Shetland UK

PostPosted: Wed May 11, 2005 7:27 am    Post subject: Problem with 0.7 getdelta Reply with quote

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:
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


Last edited by grunthus on Wed May 11, 2005 10:27 pm; edited 2 times in total
Back to top
View user's profile Send private message
Ibn al-Hazardous
Tux's lil' helper
Tux's lil' helper


Joined: 02 Sep 2004
Posts: 133
Location: Somewhere deep in the desert.

PostPosted: Wed May 11, 2005 9:10 am    Post subject: xdelta still a dependency for 7.0? Reply with quote

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?
_________________
/Ibn
Back to top
View user's profile Send private message
prymitive
Apprentice
Apprentice


Joined: 13 Jun 2004
Posts: 260

PostPosted: Wed May 11, 2005 9:39 am    Post subject: Re: xdelta still a dependency for 7.0? Reply with quote

Ibn al-Hazardous wrote:
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.
Back to top
View user's profile Send private message
Ibn al-Hazardous
Tux's lil' helper
Tux's lil' helper


Joined: 02 Sep 2004
Posts: 133
Location: Somewhere deep in the desert.

PostPosted: Wed May 11, 2005 10:30 am    Post subject: Re: xdelta still a dependency for 7.0? Reply with quote

prymitive wrote:


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. :oops:
_________________
/Ibn
Back to top
View user's profile Send private message
thomasa88
Tux's lil' helper
Tux's lil' helper


Joined: 13 Apr 2005
Posts: 143
Location: Sweden

PostPosted: Wed May 11, 2005 5:41 pm    Post subject: Reply with quote

Sweet prg :D

(kernel-6.8.2 -> 6.8.11-r8 = 5 MB instead of 36 :D)
(I had kernel 6.8.11-r6 b4 :P)
_________________
- thomasa88
Back to top
View user's profile Send private message
prymitive
Apprentice
Apprentice


Joined: 13 Jun 2004
Posts: 260

PostPosted: Wed May 11, 2005 5:55 pm    Post subject: Reply with quote

thomasa88 wrote:
Sweet prg :D

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


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 ;) )??
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page Previous  1, 2, 3 ... 8, 9, 10, 11  Next
Page 9 of 11

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum