From glen at pld-linux.org Mon May 6 09:13:46 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Mon, 06 May 2013 10:13:46 +0300 Subject: duplicate pythonegg provides Message-ID: <5187582A.5000205@pld-linux.org> Installing set #53 Processing dependencies... python-ldap-2.4.7-1.x86_64 obsoleted by python-ldap-2.4.10-1.x86_64 python-ldap-2.4.10-1.x86_64: required "pythonegg(setuptools)" is provided by the following packages: a) python-distribute-0.6.35-2.x86_64 b) python-virtualenv-1.9.1-2.noarch c) python3-distribute-0.6.35-2.x86_64 Which one do you want to install ('Q' to abort)? [python-distribute-0.6.35-2.x86_64] i guess py3 egg deps should go to separate namespace? python3egg? pythonegg3? python virtualenv is probably bogus and should me marked as excluded? -- glen From baggins at pld-linux.org Thu May 9 13:31:37 2013 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Thu, 9 May 2013 13:31:37 +0200 Subject: duplicate pythonegg provides In-Reply-To: <5187582A.5000205@pld-linux.org> References: <5187582A.5000205@pld-linux.org> Message-ID: <20130509113137.GL13401@sith.mimuw.edu.pl> On Mon, 06 May 2013, Elan Ruusam?e wrote: > Installing set #53 > Processing dependencies... > python-ldap-2.4.7-1.x86_64 obsoleted by python-ldap-2.4.10-1.x86_64 > python-ldap-2.4.10-1.x86_64: required "pythonegg(setuptools)" is > provided by the following packages: > a) python-distribute-0.6.35-2.x86_64 > b) python-virtualenv-1.9.1-2.noarch > c) python3-distribute-0.6.35-2.x86_64 > Which one do you want to install ('Q' to abort)? > [python-distribute-0.6.35-2.x86_64] > > i guess py3 egg deps should go to separate namespace? python3egg? > pythonegg3? I patched dependency gererator to create python3egg() deps for python3 egg deps. rpm rel 53 should create proper deps now. > python virtualenv is probably bogus and should me marked as excluded? Looks so, I thing noauto for pythonegg(setuptools) in spec should suffice. -- Jan R?korajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-linux.org From baggins at pld-linux.org Thu May 9 13:54:31 2013 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Thu, 9 May 2013 13:54:31 +0200 Subject: perl packages duplicating main functionality Message-ID: <20130509115431.GM13401@sith.mimuw.edu.pl> Hi, Is there any real reason why we have a lot of perl packages that duplicate modules/functionality of main perl distribution? I'm asking because I'm going to remove all of those from Th, because they cause build problems and incompatibilities (vim vs perl-ExtUtils-ParseXS, apache-mod_perl vs perl-Module-CoreList). List of culprits below: perl-Archive-Tar-1.82-1.noarch perl-Attribute-Handlers-0.93-1.noarch perl-bignum-0.29-1.noarch perl-CGI-3.63-1.noarch perl-Class-ISA-0.36-1.noarch perl-Compress-Raw-Bzip2-2.048-1.x86_64 perl-Compress-Raw-Bzip2-2.052-1.x86_64 perl-Compress-Raw-Zlib-2.048-1.x86_64 perl-Compress-Raw-Zlib-2.054-1.x86_64 perl-Convert-Scalar-1.04-2.x86_64 perl-CPAN-1.9402-1.noarch perl-Devel-PPPort-3.20-1.x86_64 perl-Digest-1.17-1.noarch perl-Digest-MD5-2.52-1.x86_64 perl-Digest-SHA-5.70-1.x86_64 perl-ExtUtils-CBuilder-0.280202-1.noarch perl-ExtUtils-CBuilder-0.280205-1.noarch perl-ExtUtils-Command-1.17-1.noarch perl-ExtUtils-Install-1.54-1.noarch perl-ExtUtils-MakeMaker-6.62-2.noarch perl-ExtUtils-Manifest-1.60-1.noarch perl-ExtUtils-ParseXS-2.22_06-1.noarch perl-ExtUtils-ParseXS-3.15-1.noarch perl-File-Temp-0.22-1.noarch perl-Filter-1.39-1.x86_64 perl-Filter-Simple-0.88-1.noarch perl-I18N-LangTags-0.35-2.noarch perl-IO-1.25-2.x86_64 perl-IO-Compress-2.048-1.noarch perl-IO-Compress-2.052-1.noarch perl-IO-Zlib-1.10-1.noarch perl-IPC-Cmd-0.76-1.noarch perl-libnet-1.22-1.noarch perl-Locale-Codes-3.24-2.noarch perl-Locale-Maketext-1.21-1.noarch perl-Locale-Maketext-Simple-0.21-1.noarch perl-Math-BigInt-1.89-1.noarch perl-Math-BigRat-0.26-1.noarch perl-Memoize-1.02-1.noarch perl-MIME-Base64-3.13-1.x86_64 perl-Module-Build-0.3800-2.noarch perl-Module-CoreList-2.60-1.noarch perl-Module-Load-0.22-1.noarch perl-Module-Load-Conditional-0.46-1.noarch perl-Module-Pluggable-4.0-1.noarch perl-parent-0.225-1.noarch perl-Parse-CPAN-Meta-1.4402-1.noarch perl-Parse-CPAN-Meta-1.4404-1.noarch perl-PathTools-3.33-1.x86_64 perl-Pod-Escapes-1.04-2.noarch perl-Pod-Parser-1.38-2.noarch perl-Pod-Simple-3.19-1.noarch perl-Scalar-List-Utils-1.23_03-2.x86_64 perl-Scalar-List-Utils-1.25-1.x86_64 perl-Storable-2.30-1.x86_64 perl-Switch-2.16-1.noarch perl-Sys-Syslog-0.29-1.x86_64 perl-Term-ANSIColor-2.02-1.noarch perl-Test-Harness-3.25-2.noarch perl-Test-Simple-0.98-1.noarch perl-Text-Balanced-2.02-1.noarch perl-Tie-File-0.98-1.noarch perl-Tie-RefHash-1.39-2.noarch perl-Time-HiRes-1.9721-1.x86_64 perl-Time-HiRes-1.9725-1.x86_64 perl-Time-Piece-1.20-1.x86_64 perl-version-0.99-1.x86_64 -- Jan R?korajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-linux.org From baggins at pld-linux.org Thu May 9 14:54:21 2013 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Thu, 9 May 2013 14:54:21 +0200 Subject: th-test: apache 2.4 In-Reply-To: <201304101115.04493.arekm@maven.pl> References: <201304101115.04493.arekm@maven.pl> Message-ID: <20130509125421.GN13401@sith.mimuw.edu.pl> On Wed, 10 Apr 2013, Arkadiusz Mi?kiewicz wrote: > > Hi, > > New apache 2.4 is arriving to th-test. > > Please test and share with upgrade results (there are triggers that convert > configuration etc but likely miss some cases). Due to apache API changes some of the modules that was available for apache 2.2 will have to be removed from Th if no one steps up and adapt them to new API. Here is the list of packages that does not build witch apache 2.4: apache-mod_cband.spec apache-mod_extract_forwarded.spec apache-mod_fastcgi.spec scgi.spec -- Jan R?korajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-linux.org From qboosh at pld-linux.org Thu May 9 16:53:48 2013 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Thu, 9 May 2013 16:53:48 +0200 Subject: perl packages duplicating main functionality In-Reply-To: <20130509115431.GM13401@sith.mimuw.edu.pl> References: <20130509115431.GM13401@sith.mimuw.edu.pl> Message-ID: <20130509145348.GA8301@mail> On Thu, May 09, 2013 at 01:54:31PM +0200, Jan R?korajski wrote: > Hi, > Is there any real reason why we have a lot of perl packages that > duplicate modules/functionality of main perl distribution? With perl 5.16 they are probably not needed. But some packages require newer versions than exist in base perl 5.12 distribution. > I'm asking because I'm going to remove all of those from Th, because they > cause build problems and incompatibilities (vim vs perl-ExtUtils-ParseXS, > apache-mod_perl vs perl-Module-CoreList). Problematic modules could be removed after checking BR list for versioned dependencies with versions newer than in perl provided in Th. -- Jakub Bogusz http://qboosh.pl/ From glen at pld-linux.org Thu May 9 21:32:24 2013 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Thu, 09 May 2013 22:32:24 +0300 Subject: [packages/fltk] - force ld.bfd In-Reply-To: <8ac83007f058950b37664d253f9241bc0a19edba_refs_heads_master@pld-linux.org> References: <8ac83007f058950b37664d253f9241bc0a19edba_refs_heads_master@pld-linux.org> Message-ID: <518BF9C8.3010502@pld-linux.org> On 09.05.2013 21:16, qboosh wrote: > commit 8ac83007f058950b37664d253f9241bc0a19edba > Author: Jakub Bogusz > Date: Thu May 9 20:16:10 2013 +0200 > > - force ld.bfd > > fltk.spec | 6 ++++++ > 1 file changed, 6 insertions(+) > --- > diff --git a/fltk.spec b/fltk.spec > index 2b909e8..a3ac967 100644 > --- a/fltk.spec > +++ b/fltk.spec > @@ -157,6 +157,12 @@ Gry FLTK: Atak Klock?w!, Warcaby, Sudoku. > %patch3 -p1 > > %build > +# gold doesn't understand -l:path/to/library.so > +if [ -x /usr/bin/ld.bfd ]; then > + install -d ld-dir > + ln -sf /usr/bin/ld.bfd ld-dir/ld > + export PATH=$(pwd)/ld-dir:$PATH > +fi so -fuse-ld=bfd gcc option works nowhere? our gcc is patched for that -f option -- glen From gotar at polanet.pl Sat May 11 07:39:50 2013 From: gotar at polanet.pl (Tomasz Pala) Date: Sat, 11 May 2013 07:39:50 +0200 Subject: th-test: apache 2.4 In-Reply-To: <20130509125421.GN13401@sith.mimuw.edu.pl> References: <201304101115.04493.arekm@maven.pl> <20130509125421.GN13401@sith.mimuw.edu.pl> Message-ID: <20130511053950.GA4499@polanet.pl> On Thu, May 09, 2013 at 14:54:21 +0200, Jan R?korajski wrote: > On Wed, 10 Apr 2013, Arkadiusz Mi?kiewicz wrote: >> >> New apache 2.4 is arriving to th-test. >> >> Please test and share with upgrade results (there are triggers that convert >> configuration etc but likely miss some cases). Please move apache 2.2 to obsoleted instead removing. > Due to apache API changes some of the modules that was available for > apache 2.2 will have to be removed from Th if no one steps up and adapt > them to new API. > > Here is the list of packages that does not build witch apache 2.4: > > apache-mod_fastcgi.spec I might be wrong, but this one is obsoleted by mod_fcgid. -- Tomasz Pala From glen at pld-linux.org Wed May 15 14:37:09 2013 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Wed, 15 May 2013 15:37:09 +0300 Subject: [packages/python-logilab-astng] - rel 2; avoid python(abi) = 2.5 dependency In-Reply-To: References: <0e3e3827f738f9aa4ba14b779929c91ef16d99c3_refs_heads_master@pld-linux.org> Message-ID: <51938175.9060706@pld-linux.org> On 15.05.2013 13:14, arekm wrote: > commit f5edbecb34fa72e63116283a84a641037caa64b9 > Author: Arkadiusz Mi?kiewicz > Date: Wed May 15 12:14:48 2013 +0200 > > - rel 2; avoid python(abi) = 2.5 dependency > > python-logilab-astng.spec | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > --- > diff --git a/python-logilab-astng.spec b/python-logilab-astng.spec > index daf7726..c4f62da 100644 > --- a/python-logilab-astng.spec > +++ b/python-logilab-astng.spec > @@ -3,7 +3,7 @@ Summary: Python Abstract Syntax Tree New Generation > Summary(pl.UTF-8): Abstrakcyjne drzewa sk?adniowe Pythona nowej generacji > Name: python-logilab-astng > Version: 0.24.3 > -Release: 1 > +Release: 2 > License: LGPL v2.1+ > Group: Development/Languages/Python > Source0: http://download.logilab.org/pub/astng/%{module}-%{version}.tar.gz > @@ -32,6 +32,8 @@ potrzebami pylinta. > > %prep > %setup -q -n %{module}-%{version} > +# drop python 2.5 egg deps > +rm */*/*py2.5.egg > all prepackaged eggs should be dropped, and regenerated in %build -- glen From glen at pld-linux.org Sat May 18 12:54:03 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Sat, 18 May 2013 13:54:03 +0300 Subject: rpm5 & ts.hdrFromFdno from .hdr file Message-ID: <51975DCB.6000104@pld-linux.org> seems the .hdr files that yum/anaconda creates are not parseable by rpm5 on the same system: # python hdr.py blockdev-2.22.2-4.i686.hdr ['hdr.py', 'blockdev-2.22.2-4.i686.hdr'] Traceback (most recent call last): File "hdr.py", line 50, in h = returnHeaderFromPackage(sys.argv[1]) File "hdr.py", line 11, in returnHeaderFromPackage hdr = hdrFromPackage(ts, rpmfile) File "hdr.py", line 29, in hdrFromPackage raise rpmUtils.RpmUtilsError, "RPM Error opening Package: [%s]" %e rpmUtils.RpmUtilsError: RPM Error opening Package: [error reading package header] # python hdr.py blockdev-2.22.2-4.i686.rpm ['hdr.py', 'blockdev-2.22.2-4.i686.rpm'] xxd.diff contains diff of hex dump of both packages without offsets # tar cf rpm5-hdr.tar hdr.py blockdev-2.22.2-4.i686.hdr blockdev-2.22.2-4.i686.rpm xxd.diff above tar is available from here to debug: http://carme.pld-linux.org/~glen/rpm5-hdr.tar -- glen From glen at pld-linux.org Sat May 18 13:37:09 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Sat, 18 May 2013 14:37:09 +0300 Subject: rpm5 & ts.hdrFromFdno from .hdr file In-Reply-To: <51975DCB.6000104@pld-linux.org> References: <51975DCB.6000104@pld-linux.org> Message-ID: <519767E5.90606@pld-linux.org> On 05/18/2013 01:54 PM, Elan Ruusam?e wrote: > seems the .hdr files that yum/anaconda creates are not parseable by > rpm5 on the same system: > ... > above tar is available from here to debug: > http://carme.pld-linux.org/~glen/rpm5-hdr.tar > header is extracted from this repodata info: perhaps those offsets are incorrect? blockdev i686 ce62ebb4ecf5b428049ebe27ee8a95379507aec3d447aa52a2fde2b31199f4e4

