Bug 619979

Are you certain that the repo you are trying to import to was cloned using fedpkg 0.5.1 ?  This looks like you cloned using 0.4, discovered it didn't have import, grabbed 0.5.1 then tried to import.

Positive! Removed the directory and clone/imported again with the same result.

Ok, I see what's going on here.  Your package doesn't have any branches but master, and that confused fedpkg.  For a short term fix, I've given you a f14 branch.  if you do a git pull, and then try the import again, it should work.

That did the trick. Thanks!

I guess ... "me too" ... trying to import new package into Fedora. And BTW, IMHO bug 620648 is caused by this as well.

johanka:tigase-utils$ fedpkg import -b master ../tigase-utils-3.3.9-1.src.rpm 
Traceback (most recent call last):
  File "/usr/bin/fedpkg", line 959, in <module>
    args.command(args)
  File "/usr/bin/fedpkg", line 466, in import_srpm
    mymodule = pyfedpkg.PackageModule(args.path)
  File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line 744, in __init__
    self.distval = self._findmasterbranch()
  File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line 694, in _findmasterbranch
    return(int(fedoras[-1].strip('f')) + 1)
IndexError: list index out of range
johanka:tigase-utils$ fedpkg upload --help
usage: fedpkg upload [-h] files [files ...]

positional arguments:
  files

optional arguments:
  -h, --help  show this help message and exit
johanka:tigase-utils$ fedpkg upload tigase-utils-3.3.9.tar.bz2 
Traceback (most recent call last):
  File "/usr/bin/fedpkg", line 959, in <module>
    args.command(args)
  File "/usr/bin/fedpkg", line 539, in new_sources
    mymodule = pyfedpkg.PackageModule(args.path)
  File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line 744, in __init__
    self.distval = self._findmasterbranch()
  File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line 694, in _findmasterbranch
    return(int(fedoras[-1].strip('f')) + 1)
IndexError: list index out of range
johanka:tigase-utils$ rpm -q fedora-packager
fedora-packager-0.5.1.0-1.el6.noarch
johanka:tigase-utils$ fedpkg new-sources tigase-utils-3.3.9.tar.bz2 
Traceback (most recent call last):
  File "/usr/bin/fedpkg", line 959, in <module>
    args.command(args)
  File "/usr/bin/fedpkg", line 539, in new_sources
    mymodule = pyfedpkg.PackageModule(args.path)
  File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line 744, in __init__
    self.distval = self._findmasterbranch()
  File "/usr/lib/python2.6/site-packages/pyfedpkg/__init__.py", line 694, in _findmasterbranch
    return(int(fedoras[-1].strip('f')) + 1)
IndexError: list index out of range
johanka:tigase-utils$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
johanka:tigase-utils$

(In reply to comment #5)
> I guess ... "me too" ... trying to import new package into Fedora. And BTW,
> IMHO bug 620648 is caused by this as well.

For the short term, I've created an F14 branch for you.

(In reply to comment #6)
> (In reply to comment #5)
> > I guess ... "me too" ... trying to import new package into Fedora. And BTW,
> > IMHO bug 620648 is caused by this as well.
> 
> For the short term, I've created an F14 branch for you.    

Thanks, that works for now.

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > I guess ... "me too" ... trying to import new package into Fedora. And BTW,
> > > IMHO bug 620648 is caused by this as well.
> > 
> > For the short term, I've created an F14 branch for you.    
> 
> Thanks, that works for now.    

Though, what's wrong with component-creation script? I have asked in bug 620168 comment 2 for plenty of branches, why they weren't created?

johanka:tigase-utils$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/f14
  remotes/origin/master
johanka:tigase-utils$ 

Where's my el5 branch?

(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > (In reply to comment #5)
> > > > I guess ... "me too" ... trying to import new package into Fedora. And BTW,
> > > > IMHO bug 620648 is caused by this as well.
> > > 
> > > For the short term, I've created an F14 branch for you.    
> > 
> > Thanks, that works for now.    
> 
> Though, what's wrong with component-creation script? I have asked in bug 620168
> comment 2 for plenty of branches, why they weren't created?
> 
> johanka:tigase-utils$ git branch -a
> * master
>   remotes/origin/HEAD -> origin/master
>   remotes/origin/f14
>   remotes/origin/master
> johanka:tigase-utils$ 
> 
> Where's my el5 branch?    

I'm not sure, you'll have to speak to the CVS/GIT admin processor folks, perhaps re-set the flag on your bug?

I met the same problem:
> fedpkg import ~/work/fedora/temp/felix-shell-1.4.2-3.fc15.src.rpm
Traceback (most recent call last):
 File "/usr/bin/fedpkg", line 1086, in ?
   args.command(args)
 File "/usr/bin/fedpkg", line 491, in import_srpm
   mymodule = pyfedpkg.PackageModule(args.path)
 File "/usr/lib/python2.4/site-packages/pyfedpkg/_init_.py", line 938, in _init_
   self.distval = self._findmasterbranch()
 File "/usr/lib/python2.4/site-packages/pyfedpkg/_init_.py", line 886, in _findmasterbranch
   return(int(fedoras[-1].strip('f')) + 1)
IndexError: list index out of range

(In reply to comment #10)
> I met the same problem:
> > fedpkg import ~/work/fedora/temp/felix-shell-1.4.2-3.fc15.src.rpm


I have made a branch for felix-shell.

me too (tm) openoffice.org-diafilter :-(

(In reply to comment #12)
> me too (tm) openoffice.org-diafilter :-(

I've created an f14 branch for you.

(In reply to comment #13)
> (In reply to comment #12)
> > me too (tm) openoffice.org-diafilter :-(
> 
> I've created an f14 branch for you.

For me it turned to be more curse than blessing. In the end tigase-* repos had to be wiped out and recreated, which turned to work just fine second time.

Me too, for drupal6.  I should only have master, EL-6 and EL-5.  I'll be dead.package/block-ing master.  If you create f14, will I have to dead.package that too?

This is `easy' manual procedure:

$ echo "/${SOURCE_FILE_NAME}" > .gitignore
$ md5sum "${SOURCE_FILE_NAME}" > sources
$ curl -k --cert ~/.fedora.cert \
  -F "name=${PACKAGE_NAME}"
  -F "md5sum=${MD5_SUM_OF_SOURCE_FILE}" \
  -F "file=@${SOURCE_FILE_NAME}" \
  https://pkgs.fedoraproject.org/repo/pkgs/upload.cgi
$ git add .gitignore sources "${SPEC_FILE}"
$ git commit
$ git push
$ koji build dist-f15 \
  "git://pkgs.fedoraproject.org/${PACKAGE_NAME}#$(<.git/refs/heads/master)"

(In reply to comment #15)
> Me too, for drupal6.  I should only have master, EL-6 and EL-5.  I'll be
> dead.package/block-ing master.  If you create f14, will I have to dead.package
> that too?

I created a f14/master branch, but once you dead.package master, you can merge that change onto f14/master.

Awesome, thanks!

ugh, same problem now with libreoffice can I get a branch made there, just to be able to upload new .tar.bz2 without misery

*** Bug 641544 has been marked as a duplicate of this bug. ***

I attached a temporary workaround to bug 641544.

(In reply to comment #19)
> ugh, same problem now with libreoffice can I get a branch made there, just to
> be able to upload new .tar.bz2 without misery

Sorry I took so long, I was out sick this morning.  I've created an f14 branch for you to make this "go away" for this package.

*** Bug 643250 has been marked as a duplicate of this bug. ***

A shame this bug is still open...

Maybe process-git-requests should be made to create f14 branches for now?

Created attachment 463010 [details]
fedora-packager-0.5.1.4-only-master-branch.patch

Simple 2 line workaround would at least avoid making dummy branches.

I wonder what happens if there is a f13 branch but not a f14 one...

(In reply to comment #25)
> Created attachment 463010 [details]
> fedora-packager-0.5.1.4-only-master-branch.patch
> 
> Simple 2 line workaround would at least avoid making dummy branches.
> 
> I wonder what happens if there is a f13 branch but not a f14 one...

I can verify that the workaround in Comment 25 does work!

Package: fedpkg-0.5.1.4-7.fc15
Architecture: x86_64
OS Release: Fedora release 15 (Rawhide)


How to reproduce
-----
1. Try to use 'fedpkg import' for a package with no stable branches in git (libindicator)
2.
3.


Comment
-----
I think around line 880 of /usr/lib/python2.7/site-packages/pyfedpkg/__init__.py does some stuff which assumes the presence of at least one branch in the 'fXX' format, which does not always have to be the case; for a package like this, which has just been added and for which I requested only a Rawhide branch, there is only the 'master' branch in git, no 'fXX' branches.

*** Bug 666810 has been marked as a duplicate of this bug. ***

FWIW I've added a link to this bug to
https://fedoraproject.org/wiki/Using_git_FAQ_for_package_maintainers#How_do_I_import_a_SRPM_package.3F

*** Bug 668230 has been marked as a duplicate of this bug. ***

https://fedorahosted.org/fedora-packager/ticket/83 could be probably used a workaround

Package: fedpkg-0.5.1.4-5.fc14
Architecture: x86_64
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. fedpkg clone nepomukcontroller
2. fedpkg import -b master ~/rpmbuild/SRPMS/nepomukcontroller-0.2-2.fc14.src.rpm



Comment
-----
Trying to import nepomukcontroller package, srpm is unpacked - spec and sources are in the place.

What's the status of this bug?

/me is going to ask for F-14 branch

Reading through the thread, I see just proposal for some workarounds instead of real solution. And the solution should be adding the reference for f15 pointing onto the master.

E.g. I did the following:

fedpkg clone -B rubygem-regin
cd rubygem-regin/master/
mkdir .git/refs/remotes/origin/f15
cp .git/refs/remotes/origin/HEAD .git/refs/remotes/origin/f15/master

This workarounds the problem with fetching the "master" branch, since rawhide is not anymore exceptional. Unfortunately, it has some side effect:

[vondruch@dhcp-25-1 master (master)]$ fedpkg build
Building rubygem-regin-0.3.7-2.fc16 for dist-rawhide
Created task: 2740961
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=2740961
....

You see that the build version is not reported corretly: rubygem-regin-0.3.7-2.*fc16* but it appears that everything is just fine on Koji. To fix this, it should be enough to remove the mathematics on the line 1022 of pyfedpkg/__init__.py

So to the conclusion. To fix this problem, the Fedora release should be always referenced in the repository, otherwise there is later no way how to correctly determine it correctly. Similar issues will arise probably when just f13 repository is present.

*** Bug 672473 has been marked as a duplicate of this bug. ***

What's the status of this bug? Note that this bug was reported 6 moths ago.

Creating F-14 branches for all my packages is not a solution. Could you look at it, please?

I am working on it.  I've been discussing various potential fixes with folks recently.  The work on this got sidelined a bit due to re-designing the branch structure.

Package: fedpkg-0.5.2.0-2.fc14
Architecture: x86_64
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. fedpkg clone rubygem-tzinfo.
2. cd rubygem-tzinfo
3. Copy here source files: 'rubygem-tzinfo.spec' , 'tzinfo-0.3.24.gem'.
4. fedpkg clog -> Error, call abrt.


Comment
-----
I want to commit new package. I prepear 1st commit & push.

Package: fedpkg-0.5.2.0-2.fc14
Architecture: x86_64
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. fedpkg clone rubygem-tzinfo.
2. cd rubygem-tzinfo
3. Copy here source files: 'rubygem-tzinfo.spec' , 'tzinfo-0.3.24.gem'.
4. fedpkg clog -> Error, call abrt.
5. Commit by GitGui.
6. git push.
7. fedpkg build -> Crash.

Comment
-----
I want to commit new package. I prepear 1st commit & push.

(In reply to comment #40)
> Package: fedpkg-0.5.2.0-2.fc14
> Architecture: x86_64
> OS Release: Fedora release 14 (Laughlin)
> 
> 
> How to reproduce
> -----
> 1. fedpkg clone rubygem-tzinfo.
> 2. cd rubygem-tzinfo
> 3. Copy here source files: 'rubygem-tzinfo.spec' , 'tzinfo-0.3.24.gem'.
> 4. fedpkg clog -> Error, call abrt.
> 5. Commit by GitGui.
> 6. git push.
> 7. fedpkg build -> Crash.
> 
> Comment
> -----
> I want to commit new package. I prepear 1st commit & push.

I have created a branch for rubygem-tzinfo.  Please pull and try your commands again.

(In reply to comment #41)
> (In reply to comment #40)
> > Package: fedpkg-0.5.2.0-2.fc14
> > Architecture: x86_64
> > OS Release: Fedora release 14 (Laughlin)
> > 
> > 
> > How to reproduce
> > -----
> > 1. fedpkg clone rubygem-tzinfo.
> > 2. cd rubygem-tzinfo
> > 3. Copy here source files: 'rubygem-tzinfo.spec' , 'tzinfo-0.3.24.gem'.
> > 4. fedpkg clog -> Error, call abrt.

+ Now run.

> > 5. Commit by GitGui.
> > 6. git push.
> > 7. fedpkg build -> Crash.

+ Now run.

> > 
> > Comment
> > -----
> > I want to commit new package. I prepear 1st commit & push.
> 
> I have created a branch for rubygem-tzinfo.  Please pull and try your commands
> again.

OK. Built.

http://koji.fedoraproject.org/koji/taskinfo?taskID=2743960 - green.

(In reply to comment #38)
> I am working on it.  I've been discussing various potential fixes with folks
> recently.  The work on this got sidelined a bit due to re-designing the branch
> structure.

Jesse, could you please share with us what are you working on? May be we also would like to have some input. It would prevent such issues in the future.

Also note that my solution proposed in #34 is easy and works well enough to stop branch pollution of repositories.

My current plan of attack is to first add a argument to manually specify the release you're dealing with.  This gives us a fallback.

Then I want to detect the state where there is only a master branch, and when that happens we'll do a koji query to see what dist-rawhide inherits from in order to figure out what rawhide is building for.  We may cache this data, not positive.  If we can't query, perhaps we're offline, then we'll tell the user to manually specify using the argument mentioned above.

I believe that those changes will fix this issue.

This is good idea.

But why don't you add the F15=rawhide branch right now? They will point now to the same head and later, when F15 is really branched they will be divided again. But may be I don't have enough Git-fu :)

(In reply to comment #16)
> This is `easy' manual procedure:
> 
> $ echo "/${SOURCE_FILE_NAME}" > .gitignore
> $ md5sum "${SOURCE_FILE_NAME}" > sources
> $ curl -k --cert ~/.fedora.cert \
>   -F "name=${PACKAGE_NAME}"
>   -F "md5sum=${MD5_SUM_OF_SOURCE_FILE}" \
>   -F "file=@${SOURCE_FILE_NAME}" \
>   https://pkgs.fedoraproject.org/repo/pkgs/upload.cgi
> $ git add .gitignore sources "${SPEC_FILE}"
> $ git commit
> $ git push
> $ koji build dist-f15 \
>   "git://pkgs.fedoraproject.org/${PACKAGE_NAME}#$(<.git/refs/heads/master)"

Thanks for that Petr; I used it to import perl-JSON-PP with just one problem - a missing backslash after -F "name=${PACKAGE_NAME}" in the curl command. Otherwise it worked great.

Ok, I just pushed something to master that does the koji lookup if we don't find any remote branches.  It's not entirely complete, I still need to add some code to handle the network being down, and to add the argument to manually specify distro version, but it's a start, and enough to close this bug.

And now I have error catching for not being able to reach koji, and I added a "--dist" global argument that allows devs to manually specify which dist they are using (f15, el5, etc.)

fedora-packager-0.5.3.0-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/fedora-packager-0.5.3.0-1.fc14

fedora-packager-0.5.3.0-1.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/fedora-packager-0.5.3.0-1.fc13

fedora-packager-0.5.3.0-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/fedora-packager-0.5.3.0-1.el6

fedora-packager-0.5.3.0-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/fedora-packager-0.5.3.0-1.el5

fedora-packager-0.5.3.0-1.el5 has been pushed to the Fedora EPEL 5 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update fedora-packager'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/fedora-packager-0.5.3.0-1.el5

fedora-packager-0.5.3.0-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

fedora-packager-0.5.3.0-1.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

fedora-packager-0.5.3.0-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

fedora-packager-0.5.5.0-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/fedora-packager-0.5.5.0-1.el6

"new-sources" still doesn't work with the new version:

$ rpm -q fedpkg
fedpkg-0.5.3.0-1.fc14.noarch
$ fedpkg clone tumbler
Cloning into tumbler...
remote: Counting objects: 62, done.
remote: Compressing objects: 100% (44/44), done.
remote: Total 62 (delta 21), reused 36 (delta 12)
Receiving objects: 100% (62/62), 7.87 KiB, done.
Resolving deltas: 100% (21/21), done.
$ cd tumbler/
$ git branch
* master
$ fedpkg new-sources tumbler-0.1.20.tar.bz2 
Traceback (most recent call last):
  File "/usr/bin/fedpkg", line 1259, in <module>
    args.command(args)
  File "/usr/bin/fedpkg", line 613, in new_sources
    mymodule = pyfedpkg.PackageModule(args.path, args.dist)
  File "/usr/lib/python2.7/site-packages/pyfedpkg/__init__.py", line 1083, in __init__
    self.module = _name_from_spec(os.path.join(self.path, self.spec))
  File "/usr/lib/python2.7/site-packages/pyfedpkg/__init__.py", line 111, in _name_from_spec
    return output.split()[0]
IndexError: list index out of range

Ok, works in 0.5.5.0-2 from updates-testing.

fedora-packager-0.5.5.0-2.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/fedora-packager-0.5.5.0-2.el6

fedora-packager-0.5.5.0-2.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.