Support for blockdev

The utility blockdev allows one to call block device ioctls from the command line. This package also includes initscript to set blockdev parameters at system startup. http://userweb.kernel.org/~kzak/util-linux/ GPL pld Applications/System nereid-builder util-linux-2.22.2-4.src.rpm

/etc/init/blockdev.conf /etc/rc.d/init.d/blockdev /etc/sysconfig/blockdev /sbin/blockdev

-- glen From glen at pld-linux.org Sat May 18 13:56:52 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Sat, 18 May 2013 14:56:52 +0300 Subject: rpm5 & ts.hdrFromFdno from .hdr file In-Reply-To: <519767E5.90606@pld-linux.org> References: <51975DCB.6000104@pld-linux.org> <519767E5.90606@pld-linux.org> Message-ID: <51976C84.90101@pld-linux.org> On 05/18/2013 02:37 PM, Elan Ruusam?e wrote: > On 05/18/2013 01:54 PM, Elan Ruusam?e wrote: >> seems the .hdr files that yum/anaconda creates are not parseable by >> rpm5 on the same system: >> ... >> above tar is available from here to debug: >> http://carme.pld-linux.org/~glen/rpm5-hdr.tar >> > > > header is extracted from this repodata info: > > > > perhaps those offsets are incorrect? script to extract the offsets like yum does (ripped from yum): http://carme.pld-linux.org/~glen/h-range.py # python h-range.py blockdev-2.22.2-4.i686.rpm START: 368, END: 7947, SIZE: 7579 Wrote: blockdev-2.22.2-4.i686.rpm.hdr # md5sum -b *.hdr ce84368ce713e81ad50214c9021f46d3 *blockdev-2.22.2-4.i686.hdr ce84368ce713e81ad50214c9021f46d3 *blockdev-2.22.2-4.i686.rpm.hdr -- glen From glen at pld-linux.org Sat May 18 18:26:03 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Sat, 18 May 2013 19:26:03 +0300 Subject: rpm5 & ts.hdrFromFdno from .hdr file In-Reply-To: <51976C84.90101@pld-linux.org> References: <51975DCB.6000104@pld-linux.org> <519767E5.90606@pld-linux.org> <51976C84.90101@pld-linux.org> Message-ID: <5197AB9B.2090704@pld-linux.org> On 05/18/2013 02:56 PM, Elan Ruusam?e wrote: >> >> >> perhaps those offsets are incorrect? > > script to extract the offsets like yum does (ripped from yum): > http://carme.pld-linux.org/~glen/h-range.py > > # python h-range.py blockdev-2.22.2-4.i686.rpm > START: 368, END: 7947, SIZE: 7579 > Wrote: blockdev-2.22.2-4.i686.rpm.hdr > > # md5sum -b *.hdr > ce84368ce713e81ad50214c9021f46d3 *blockdev-2.22.2-4.i686.hdr > ce84368ce713e81ad50214c9021f46d3 *blockdev-2.22.2-4.i686.rpm.hdr it still seems to be stuck in rpm5, same header-file is usable on rpm4.10: # python hdr2.py blockdev-2.22.2-4.i686.hdr [] # rpm -q rpm-python rpm-python-4.10.3.1-1.fc18.i686 # cat hdr2.py import sys, rpm print rpm.readHeaderListFromFile(sys.argv[1]) # python hdr2.py blockdev-2.22.2-4.i686.hdr None # rpm -q python-rpm python-rpm-5.4.10-50.i686 -- glen From n3npq at me.com Sat May 18 19:58:16 2013 From: n3npq at me.com (Jeffrey Johnson) Date: Sat, 18 May 2013 13:58:16 -0400 Subject: rpm5 & ts.hdrFromFdno from .hdr file In-Reply-To: <519767E5.90606@pld-linux.org> References: <51975DCB.6000104@pld-linux.org> <519767E5.90606@pld-linux.org> Message-ID: On May 18, 2013, at 7:37 AM, Elan Ruusam?e wrote: > On 05/18/2013 01:54 PM, Elan Ruusam?e wrote: >> seems the .hdr files that yum/anaconda creates are not parseable by rpm5 on the same system: >> ... >> above tar is available from here to debug: >> http://carme.pld-linux.org/~glen/rpm5-hdr.tar >> > > > header is extracted from this repodata info: > > > > perhaps those offsets are incorrect? > Heh: offsets being different. You (in fact) asked for the change in offsets years ago. I also gave you the backport to rpm-4.4.9 at the time. The issue is that the package signature precedes the plaintext that is signed in a *.rpm package. In order to sign a package, the entire payload MUST be rewritten, which is quite slow on NFS. rpm5 reserves space in the signature header so that the signature can be substituted rather than forcing the entire package to be rewritten. The corollary is that the metadata header always starts at the same offset. Offhand, you do not seem to be using the functionality that you asked for: "368" is way too small. I also suspect that you are using ancient versions of yum (and perhaps anaconda) if attempting to produce files containing only header metadata, rpm5 goes to some 'lenghts to ALWAYS verify package signatures, and EVERY package produced by rpmbuild has a non-repudiable signature (i.e. there is ALWAYS a signature and public key present in every package produced by rpmbuild). hth 73 de Jeff 73 de Jeff From glen at pld-linux.org Sat May 18 22:37:09 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Sat, 18 May 2013 23:37:09 +0300 Subject: rpm5 & ts.hdrFromFdno from .hdr file In-Reply-To: References: <51975DCB.6000104@pld-linux.org> <519767E5.90606@pld-linux.org> Message-ID: <5197E675.6080706@pld-linux.org> On 05/18/2013 08:58 PM, Jeffrey Johnson wrote: > On May 18, 2013, at 7:37 AM, Elan Ruusam?e wrote: > >> On 05/18/2013 01:54 PM, Elan Ruusam?e wrote: >>> seems the .hdr files that yum/anaconda creates are not parseable by rpm5 on the same system: >>> ... >>> above tar is available from here to debug: >>> http://carme.pld-linux.org/~glen/rpm5-hdr.tar >>> >> >> header is extracted from this repodata info: >> >> >> >> perhaps those offsets are incorrect? >> > Heh: offsets being different. > > You (in fact) asked for the change in offsets years ago. I also gave you the > backport to rpm-4.4.9 at the time. i suspected so... ok. found the patch https://github.com/pld-linux/rpm/blob/rpm-4_5/rpm-sigpad.patch > The corollary is that the metadata header always starts at the same offset. > > Offhand, you do not seem to be using the functionality that you asked for: "368" > is way too small. it was never patched in yum part, so this can be explained > I also suspect that you are using ancient versions of yum (and perhaps anaconda) > if attempting to produce files containing only header metadata, rpm5 goes to some > 'lenghts to ALWAYS verify package signatures, and EVERY package produced by > rpmbuild has a non-repudiable signature (i.e. there is ALWAYS a signature and > public key present in every package produced by rpmbuild). yum and anaconda are recent, and that _get_header_byte_range() seems unchanged for ages [1] just they don't do the padding there and i don't know what yum or anaconda-yum are doing there (it's too much code), but yum itself works in pld (can install packages), anaconda-yum gets stuck with this problem, as it seems to store .hdr of each package, and later it can't process it. [1] http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=2d835c75 -- glen From glen at pld-linux.org Sat May 18 22:57:06 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Sat, 18 May 2013 23:57:06 +0300 Subject: rpm5 & ts.hdrFromFdno from .hdr file In-Reply-To: References: <51975DCB.6000104@pld-linux.org> <519767E5.90606@pld-linux.org> Message-ID: <5197EB22.8020607@pld-linux.org> On 05/18/2013 08:58 PM, Jeffrey Johnson wrote: > Heh: offsets being different. something doesn't end up. the .hdr file created on fedora is not parseable either, see this post: http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2013-May/023530.html the .hdr file was created by anaconda installer (using the same algorthm i pasted from yum) and it successfully used the header file and installed real rpm too. -- glen From glen at pld-linux.org Sat May 18 23:12:31 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Sun, 19 May 2013 00:12:31 +0300 Subject: rpm5 & ts.hdrFromFdno from .hdr file In-Reply-To: References: <51975DCB.6000104@pld-linux.org> <519767E5.90606@pld-linux.org> Message-ID: <5197EEBF.7050607@pld-linux.org> On 05/18/2013 08:58 PM, Jeffrey Johnson wrote: >> >header is extracted from this repodata info: >> > >> > >> > >> >perhaps those offsets are incorrect? >> > > Heh: offsets being different. so, i found rpm5 has the offsets stored in headers already, and those give the same offsets out, which seem to be correct (compared to what rpm/yum on fedora does) # ./hw5.py blockdev-2.22.2-4.i686.rpm st: 368, end: 7947 START: 368, END: 7947, SIZE: 7579 Wrote: blockdev-2.22.2-4.i686.rpm.rpm5.hdr # md5sum *.hdr ce84368ce713e81ad50214c9021f46d3 blockdev-2.22.2-4.i686.rpm.hdr ce84368ce713e81ad50214c9021f46d3 blockdev-2.22.2-4.i686.rpm.rpm5.hdr altho all the files used in the tests are in this [1] archive, showing the .py here as well: [1] http://carme.pld-linux.org/~glen/rpm5-hdr.tar # cat hw5.py #!/usr/bin/python import os, sys, rpm def get_hdr(rpm_file): ts = rpm.ts() fdno = os.open(rpm_file, os.O_RDONLY) hdr = ts.hdrFromFdno(fdno) os.close(fdno) return hdr def _get_header_byte_range(localpath): hdr = get_hdr(localpath) print "st: %s, end: %s" % (hdr[1211], hdr[1212]) q = hdr.sprintf('%{HEADERSTARTOFF} %{HEADERENDOFF}') (start, end) = q.split(' ') return (int(start), int(end)) fn = sys.argv[1] (start,end) = _get_header_byte_range(fn) size = end-start print "START: %d, END: %d, SIZE: %d" % (start,end,size) f = open(fn, 'r') f.seek(start) h = f.read(size) f.close() hfn = '%s.rpm5.hdr' % fn f = open(hfn, 'w') f.write(h) f.close() print "Wrote: %s" % hfn -- glen From n3npq at me.com Sun May 19 00:53:43 2013 From: n3npq at me.com (Jeffrey Johnson) Date: Sat, 18 May 2013 18:53:43 -0400 Subject: rpm5 & ts.hdrFromFdno from .hdr file In-Reply-To: <5197EEBF.7050607@pld-linux.org> References: <51975DCB.6000104@pld-linux.org> <519767E5.90606@pld-linux.org> <5197EEBF.7050607@pld-linux.org> Message-ID: <916A9A7C-3757-43F4-B107-7FD53278C8AE@me.com> On May 18, 2013, at 5:12 PM, Elan Ruusam?e wrote: > On 05/18/2013 08:58 PM, Jeffrey Johnson wrote: >>> >header is extracted from this repodata info: >>> > >>> > >>> > >>> >perhaps those offsets are incorrect? >>> > >> Heh: offsets being different. > so, i found rpm5 has the offsets stored in headers already, and those give the same offsets out, which seem to be correct (compared to what rpm/yum on fedora does) > > # ./hw5.py blockdev-2.22.2-4.i686.rpm > st: 368, end: 7947 > START: 368, END: 7947, SIZE: 7579 > Wrote: blockdev-2.22.2-4.i686.rpm.rpm5.hdr > Well I'm not at all surprised that the offsets are identical since nothing has explicitly changed in a header format since like forever. There are several implicit contextual changes to the data that is loosely called a "header". 1) RPM always added 16b of magic when writing a header to disk in a package. YUM originally wrote metadata headers without the magic, and I suspect that is/was the code that is in anaconda when yum support was merged in. From memory, the 16b of magic are always added in @rpm5.org code to make a "header" less complex (because a unchanged/immutable data blob). 2) signature tags are appended to what is called a "immutable header region" in the header object when a header is loaded so that all metadata can be accessed from a single object. I don't know what/why anaconda is re-exporting header metadata to a file: but added tags MUST be removed to re-create the metadata header blob exactly as it was in the original *.rpm for multiple export/import operations. The data blob is also allocated using mmap(2) with PROT_READ protections to prevent changes. So what is the exact issue you are trying to solve? AFAIK anaconda tools cannot read a header using rpm-python from RPM5? 73 de Jeff From glen at pld-linux.org Mon May 20 10:54:52 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Mon, 20 May 2013 11:54:52 +0300 Subject: rpm5 & ts.hdrFromFdno from .hdr file In-Reply-To: <916A9A7C-3757-43F4-B107-7FD53278C8AE@me.com> References: <51975DCB.6000104@pld-linux.org> <519767E5.90606@pld-linux.org> <5197EEBF.7050607@pld-linux.org> <916A9A7C-3757-43F4-B107-7FD53278C8AE@me.com> Message-ID: <5199E4DC.1010309@pld-linux.org> On 05/19/2013 01:53 AM, Jeffrey Johnson wrote: > So what is the exact issue you are trying to solve? AFAIK anaconda > tools cannot read a header using rpm-python from RPM5? rpm/python-rpm/yum/anaconda from pld can not read .hdr file that yum/anaconda writes (the code that writes was also posted in my earlier posts) the same .hdr file is readable in fc18, fc18 creates the same identical .hdr file (the samples should be visible in my earlier posts). i tested with pld and fedora rpm's both ways. the read call i narrowed it down that is giving None in pld and an object in fc was rpm.readHeaderListFromFile -- glen From n3npq at me.com Mon May 20 19:32:40 2013 From: n3npq at me.com (Jeffrey Johnson) Date: Mon, 20 May 2013 13:32:40 -0400 Subject: rpm5 & ts.hdrFromFdno from .hdr file In-Reply-To: <5199E4DC.1010309@pld-linux.org> References: <51975DCB.6000104@pld-linux.org> <519767E5.90606@pld-linux.org> <5197EEBF.7050607@pld-linux.org> <916A9A7C-3757-43F4-B107-7FD53278C8AE@me.com> <5199E4DC.1010309@pld-linux.org> Message-ID: On May 20, 2013, at 4:54 AM, Elan Ruusam?e wrote: > On 05/19/2013 01:53 AM, Jeffrey Johnson wrote: >> So what is the exact issue you are trying to solve? AFAIK anaconda >> tools cannot read a header using rpm-python from RPM5? > rpm/python-rpm/yum/anaconda from pld can not read .hdr file that yum/anaconda writes (the code that writes was also posted in my earlier posts) > > the same .hdr file is readable in fc18, fc18 creates the same identical .hdr file (the samples should be visible in my earlier posts). i tested with pld and fedora rpm's both ways. > I have looked at your xxd diff. --- blockdev-2.22.2-4.i686.hdr.xxd 2013-05-18 13:34:14.478680653 +0300 +++ blockdev-2.22.2-4.i686.rpm.xxd 2013-05-18 13:34:14.482014000 +0300 ... @@ -471,4 +494,582 @@ 0000 0001 2890 2800 7dc7 3000 5250 4d35 ....(.(.}.0.RPM5 6874 7470 3a2f 2f62 7567 732e 706c 642d http://bugs.pld- 6c69 6e75 782e 6f72 672f 0000 0000 3f00 linux.org/....?. - 0000 07ff fffb e000 0000 10 ........... + 0000 07ff fffb e000 0000 105d 0000 8000 ...........].... + ffff ffff ffff ffff 0018 0ddd 0463 9c72 .............c.r + 1b76 a1c0 28f1 7658 30b2 3563 7c82 b8e3 .v..(.vX0.5c|... This isn't too surprising since you are comparing a header to a package dump. Meanwhile most (if not all) of the header is identical to the same portion in the package. The start:end section in the package is an unloaded header. Any differences in the exported hdr file are yum/anaconda changes through python-rpm bindings or usage. header load/unload operations are performed on every database access: there is no reason whatsoever to suspect the rpm implementation. > the read call i narrowed it down that is giving None in pld and an object in fc was rpm.readHeaderListFromFile > Comparing a dump of the working fc18 with the non-working header file to ensure data is identical. If the data is identical, then the next step is to look at readHeaderListFromFile. Note "list": with a single header, you are not going to be able to test a list (and there are likely differences in behavior there since concatenated headers in a single file haven't been used anywhere I know of for nearly a decade.) hth 73 de Jeff > -- > glen > > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From glen at pld-linux.org Mon May 20 21:16:36 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Mon, 20 May 2013 22:16:36 +0300 Subject: rpm5 & ts.hdrFromFdno from .hdr file In-Reply-To: References: <51975DCB.6000104@pld-linux.org> <519767E5.90606@pld-linux.org> <5197EEBF.7050607@pld-linux.org> <916A9A7C-3757-43F4-B107-7FD53278C8AE@me.com> <5199E4DC.1010309@pld-linux.org> Message-ID: <519A7694.7000004@pld-linux.org> On 05/20/2013 08:32 PM, Jeffrey Johnson wrote: >> >the read call i narrowed it down that is giving None in pld and an object in fc was rpm.readHeaderListFromFile >> > > Comparing a dump of the working fc18 with the non-working header file to ensure data is identical. maybe i wasn't clear enough in previous responses, but pld and fc both produce indentical .hdr files, whether input is pld or fc package, doesn't matter. and the resulting .hdr is usable only in rpm-python on fc. so yes, the data is identical. -- glen From n3npq at me.com Mon May 20 21:24:30 2013 From: n3npq at me.com (Jeffrey Johnson) Date: Mon, 20 May 2013 15:24:30 -0400 Subject: rpm5 & ts.hdrFromFdno from .hdr file In-Reply-To: <519A7694.7000004@pld-linux.org> References: <51975DCB.6000104@pld-linux.org> <519767E5.90606@pld-linux.org> <5197EEBF.7050607@pld-linux.org> <916A9A7C-3757-43F4-B107-7FD53278C8AE@me.com> <5199E4DC.1010309@pld-linux.org> <519A7694.7000004@pld-linux.org> Message-ID: <1D411974-F4C7-4A06-AC1C-A19F69371FFC@me.com> On May 20, 2013, at 3:16 PM, Elan Ruusam?e wrote: > On 05/20/2013 08:32 PM, Jeffrey Johnson wrote: >>> >the read call i narrowed it down that is giving None in pld and an object in fc was rpm.readHeaderListFromFile >>> > >> Comparing a dump of the working fc18 with the non-working header file to ensure data is identical. > maybe i wasn't clear enough in previous responses, but pld and fc both produce indentical .hdr files, whether input is pld or fc package, doesn't matter. and the resulting .hdr is usable only in rpm-python on fc. > > so yes, the data is identical. > Good. So there is likely a difference in the python-rpm binding implementation. I'm not surprised ... Try to pin down the exact return code in yum/anaconda that is failing. One way to do this is to turn on RPMIO debugging, another way is with strace (limit to open/close/read/write if the spewage overwhelms) (from ancient memories) The @rpm5.org code has a slightly different return for EOF than what yum/anaconda are expecting. Just one guess ... ... another guess ... the @rpm.org python bindings is trying to support reading headers without verifying digest/signature, and is also (though its enturely unused afaik) attemptint to support multiple concatenated headers read from single file. hth 73 de Jeff > -- > glen > > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From glen at pld-linux.org Mon May 20 21:42:15 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Mon, 20 May 2013 22:42:15 +0300 Subject: rpm5 & ts.hdrFromFdno from .hdr file In-Reply-To: <1D411974-F4C7-4A06-AC1C-A19F69371FFC@me.com> References: <51975DCB.6000104@pld-linux.org> <519767E5.90606@pld-linux.org> <5197EEBF.7050607@pld-linux.org> <916A9A7C-3757-43F4-B107-7FD53278C8AE@me.com> <5199E4DC.1010309@pld-linux.org> <519A7694.7000004@pld-linux.org> <1D411974-F4C7-4A06-AC1C-A19F69371FFC@me.com> Message-ID: <519A7C97.8070006@pld-linux.org> On 05/20/2013 10:24 PM, Jeffrey Johnson wrote: > On May 20, 2013, at 3:16 PM, Elan Ruusam?e wrote: > >> so yes, the data is identical. >> > Good. > > So there is likely a difference in the python-rpm binding implementation. I'm > not surprised ... yes, they moved the implemetation to .py, which just gives out rpm.hdr object there > Try to pin down the exact return code in yum/anaconda that is failing. > One way to do this is to turn on RPMIO debugging, another way is yeah, and how to do that in .py interface? > with strace (limit to open/close/read/write if the spewage overwhelms) $ strace -ff -efile -s2000 python hdr2.py blockdev-2.22.2-4.i686.hdr 2>blockdev-2.22.2-4.i686.hdr.strace None file is opened on line 343, and then it just exits: 343 open("blockdev-2.22.2-4.i686.hdr", O_RDONLY|O_LARGEFILE) = 3 344 getcwd("/home/vagrant", 4096) = 14 345 +++ exited with 0 +++set also appended blockdev-2.22.2-4.i686.hdr.strace.gz to previous archive at: http://carme.pld-linux.org/~glen/rpm5-hdr.tar > (from ancient memories) > The @rpm5.org code has a slightly different return for EOF than what > yum/anaconda are expecting. Just one guess ... > > ... another guess ... the @rpm.org python bindings is trying to support > reading headers without verifying digest/signature, and is also (though > its enturely unused afaik) attemptint to support multiple concatenated > headers read from single file. i tested also with unsigned rpm's - same result (failing). but otoh, you say pld (rpm5) rpm's are always signed, so maybe that test was not accurate. -- glen From glen at pld-linux.org Mon May 20 21:50:39 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Mon, 20 May 2013 22:50:39 +0300 Subject: rpm5 & ts.hdrFromFdno from .hdr file In-Reply-To: <1D411974-F4C7-4A06-AC1C-A19F69371FFC@me.com> References: <51975DCB.6000104@pld-linux.org> <519767E5.90606@pld-linux.org> <5197EEBF.7050607@pld-linux.org> <916A9A7C-3757-43F4-B107-7FD53278C8AE@me.com> <5199E4DC.1010309@pld-linux.org> <519A7694.7000004@pld-linux.org> <1D411974-F4C7-4A06-AC1C-A19F69371FFC@me.com> Message-ID: <519A7E8F.9080800@pld-linux.org> On 05/20/2013 10:24 PM, Jeffrey Johnson wrote: > Try to pin down the exact return code in yum/anaconda that is failing. > One way to do this is to turn on RPMIO debugging, another way is from code debug, it hits line 770, which sets whole return value to None rpm-5.4.10/python $ PYTHONPATH=. python -c "import sys, rpm; print rpm.readHeaderListFromFile(sys.argv[1])" blockdev-2.22.2-4.i686.hdr add h:0x1047560 notfound set to none end while LIST IT ALL: 0x7f6329d76080 LIST: 0x7f6329d76080, '' None 730 /** 731 */ 732 PyObject * rpmReadHeaders (FD_t fd) 733 { 734 PyObject * list; 735 Header h; 736 hdrObject * hdr; 737 738 if (!fd) { 739 PyErr_SetFromErrno(pyrpmError); 740 return NULL; 741 } 742 743 list = PyList_New(0); 744 if (!list) { 745 return NULL; 746 } 747 748 ... 749 750 while (h) { 751 printf("add h:%p\n", h); 752 hdr = hdr_Wrap(h); 753 if (PyList_Append(list, (PyObject *) hdr)) { 754 Py_XDECREF(list); 755 Py_XDECREF(hdr); 756 return NULL; 757 } 758 Py_XDECREF(hdr); 759 760 (void)headerFree(h); /* XXX ref held by hdr */ 761 h = NULL; 762 763 Py_BEGIN_ALLOW_THREADS 764 { const char item[] = "Header"; 765 const char * msg = NULL; 766 rpmRC rc = rpmpkgRead(item, fd, &h, &msg); 767 if(rc == RPMRC_NOTFOUND) { 768 Py_INCREF(Py_None); 769 printf("notfound set to none\n"); 770 list = Py_None; 771 } 772 else if (rc != RPMRC_OK) 773 rpmlog(RPMLOG_ERR, "%s: %s: %s : error code: %d\n", "rpmpkgRead", item, msg, rc); 774 msg = _free(msg); 775 } 776 Py_END_ALLOW_THREADS 777 printf("end while\n"); 778 } 779 780 printf("LIST IT ALL: %p\n", list); 781 return list; 782 } -- glen From n3npq at me.com Mon May 20 21:55:46 2013 From: n3npq at me.com (Jeffrey Johnson) Date: Mon, 20 May 2013 15:55:46 -0400 Subject: rpm5 & ts.hdrFromFdno from .hdr file In-Reply-To: <519A7C97.8070006@pld-linux.org> References: <51975DCB.6000104@pld-linux.org> <519767E5.90606@pld-linux.org> <5197EEBF.7050607@pld-linux.org> <916A9A7C-3757-43F4-B107-7FD53278C8AE@me.com> <5199E4DC.1010309@pld-linux.org> <519A7694.7000004@pld-linux.org> <1D411974-F4C7-4A06-AC1C-A19F69371FFC@me.com> <519A7C97.8070006@pld-linux.org> Message-ID: <4532BDBB-F50B-48EF-A757-51FEDF561735@me.com> On May 20, 2013, at 3:42 PM, Elan Ruusam?e wrote: > On 05/20/2013 10:24 PM, Jeffrey Johnson wrote: >> On May 20, 2013, at 3:16 PM, Elan Ruusam?e wrote: >> >>> so yes, the data is identical. >>> >> Good. >> >> So there is likely a difference in the python-rpm binding implementation. I'm >> not surprised ... > yes, they moved the implemetation to .py, which just gives out rpm.hdr object there >> Try to pin down the exact return code in yum/anaconda that is failing. >> One way to do this is to turn on RPMIO debugging, another way is > yeah, and how to do that in .py interface? There are several ways: Easiest by far is just to set _rpmio_debug (from memory, name is obvious) to -1 and temporarily install. the FD_t object SHOULD have a Debug method to set per-object rather than globally. Easy enough to add the method if not present, look at other RPM objects). One can also use Python to find the symbol and assign to non-zero (-1 instead of +1 sometimes gives more information) But every I/O operation done by RPM5 SHOULD be insturmented. >> with strace (limit to open/close/read/write if the spewage overwhelms) > > $ strace -ff -efile -s2000 python hdr2.py blockdev-2.22.2-4.i686.hdr 2>blockdev-2.22.2-4.i686.hdr.strace > None > > file is opened on line 343, and then it just exits: > 343 open("blockdev-2.22.2-4.i686.hdr", O_RDONLY|O_LARGEFILE) = 3 > 344 getcwd("/home/vagrant", 4096) = 14 > 345 +++ exited with 0 +++set > OK. the getcwd is being done to change a ealtive name into an absolute name. You are failing on the open, and my guess is that yum/anaconda have decided to _NOT_ write header magic which RPM5 is expecting. > also appended blockdev-2.22.2-4.i686.hdr.strace.gz to previous archive at: > http://carme.pld-linux.org/~glen/rpm5-hdr.tar > >> (from ancient memories) >> The @rpm5.org code has a slightly different return for EOF than what >> yum/anaconda are expecting. Just one guess ... >> >> ... another guess ... the @rpm.org python bindings is trying to support >> reading headers without verifying digest/signature, and is also (though >> its enturely unused afaik) attemptint to support multiple concatenated >> headers read from single file. > > i tested also with unsigned rpm's - same result (failing). but otoh, you say pld (rpm5) rpm's are always signed, so maybe that test was not accurate. > You don't have to believe me, try-and-see, WYSIWYG. rpnbuild -bb foo.spec rpm -qvvp foo*.rpm You should see the non-repudiable signature being verified. You can see the public key in metadata by doing rpm -qp --yaml foo*.rpm 73 de Jeff > -- > glen > > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From n3npq at me.com Mon May 20 22:09:55 2013 From: n3npq at me.com (Jeffrey Johnson) Date: Mon, 20 May 2013 16:09:55 -0400 Subject: rpm5 & ts.hdrFromFdno from .hdr file In-Reply-To: <519A7E8F.9080800@pld-linux.org> References: <51975DCB.6000104@pld-linux.org> <519767E5.90606@pld-linux.org> <5197EEBF.7050607@pld-linux.org> <916A9A7C-3757-43F4-B107-7FD53278C8AE@me.com> <5199E4DC.1010309@pld-linux.org> <519A7694.7000004@pld-linux.org> <1D411974-F4C7-4A06-AC1C-A19F69371FFC@me.com> <519A7E8F.9080800@pld-linux.org> Message-ID: <7F74EC11-340C-4620-B088-2F4DC3001561@me.com> On May 20, 2013, at 3:50 PM, Elan Ruusam?e wrote: > > 763 Py_BEGIN_ALLOW_THREADS > 764 { const char item[] = "Header"; > 765 const char * msg = NULL; > 766 rpmRC rc = rpmpkgRead(item, fd, &h, &msg); > 767 if(rc == RPMRC_NOTFOUND) { > 768 Py_INCREF(Py_None); > 769 printf("notfound set to none\n"); > 770 list = Py_None; > 771 } rpmpkgRead ends up in rpmdb/pkgio.c:1396 rpmReadHeader() Wrap the above code with extern int _pkgio_debug; ... _pkgio_debug = -1; ... _pkgio_debug = 0; to find what is returning RPMRC_NOTFOUND. Pay attention to this comment /* XXX Handle EOF's as RPMRC_NOTFOUND, not RPMRC_FAIL, returns. */ because there are several causes for a RPMRC_NOTFOUND return. hth 73 de Jeff From baggins at pld-linux.org Tue May 28 13:10:12 2013 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Tue, 28 May 2013 13:10:12 +0200 Subject: th-test: apache 2.4 In-Reply-To: <201304101115.04493.arekm@maven.pl> References: <201304101115.04493.arekm@maven.pl> Message-ID: <20130528111012.GD22808@sith.mimuw.edu.pl> On Wed, 10 Apr 2013, Arkadiusz Mi?kiewicz wrote: > > Hi, > > New apache 2.4 is arriving to th-test. > > Please test and share with upgrade results (there are triggers that convert > configuration etc but likely miss some cases). Apache 2.4 is now in th-ready, all webapps have been updated to new access syntax and are also present in th-ready. Please once again test and report if any problems arise. In 1-2 weeks I will move old apache 2.2 to obsoleted and move 2.4 to main. -- Jan R?korajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-linux.org From lukaszgl at post.pl Thu May 30 10:06:05 2013 From: lukaszgl at post.pl (Lukasz Glebicki) Date: Thu, 30 May 2013 10:06:05 +0200 Subject: Fwd: DISTFILES: rosegarden: ERRORS: rosegarden-13.04.tar.bz2 Message-ID: <1670235.dIcUtEFayM@inhell> How to fetch this sources ? I put it to dropin but script is still trying to download not from dropin? Should I remove temporally from spec MD5 signature? Regards, ---------- Forwarded Message ---------- Subject: DISTFILES: rosegarden: ERRORS: rosegarden-13.04.tar.bz2 Date: Wednesday 29 of May 2013, 21:36:22 From: blekot To: pld-cvs-commit at lists.pld-linux.org CC: blekot at pld-linux.org wget -nv --no-check-certificate --user-agent=PLD/distfiles -O ./tmp/e5d0b378-0ab1-4f65- ac48-38086e798ca2/bcc9be7bf8c3945e0eefdb95dc037f0b/rosegarden-13.04.tar.bz2 "http://dl.sourceforge.net/rosegarden/rosegarden-13.04.tar.bz2": exited with code 4 (0x00) FATAL: http://dl.sourceforge.net/rosegarden/rosegarden-13.04.tar.bz2 (bcc9be7bf8c3945e0eefdb95dc037f0b) was not fetched correctly (wget -nv --no- check-certificate --user-agent=PLD/distfiles -O ./tmp/e5d0b378-0ab1-4f65- ac48-38086e798ca2/bcc9be7bf8c3945e0eefdb95dc037f0b/rosegarden-13.04.tar.bz2 "http://dl.sourceforge.net/rosegarden/rosegarden-13.04.tar.bz2": ): file fetched but has 0 length Files fetched: 0 -- Virtually Yours: distfiles. ----------------------------------------- -- ?ukasz G??bicki mail/rot13:yhxnfmty at cbfg.cy PLD/Linux Team gg:246267 Linux Registered User #318551 blekot:{irc,skype} From glen at pld-linux.org Thu May 30 11:21:59 2013 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Thu, 30 May 2013 12:21:59 +0300 Subject: Fwd: DISTFILES: rosegarden: ERRORS: rosegarden-13.04.tar.bz2 In-Reply-To: <1670235.dIcUtEFayM@inhell> References: <1670235.dIcUtEFayM@inhell> Message-ID: <51A71A37.30208@pld-linux.org> On 30.05.2013 11:06, Lukasz Glebicki wrote: > How to fetch this sources ? I put it to dropin but script is still trying to > download not from dropin? Should I remove temporally from spec MD5 signature? you need to tell df-fetcher that file is in your dropin, thus .spec should have no url. you can use temporary branch to do so: git checkout master git pull --rebase git checkout -b df vim *.spec # remove url from SourceX, so it would be only filename git commit -m "df upload" *.spec git push origin df sleep 500 git push origin :df -- glen