Re: Is PulseAudio dead?

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/2/10 4:00 PM, Robert 'Bob' Jensen wrote:
 Reminds me of a quote in a book I know.
 
 He is like the farmer who came up out of his cyclone cellar to find
 his home ruined. To his wife, he remarked, Don't see anything the
 matter here, Ma. Ain't it grand the wind stopped blowin'?
 
 I'm just saying.

Bob, if you can't be nice, please don't be here.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxXWogACgkQ4v2HLvE71NX6lQCfXPFVNKXpUJbw3Jo68pIpyypE
gVwAnRTc/fGuMaqX/IybTvguOV6ZZmAI
=Tp0i
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ACLs working with dist-git?

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/31/2010 05:05 PM, Adam Goode wrote:
 Hi,
 
 I only have commit ACLs on el6 and el5 for python-gdata, but it seems I
 am able to push to all branches. Is this correct? My username is agoode.
 
 
 Thanks,
 
 Adam
 
 

According to
https://admin.fedoraproject.org/pkgdb/acls/name/python-gdata you have
commit access on devel, f14, f13, f12, el5, el6

The git acls have been constructed to support this.  You should not be
able to push to f11 if you want to test that theory

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxVtLwACgkQ4v2HLvE71NW+6ACgsC82kq5tO7LAJyn74vvs7orR
hbUAnA8h0TLvjH1vYb+gPd4SpyAgG7lC
=LgSv
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F14 mirror list still pointing at rawhide

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/01/2010 09:32 AM, M A Young wrote:
 I was trying a yum update on F-14 (fedora-release-14-0.7) but was offered 
 a few F-15 packages. I checked
 https://mirrors.fedoraproject.org/metalink?repo=fedora-14arch=x86_64
 and the mirrors it points to are all rawhide rather than the F-14 branch.
 
   Michael Young

This is being fixed as soon as a mirrormanager admin looks at it.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxVtO4ACgkQ4v2HLvE71NWjnwCgsGOkTTbSvfFdSE/rxSg7ryWC
cr4AnRS5e8xEoLGQ6zy8Ns4uee0WQNP1
=9wCF
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: strange issue with dist-git/fedpkg

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/31/2010 01:00 AM, Julian Sikorski wrote:
 Dear all,
 
 I tried to make a chain build today:
 https://koji.fedoraproject.org/koji/taskinfo?taskID=2368385
 For some reason, an ancient release was picked for goffice, and not the
 proper 0.8.8-1. Any thoughts?

I have to admit, the chain-build target is really untested.  I'll have
to look further into what happened here.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxUUWgACgkQ4v2HLvE71NXV2gCglfI8XYSk+8JVhC1wSGk8eE8x
d3QAmwfpXFspHE7tn0owcEFRD8kbUAZU
=CPRV
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: strange issue with dist-git/fedpkg

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/31/2010 09:38 AM, Jesse Keating wrote:
 On 07/31/2010 01:00 AM, Julian Sikorski wrote:
 Dear all,
 
 I tried to make a chain build today:
 https://koji.fedoraproject.org/koji/taskinfo?taskID=2368385
 For some reason, an ancient release was picked for goffice, and not the
 proper 0.8.8-1. Any thoughts?
 
 I have to admit, the chain-build target is really untested.  I'll have
 to look further into what happened here.
 

Actually I found the bug, and fixed it at least for building from
rawhide.  It'll be in the next build of fedora-packager.

If you really care, you can locally patch
/usr/lib/python-2.?/site-packages/pyfedpkg/__init__.py with:

@@ -359,7 +359,9 @@ def get_latest_commit(module):

 # This is stupid that I have to use subprocess :/
 url = ANONGITURL % {'module': module}
- -cmd = ['git', 'ls-remote', url, 'master']
+# This cmd below only works to scratch build rawhide
+# We need something better for epel
+cmd = ['git', 'ls-remote', url, 'refs/heads/master']
 try :
 proc = subprocess.Popen(cmd, stderr=subprocess.PIPE,
 stdout=subprocess.PIPE)


- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxUVU8ACgkQ4v2HLvE71NVxKgCfTBlQzkpouEAKZi5beE5Fcyob
VDAAnRddHzvfkTgdX/imT0nr/r6VCW8i
=dcMm
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Massive broken deps and tagging into dist-f14?

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/30/2010 07:50 PM, Mamoru Tasaka wrote:
 Jesse Keating wrote, at 07/31/2010 11:36 AM +9:00:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 7/30/10 7:13 PM, Mamoru Tasaka wrote:
 This morning I receided massive broken deps on F-14 and then received
 massive mails of tagging into dist-f14 tree. Can I assume that
 I can ignore these broken deps report or there is something I have
 to do for this?


 Yes, you can ignore this.  It was my fault.  Tomorrow a better compose
 should go through.

 
 Thank you.
 
 Now another question for tag issue. Currently how is it going about
 the inheritance of dist-rawhide tag?
 
 About pygtk2 618944 bug I saw Toshio rebuilt pygtk2-0.17.0-7.fc14,
 however I firstly thought that this new pkg was not rebuild for rawhide
 yet because:
 
 [tasa...@localhost ~]$ koji latest-pkg dist-f14-build pygtk2
 Build Tag   Built by
     
 
 pygtk2-2.17.0-7.fc14  dist-f14-override toshio
 [tasa...@localhost ~]$ koji latest-pkg dist-rawhide pygtk2
 Build Tag   Built by
     
 
 pygtk2-2.17.0-6.fc14  dist-f14  dmalcolm
 
 So I tried to rebuild pygtk2 also on rawhide but it failed with koji's
 reporting that it already exists. Actually:
 [tasa...@localhost ~]$ koji latest-pkg dist-f15 pygtk2
 Build Tag   Built by
     
 
 pygtk2-2.17.0-7.fc15  dist-f15  toshio
 
 Regards,
 Mamoru


That's my fault.  I forgot to update the dist-rawhide tag.  Should be
cleared up now.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxUUHIACgkQ4v2HLvE71NVCqgCgojLtZoMyQluk1b3dqGkZgnLx
yEYAoJlqPpZAp/0KlaaE+MjG7LlTnBN4
=DKl1
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Massive broken deps and tagging into dist-f14?

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/31/2010 01:44 AM, Michael Schwendt wrote:
 Why did we receive mails about tagging into dist-f14?

Because I'm breaking the inheritance chain now that we've branched,
otherwise stable updates from F13/F12 could leak into dist-f14 and
bypass bodhi for dist-f14.  I had forgotten to add this to my SOP last
release which is why we had massively broken deps in the first branched
compose.  Since I was in a hurry I didn't have time to write a full
script that would do the tagging without notification.

 
 | qosmic-1.4.2-4.fc13 successfully tagged into dist-f14 by jkeating
 
 I'm not subscribed to that package in koji, and I'm not a comaintainer
 of it either.

This was answered later in the thread.


- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxUUNwACgkQ4v2HLvE71NULggCfR6OJxxzRGrkn9BFBGQsEwsS6
/3EAnRESnlge3K1bLl+uHKwcIDwLfK2e
=ngGf
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Cannot checkout package

[Jesse Keating]

I thought I had fixed that. There is a umask in the gitolote.RC that should 
cover it. And a setgid on the log dir. 

Mike McGrath mmcgr...@redhat.com wrote:

On Sat, 31 Jul 2010, Mike McGrath wrote:

 On Sat, 31 Jul 2010, Orion Poplawski wrote:

Trying to check out vtk (or other packages):
 
  $ fedpkg co vtk
  Cloning into vtk...
  Warning: No xauth data; using fake authentication data for X11 forwarding.
  open log failed: Permission denied
  fatal: The remote end hung up unexpectedly
  Could not clone: Command '['git', 'clone',
  'ssh://or...@pkgs.fedoraproject.org/vtk']' returned non-zero exit status 
  128
 
  I was able to do this earlier today fine with other packages and have
  the latest fedora-package for F13.
 

 Looking now, I can't even get a shell anymore remotely.  Console time.


fixed.. looking for a permanent fix now.  Basically the logs got
rotated, dmaphy was the first one in and the default umask was too
restrictive for anyone else to write to the logs.

   -Mike
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: modification of sources file causes git corruption.

[Jesse Keating]

No reason really. Just didnt have anybody call me on it. I can fix that in the 
next fedpkg build.

--
Jes

Dave Jones da...@redhat.com wrote:

Check this out..

(00:13:25:da...@gelk:kernel)$ fedpkg -v upload patch-2.6.35-rc6-git6.bz2
Creating module object from /mnt/data/src/fedora/kernel
Uploading: f73d01927a3150e729b44add5ea4923c  patch-2.6.35-rc6-git6.bz2
Running curl -k --cert /home/davej/.fedora.cert --fail -o /dev/null 
--show-error --progress-bar -F name=kernel -F 
md5sum=f73d01927a3150e729b44add5ea4923c -F fi...@patch-2.6.35-rc6-git6.bz2 
https://pkgs.fedoraproject.org/repo/pkgs/upload.cgi directly on the tty
 100.0%
Source upload succeeded. Don't forget to commit the sources file
(00:13:35:da...@gelk:kernel)$ git fsck --full
(00:13:59:da...@gelk:kernel)$ cat sources 
10eebcb0178fb4540e2165bfd7efc7ad  linux-2.6.34.tar.bz2
1205481c8d1b5ccecad87840ddaeaf81  patch-2.6.35-rc6.bz2
6488f89f618d7e03af865534b31d3419  patch-2.6.35-rc6-git5.bz2
f73d01927a3150e729b44add5ea4923c  patch-2.6.35-rc6-git6.bz2
(00:14:02:da...@gelk:kernel)$ vim sources 
(00:14:05:da...@gelk:kernel)$ cat sources 
10eebcb0178fb4540e2165bfd7efc7ad  linux-2.6.34.tar.bz2
1205481c8d1b5ccecad87840ddaeaf81  patch-2.6.35-rc6.bz2
f73d01927a3150e729b44add5ea4923c  patch-2.6.35-rc6-git6.bz2
(00:14:06:da...@gelk:kernel)$ git fsck --full
(00:14:43:da...@gelk:kernel)$ git commit -a
[master 89d0d88] 2.6.35-rc6-git6
 3 files changed, 6 insertions(+), 2 deletions(-)
(00:16:40:da...@gelk:kernel)$ git fsck --full
dangling blob 64802926167a6aef0d71a5e6de35f0857674947b


git show on that blob shows the variant of 'sources' before I removed
the git5 entry. It seems if there's a pending staged commit to a file,
and then you modify it, git loses its shit.

Why can't fedpkg upload just leave the file modified instead of staging the 
commit ?
This would also have the advantage of showing up in git diff without the need
for --cached before doing the actual commit.

If we're modifying sources for an upload, chances are we're going to want to 
remove
a stale entry anyway, and having to do this as two commits seems a bit dumb.

   Dave

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 has been branched!

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/30/2010 06:00 AM, John Poelstra wrote:
 Jesse Keating said the following on 07/29/2010 09:03 PM Pacific Time:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 https://fedoraproject.org/wiki/Branch_Freeze_Policy

 I know it's been a rough couple of days here, python-2.7 and boost
 rebuilds creating build havoc, systemd creating some interesting
 confusion, and dist-git to top it all off.  But we'll work through it as
 best as we can, as we always do.  Onward into the future!

 
 We didn't have this *freeze* reflected in the Fedora 14 schedule.  Is 
 this the same as the task Branch Fedora 14 from Rawhide?
 
 In normal circumstances, how long would you expect the freeze to last?
 
 John

Well perhaps the page name is misleading, but this is the freeze of
being branched and using bodhi for everything.  It's exactly what we did
last release, the first release of no frozen rawhide.  We are frozen
in that if you do a build in the f14 branch, the build won't
automatically show up, you have to do a bodhi action.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxTBRcACgkQ4v2HLvE71NUGZgCguyfkuIJ28WSRRVTcTl3jkxxZ
nv4AnRd9V/771QUgcbfstop0Udk6TsPz
=8k04
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: The move to git!

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/30/2010 03:06 AM, Peter Lemenkov wrote:
 Great news!
 
 Few questions still remains unanswered for me:
 
 * Should I use git now?

Yes.

 * May I still use cvs?

read-only

 * If I'll add some changes right now using git/cvs will they be
 available in cvs/git respectively?

You won't be able to add anything to cvs, so use git.

 * I just noticed that some freshly cloned git repositories are about
 one month old (namely, couchdb) - do I need to wait until final
 synchronization before using git for them?
 

You need a newer fedora-packager.


- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxTEU8ACgkQ4v2HLvE71NVKPgCfUqH0hUwZfc7mjG3yppgKkA/M
1z0An3nuPXO2LM1chg6QvNxQLOX9xPKU
=dDbT
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: The move to git!

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/30/2010 05:43 AM, Miroslav Suchý wrote:
 On 07/30/2010 05:55 AM, Jesse Keating wrote:
 starts to spread ( https://fedoraproject.org/wiki/Using_Fedora_GIT is a
 good start ).
 
 I made:
 
 fedpkg clone python-debian
 cd python-debian
 fedpkg switch-branch f14
   edit spec file
 fedpkg commit -m 'edit changelog entry' -p
 fedpkg push
 
 And the last thep did not updated that remote branch.
 I had to manualy run:
 
 git push origin f14:f14/master
 
 which done what I really wanted. This is bug or I done something wrong?

One part bug, one part user configuration.

If you do git config --add --global push.default tracking then fedpkg
push would do as you expect.  I need to make fedpkg push work regardless
of that local setting.

 
 Additionaly: how the new tags in git are going to appear. Is is supposed 
 to create fedpkg? Or should I manually create it using git tag and 
 git push --tags?

You don't need tags to build anymore, so fedpkg doesn't do anything with
them at this point.

 
 
 And btw: Thx. Big thx. Now I can really see what I did, which was in cvs 
 impossible (at least with my level of laziness).
 


- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxTEj4ACgkQ4v2HLvE71NVMOwCfUdU/WInufz8ocXbWp/AL6ROf
H9cAnioqaFCKemfCIrBljDFJAWq/8rrS
=dd7q
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 has been branched!

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/30/2010 10:24 AM, darrell pfeifer wrote:
 Are the koji static repos coming back soon? Current rawhide is mid-way
 through the boost/python havoc.

er... they never went away... What are you seeing?

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxTDdwACgkQ4v2HLvE71NVLRgCgxvse8iXb046r+fZfze8yZbXV
PIIAoLGavcRgTu+HVuDBVKEKE9UXJ/nI
=q3an
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: The move to git!

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/30/2010 02:13 AM, Martin Sourada wrote:
 Ok, so trying to update a package (libass) I've noticed a tiny problem:
 the fedpkg switch-branch does not seem to set up proper tracking of
 remote branches which then results in (uhm, I'm using git commit -a and
 git push, so you maybe handle this in fedpkg commit -p):
 
 pyfedpkg.FedpkgError: There are unpushed changes in your repo
 
 fedora-packager-0.5.0.1-3.fc12.noarch

This is my fault, I did all my design and testing with a git setting of
push.default tracking which instructs git to push to whatever branch
I'm tracking (which makes perfect sense to me, why isn't it a defaut?).
 Until fedpkg takes this into account, it's easiest to just do:

git config --global --add push.default tracking

Then you can easily push (and pull) from fedpkg switch-branch setups.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxTDxwACgkQ4v2HLvE71NUAiACcCK8OsJWHs2y43ikmiIwMrEt3
vJcAoKYqDJz9MeEDB1ocPPl8aG7X9Lvy
=xKCB
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: The move to git!

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/30/2010 01:02 AM, Michal Hlavinka wrote:
 On Friday 30 of July 2010 05:55:09 Jesse Keating wrote:
 ... Wiki
 pages
 will get filled out as knowledge of how to interact with dist-git
 starts
 to spread ( https://fedoraproject.org/wiki/Using_Fedora_GIT is a
 good
 start ).
 
 Thanks for your hard work! Could you describe this in more
 details:
 OLD CVS  | NEW GIT | Notes
 make tag |   N/A   | Explicitly tagging
 source states for package builds is no longer necessary.
 
 how this exactly
 works? What will happen in following cases? :
 1) commit some changes with
 release number change, commit another changes, build

The build attempt will use the latest content you pushed.  If you've
previously built something with that n-v-r the buildsystem will reject
the build, otherwise it'll continue.

 
 2) commit some changes
 with release number change, scratch build, commit rest of the changes,
 build

See above, the build would happen.

 
 3) commit some changes with release number change, someone else
 starts build, commit rest of the changes, build

The buildsystem will reject the build because one with the same n-v-r is
either in progress or completed successfully.

 
 4) commit some changes with
 release number change, build - fails because of typo/missing updated
 sources, commit fix, build

Build will go through because there are no successful builds with that n-v-r

 
 Michal


- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxTDI0ACgkQ4v2HLvE71NW+iACgkE2cIycWxBxbhVWia1ynIrKT
5xAAoKfpYdgxwlF3P3yx62SVccAMNVgW
=E9/3
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: The move to git!

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/30/2010 08:52 AM, Daniel J Walsh wrote:
 
 fedpkg build
  fedpkg build
 Traceback (most recent call last):
   File /usr/bin/fedpkg, line 959, in module
 args.command(args)
   File /usr/bin/fedpkg, line 297, in build
 mymodule.init_koji(args.user, kojiconfig)
   File /usr/lib/python2.7/site-packages/pyfedpkg/__init__.py, line
 1102, in init_koji
 defaults['serverca'])
   File /usr/lib/python2.7/site-packages/koji/__init__.py, line 1628,
 in ssl_login
 sinfo = self.callMethod('sslLogin', proxyuser)
   File /usr/lib/python2.7/site-packages/koji/__init__.py, line 1673,
 in callMethod
 return self._callMethod(name, args, opts)
   File /usr/lib/python2.7/site-packages/koji/__init__.py, line 1698,
 in _callMethod
 return proxy.__getattr__(name)(*args)
   File /usr/lib64/python2.7/xmlrpclib.py, line 1224, in __call__
 return self.__send(self.__name, args)
   File /usr/lib64/python2.7/xmlrpclib.py, line 1570, in __request
 verbose=self.__verbose
   File /usr/lib64/python2.7/xmlrpclib.py, line 1264, in request
 return self.single_request(host, handler, request_body, verbose)
   File /usr/lib64/python2.7/xmlrpclib.py, line 1294, in single_request
 response = h.getresponse(buffering=True)
 AttributeError: PlgHTTPS instance has no attribute 'getresponse'
 [Exit 1]
 
 Seems to be broken in Rawhide.
 
  rpm -q fedora-packager
 fedora-packager-0.5.1.0-1.fc14.noarch

Yeah, this is unfortunate, but something is broken in the xmlrpc stuff
in or around koji.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxTFj0ACgkQ4v2HLvE71NVI8wCeP1Dlv4oVg6fM6lCsKwIiS6+z
cLcAoJ1ArFu/cICQzh9uxzCZIJcT/yV0
=St51
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: The move to git!

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/30/2010 10:53 AM, Konstantin Ryabitsev wrote:
 On Fri, Jul 30, 2010 at 1:35 PM, Konstantin Ryabitsev
 i...@fedoraproject.org wrote:
 Hmm... Doesn't seem to be working at all for me.

 $ fedpkg co verbiste
 Traceback (most recent call last):
  File /usr/bin/fedpkg, line 959, in module
args.command(args)
  File /usr/bin/fedpkg, line 409, in clone
pyfedpkg.clone(args.module[0], args.user, args.path, args.branch)
  File /usr/lib/python2.6/site-packages/pyfedpkg/__init__.py, line
 302, in clone
_run_command(cmd)
  File /usr/lib/python2.6/site-packages/pyfedpkg/__init__.py, line
 115, in _run_command
stderr=sys.stderr, shell=shell)
  File /usr/lib64/python2.6/subprocess.py, line 483, in check_call
retcode = call(*popenargs, **kwargs)
  File /usr/lib64/python2.6/subprocess.py, line 470, in call
return Popen(*popenargs, **kwargs).wait()
  File /usr/lib64/python2.6/subprocess.py, line 621, in __init__
errread, errwrite)
  File /usr/lib64/python2.6/subprocess.py, line 1126, in _execute_child
raise child_exception
 OSError: [Errno 2] No such file or directory
 $ rpm -q fedora-packager
 fedora-packager-0.5.1.0-1.fc13.noarch
 
 Ah, as silly as it was, I didn't actually check whether git was
 installed -- I rather assumed it would be as a dependency. Everything
 works after actually installing git (though it's still a bug in
 fedora-packager deps).
 
 Regards,

Hrm, this is actually a bug in GitPython. It needs to depend on
/usr/bin/git.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxTFvoACgkQ4v2HLvE71NVW9wCgpA0QFI/ta3ErcOIwVWP9AOAr
efkAnjf0tGG4mAadskt5wl0sTidW
=HQ90
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: The move to git!

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/30/2010 01:49 AM, pbrobin...@gmail.com wrote:
 One thing I've never got around to working out how to do in git which
 is different from previous is dealing with branches. Where previously
 it was as simple as changing directories to deal with the various
 fedora releases obviously with real branches now we need to do
 something a little differnet. Could someone update the docs with
 details how to do this? I retried fedpkg switch-branch f-13 (and
 various other possible branch names) and using a git branch didn't
 give me any branches other than master. Could we also add some extra
 branch related commands to indicate things like listing the current
 branch, a list of all branches, and how we would commit a new spec to
 more than one branch.

https://fedoraproject.org/wiki/Using_Fedora_GIT#Merging is a good start
for this, and eventually we'll have tooling in fedpkg to facilitate
things like this.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxTDqkACgkQ4v2HLvE71NUESgCeKZ05rd4GWbes5FlBixhxej+Q
oTkAn1wjRrIQqJcRK7x/JPvnsQLP0XII
=YOf1
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedpkg/git issue

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/30/2010 10:57 AM, Orion Poplawski wrote:
   Tried to do a commit and seem to be in a bad state:
 
 [or...@orca paraview]$ fedpkg commit -p
 
 [master 6f6d9c7] Add patch to support python 2.7
   2 files changed, 18 insertions(+), 1 deletions(-)
   create mode 100644 paraview-3.8.0-py27.patch
 Warning: No xauth data; using fake authentication data for X11 forwarding.
 parse /etc/gitolite/conf/gitolite.conf-compiled.pm failed: Can't find 
 string terminator ' anywhere before EOF at 
 /etc/gitolite/conf/gitolite.conf-compiled.pm line 1296608.

I'm starting to think that when the new ACLs get compiled there is a
non-atomic switchout and you could be hitting it during that non-atomic
action.  This is just a guess though, going to talk with upstream.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxTHOYACgkQ4v2HLvE71NWQNgCdFAhGGY22nw9w0GBDKzmNAX1z
w8EAn28Kn7mblfmkp5KtnkSbhfNrqmIx
=3Lyv
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Massive broken deps and tagging into dist-f14?

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/30/10 7:13 PM, Mamoru Tasaka wrote:
 This morning I receided massive broken deps on F-14 and then received
 massive mails of tagging into dist-f14 tree. Can I assume that
 I can ignore these broken deps report or there is something I have
 to do for this?
 

Yes, you can ignore this.  It was my fault.  Tomorrow a better compose
should go through.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxTjBgACgkQ4v2HLvE71NWxnACgk4KNwyCgiArJx+6sGWWxtEKA
ik4AnRCY8qNokAQ1gPhIvs0RTkndLOu2
=8c7m
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Massive broken deps and tagging into dist-f14?

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/30/10 7:13 PM, Mamoru Tasaka wrote:
 This morning I receided massive broken deps on F-14 and then received
 massive mails of tagging into dist-f14 tree. Can I assume that
 I can ignore these broken deps report or there is something I have
 to do for this?
 

Yes, you can ignore this.  It was my fault.  Tomorrow a better compose
should go through.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxTjD0ACgkQ4v2HLvE71NWvxgCfVPT9jPV1/c6EGTPGPgzZsExQ
n7EAn1Qa1sywjonvCipBl9PBmQlMb935
=FsTt
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 branching and dist-git roll out

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/30/10 8:39 PM, Bruno Wolff III wrote:
 On Fri, Jul 30, 2010 at 22:24:59 -0500,
   Bruno Wolff III br...@wolff.to wrote:
 I noticed that the f14 repo from the kernel mirror seems to have only
 things that are tagged dist-f14 and no inherited stuff. (Note that
 while there is kitutuki-0.9.9c-1.fc13.i686.rpm, it's tagged both
 dist-f13 and dist-f14.)
 
 Probably related to this I got some broken package dependency warnings emailed
 to me that seem to be for things that weren't rebuilt for F14. Is it safe
 to ignore this batch of warnings?

Safe to ignore.  I've fixed it up and the next branched compose should
get all the packages.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxTrqkACgkQ4v2HLvE71NV0NQCglfIjzhLzQ6VqzqrFn/xCR9Td
UlkAnRkYjXFHgLVLmWZIUL9UA7z0pRrR
=QHZr
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: cgit instead of gitweb?

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/30/2010 12:11 AM, Rahul Sundaram wrote:
  Hi
 
 Any particular reason we are using gitweb at
 http://pkgs.fedoraproject.org/gitweb/.  Cgit is used in freedesktop.org
 is much more faster and resource efficient. 
 
 Rahul

No real reason other than we were already using gitweb-caching elsewhere
in infrastructure and at kernel.org.  I have on my todo list to trial
cgit tomorrow.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxSflQACgkQ4v2HLvE71NVadQCgr07cknrcq3lOlYo3JzjnZzIK
Y+wAoLq52cgK4ysHZzk9Vv61VUTYRwK8
=eq1H
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 branching and dist-git roll out

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/29/2010 07:14 AM, pbrobin...@gmail.com wrote:
 On Wed, Jul 28, 2010 at 10:18 AM, Jesse Keating jkeat...@redhat.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 07/23/2010 11:54 PM, Jesse Keating wrote:
 The conversion will take a couple days, which means our normal short
 outage for branching will be a bit extended.  I wish there was another
 way, but converting over 9K cvs repos into git repos does take some
 time.  I really feel that this move is worth the extended outage.

 The conversion process has begun.  We have just over 10K repos to
 convert, and nearly 200 are done already.  I'm employing a second host
 to help conversion to cut down on the over all outage time.
 
 Is there a running status report somewhere?
 
 Peter

Not really, but I can give a quick update.

Over 10K repos have been converted, but I do have to run a script over
those repos and make sure the conversion actually succeeded.  We've
also gotten dist-f14, dist-f13, dist-f12, and el6 in a state that we can
build with, however we do have to do some bootstrapping of el4/5.  I
have yet to look at OLPC-2/3.

We have run into some trouble with the kernel repo so I'm attempting
some different conversion options, with a final fallback position of
creating empty git repos and importing the last built srpms for each branch.

We've also identified some issues with gitweb that we are working on,
however this is not critical functionality and can be set aside until
after the outage.

Today's work will consist of getting el4/5 buildable, getting updates
pushed with a good production build of fedpkg, mass branching git and
turning on the buildsystem again.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxRwpgACgkQ4v2HLvE71NVJJgCbBGyB2ywy+FMZEPll7ZUe1YSg
KAoAoIlWGID8vEOl3zxuZaFq6XL1OxG4
=nsQg
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 branching and dist-git roll out

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/29/2010 11:10 AM, Tom spot Callaway wrote:
 On 07/29/2010 02:04 PM, Jesse Keating wrote:
 Over 10K repos have been converted, but I do have to run a script over
 those repos and make sure the conversion actually succeeded.  We've
 also gotten dist-f14, dist-f13, dist-f12, and el6 in a state that we can
 build with, however we do have to do some bootstrapping of el4/5.  I
 have yet to look at OLPC-2/3.
 
 This may be a dumb question (I'm full of dumb questions sometimes), but
 is there any documentation available on how to use the new setup? Even
 something as simple as pasting the new command equivalents (both with
 fedpkg and with git, if possible) for things like:
 
 * cvs checkout libfoo
 * cvs commit -m 'updated to libfoo 1.3' .
 * cd F-13  make tag  BUILD_FLAGS=--nowait make build
 
 Thanks,
 
 ~spot

I keep asking for help with this, but it looks like I my have to write
it all myself, which make take a while...

But for the typical tasks here we go:

I want to build a new libfoo for rawhide:
  fedpkg clone libfoo
  cd libfoo
  edit files
  fedpkg commit
  input commit message
  fedpkg push (this step could be skipped with fedpkg commit -p)
  fedpkg build

I want to build a new libfoo for Fedora 13:
Option A:
  fedpkg clone -b f13 libfoo
  cd libfoo
Option B:
  fedpkg clone libfoo
  cd libfoo
  fedpkg switch-branch f13
Option C:
  fedpkg clone -B libfoo
  cd libfoo/f13/

I want to import an srpm to my repo libfoo
  cd libfoo/
  fedpkg import path.to.srpm
  review changes
  fedpkg commit -p

I want to upload new sources (replacing existing ones)
  cd libfoo/
  fedpkg new-sources file [file file]

I want to add a new source file without replacing others
  cd libfoo/
  fedpkg upload file [file file]


Grabbing a recent fedora-packager build from
http://koji.fedoraproject.org/koji/packageinfo?packageID=5409 and
running fedpkg --help, then fedpkg target --help will give you a
better idea of what targets are available and how they can be used.

If somebody wants to take the above and start working on wiki pages,
please do so.  I beg you!

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxRx6YACgkQ4v2HLvE71NXdxACeNa4nS5rcpeeXzJfwzzYK+/oA
wCAAn1VTCnjfpZDs/2I+E46jDzucL7PL
=UAPo
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 branching and dist-git roll out

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/29/2010 11:18 AM, Iain Arnell wrote:
 On Thu, Jul 29, 2010 at 8:10 PM, Tom spot Callaway
 tcall...@redhat.com wrote:
 This may be a dumb question (I'm full of dumb questions sometimes),
 
 Even dumber question. Are bugzilla fedora-cvs flags getting renamed?
 And do we need to make New Package Git Requests now?
 
 
 

At some point yes, but not immediately.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxRx70ACgkQ4v2HLvE71NWhfwCgvJZ5vo1hS7K2tvvNHLLjCWkn
4iUAoL3HrEyXRBhxlVkg8NHOeAoxHpE8
=tDqm
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 branching and dist-git roll out

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/29/2010 11:51 AM, Tom spot Callaway wrote:
 On 07/29/2010 02:25 PM, Jesse Keating wrote:
 Option C:
   fedpkg clone -B libfoo
   cd libfoo/f13/
 
 This doesn't seem to work... perhaps because of the transition?
 
 http://fpaste.org/FV5g/
 
 If I can get this working, I'd be willing to help write wiki pages. :)
 
 ~spot

You've got the old fepdkg which is setup to hit the stg environment.
Grab one of the builds from the koji link I gave above.  However I did
just discover a bug with fedpkg clone -b that I have to fix up.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxRzy8ACgkQ4v2HLvE71NWUggCgk+Mcm9o0ExnmKbnKeDlPn6Rd
RjwAoLg0ZpmjAz7mXMVtK95ocqZn6WTI
=Og5s
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 branching and dist-git roll out

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/29/2010 11:48 AM, pbrobin...@gmail.com wrote:
 Completely ignore OLPC* they are historical and are no longer used.

I see active build targets in koji for dist-olpc{2,3,4},
olpc2-{ship2,trail3,update1}.  Are you saying we could remove all of
these targets?

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxR00gACgkQ4v2HLvE71NU87wCfeKwTOAOaukmMUg2R9MqHovsU
v6kAn0/CGllSN14KufqTQ2aKBCSzUnb7
=dABO
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 branching and dist-git roll out

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/29/2010 12:58 PM, Stephen Gallagher wrote:
 This didn't work for me. 'fedpkg push' just gives me:

You need a newer fedpkg.  I linked above to the latest builds.  We're
working on getting them pushed out in updates for people.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxR4NYACgkQ4v2HLvE71NVKwgCgxgBDUzocooMit2cKc7Ak0/ad
TiMAn1OOPWHVGMOC9OrPEy0mYT4pm4sF
=zw/V
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 branching and dist-git roll out

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/29/2010 11:04 AM, Jesse Keating wrote:
 On 07/29/2010 07:14 AM, pbrobin...@gmail.com wrote:
 On Wed, Jul 28, 2010 at 10:18 AM, Jesse Keating jkeat...@redhat.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 07/23/2010 11:54 PM, Jesse Keating wrote:
 The conversion will take a couple days, which means our normal short
 outage for branching will be a bit extended.  I wish there was another
 way, but converting over 9K cvs repos into git repos does take some
 time.  I really feel that this move is worth the extended outage.

 The conversion process has begun.  We have just over 10K repos to
 convert, and nearly 200 are done already.  I'm employing a second host
 to help conversion to cut down on the over all outage time.
 
 Is there a running status report somewhere?
 
 Peter
 
 Not really, but I can give a quick update.
 
 Over 10K repos have been converted, but I do have to run a script over
 those repos and make sure the conversion actually succeeded.  We've
 also gotten dist-f14, dist-f13, dist-f12, and el6 in a state that we can
 build with, however we do have to do some bootstrapping of el4/5.  I
 have yet to look at OLPC-2/3.
 
 We have run into some trouble with the kernel repo so I'm attempting
 some different conversion options, with a final fallback position of
 creating empty git repos and importing the last built srpms for each branch.
 
 We've also identified some issues with gitweb that we are working on,
 however this is not critical functionality and can be set aside until
 after the outage.
 
 Today's work will consist of getting el4/5 buildable, getting updates
 pushed with a good production build of fedpkg, mass branching git and
 turning on the buildsystem again.
 

Another update.  I've moved all the repos we have converted into the
production rpms directory.  This is read/write now.  I'm also in the
process of branching all of them for f14, but as this doesn't generate
any email, and I trust git to not screw things up this doesn't require
any outage.  Once the branching is done I'm going to update what
'dist-rawhide' targets so that builds from master will go to dist-f15,
the next rawhide.  I'll also build a new fedora-release for dist-f14/f15
that sets up the dist tags correctly.

el4/5 has been boot strapped so we can build there, although fedpkg
doesn't really work on el4.  We've taken some... extreme shortcuts to
get the buildsystem to work.  If somebody wants to work on porting
fedpkg to el4, be my guest :)

We were not able to successfully convert the kernel repo, so I'm going
to do the last ditch effort of creating an empty repo and importing the
last srpm.

We are getting very close to calling this conversion good enough to
run with.  A bigger announcement will come then.  Some wiki pages are
now up, thanks to spot and others,
https://fedoraproject.org/wiki/Using_Fedora_GIT

We just might finish up before the 48 hour window is up!

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxSCbgACgkQ4v2HLvE71NVzXACghLMQOBhUASg0RdYrFHz8NxiV
a54An0eqcvuO17npYxZAscHJzpAogy3V
=9dYI
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Outage: Build System - 2010-07-28 07:15 UTC

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/28/2010 12:05 AM, Jesse Keating wrote:
 There will be an outage starting at 2010-07-28 07:15 UTC, which will
 last approximately 48 hours.
 
 To convert UTC to your local time, take a look at
 http://fedoraproject.org/wiki/Infrastructure/UTCHowto
 or run:
 
 date -d '2010-07-28 07:15 UTC'
 
 Reason for outage: dist-git migration and Fedora 14 branching
 
 Affected Services:
 
 Buildsystem - http://koji.fedoraproject.org/
 CVS / Source Control
 
 Unaffected Services: All others
 
 Ticket Link: N/A
 
 Contact Information: Jesse Keating jkeat...@redhat.com or Oxf13 on IRC
 
 Please join #fedora-admin in irc.freenode.net or respond to this email
 to track the status of this outage.
 

The outage is now over.  We've migrated to dist-git and we've branched
for f14.  A more detailed announcement coming soon.  Make sure you have
fedora-packager 0.5.1 or better
(http://koji.fedoraproject.org/koji/packageinfo?packageID=fedora-packager).
 If you run into issues with your repos, let me know.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxSIKIACgkQ4v2HLvE71NWJWQCghzAF+uyWxm3lPRo2VKuyhre8
ofYAnA+AmzFQkhaHtqD9yN3T0nNxNLnt
=ffos
-END PGP SIGNATURE-
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

The move to git!

[Jesse Keating]

 the years (I've been
working on this off and on for nearly 4 years!) ranging from the built
in git cvsimport to git-svn to parsecvs and a few others.  In the end,
we took a page from the gnome project and used parsecvs (
http://cgit.freedesktop.org/~krh/parsecvs/ ) for the vast majority of
our repositories.  There were a few that gave parsecvs fits and recent
versions of git cvsimport were able to handle them.  The git system is
fantastic enough that we were able to merge our pseudo cvs branches into
actual git branches complete with a real shared history, but again I'll
spare you the details of the scripting to do this.  All but the kernel
repo  seems to have converted successfully which is a pretty good
success rate in my book.  We may yet get the kernel converted, but in
the interest of time we opted to start fresh with dist-git for now.

Without the help of many others, this project would never have gotten
done.  Folks helped out with Koji modifications, with fedpkg
contributions, with repeated testing of attempted conversions, with
logic checking of my plans, of helping me understand more of git
internals and deciphering error output, and most of all with being
patient while we worked through the transition and very positive along
the way.  Things will be bumpy over the next few weeks as we really
start putting distgit to the test.  No amount of staging and testing can
really replace production use.  There will be many more updates to
fedpkg as bugs are found and fixed and features are contributed.  Wiki
pages will get filled out as knowledge of how to interact with dist-git
starts to spread ( https://fedoraproject.org/wiki/Using_Fedora_GIT is a
good start ).

Once again I want to thank everybody who helped out and for all the
(continued) patience!  I'll be available via email and IRC as much as
possible the next few days to help anybody with dist-git issues.  Look
for Oxf13 on freenode.  Happy gitting!

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxSTR0ACgkQ4v2HLvE71NXEswCeOAu+EG/porsvkjMVq+4lAchy
VMgAn1DNwqyYcSSC3bwX/MQ/cfwx7qjs
=fBGf
-END PGP SIGNATURE-
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora 14 has been branched!

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

https://fedoraproject.org/wiki/Branch_Freeze_Policy

I know it's been a rough couple of days here, python-2.7 and boost
rebuilds creating build havoc, systemd creating some interesting
confusion, and dist-git to top it all off.  But we'll work through it as
best as we can, as we always do.  Onward into the future!

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxSTyUACgkQ4v2HLvE71NUOrACgh9lVjA6Seo8P8XVWKp9/G2Kv
AqgAn34YI89nUBWRHlkoiqkGNLcL0RXt
=ieir
-END PGP SIGNATURE-
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 branching and dist-git roll out

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/23/2010 11:54 PM, Jesse Keating wrote:
 The conversion will take a couple days, which means our normal short
 outage for branching will be a bit extended.  I wish there was another
 way, but converting over 9K cvs repos into git repos does take some
 time.  I really feel that this move is worth the extended outage.

The conversion process has begun.  We have just over 10K repos to
convert, and nearly 200 are done already.  I'm employing a second host
to help conversion to cut down on the over all outage time.

I was not able to get a fedpkg (fedora-packager) build out today,
however as soon as that repo is converted and we get the koji changes in
place to build from git we will use that as a test build and get the
updated fedpkg into your hands.

I've also started on some wiki work to change some CVS pages, but much
more will come.  Any help here is appreciated.

Thanks again for your patience!

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxP9eMACgkQ4v2HLvE71NV6jQCfRCSkB2BCvGchCVL7n2izoze6
L1oAniHdh0NNUc4c58Qh2mkr1XSUq0s0
=ZnFm
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 branching and dist-git roll out

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/28/2010 08:15 AM, pbrobin...@gmail.com wrote:
 So once the package is converted is the git repo read/write so we can
 begin updates or is it all down until the conversion is complete?

Kinda, but not for production use.  Once they are all converted I have
to move them into place and setup the git hooks.  I'm not doing that as
they are converted, but once the whole mess is done.

 
 Also is there a wiki page outlining the rough conversion from old to
 new commands and other such policy/procedure changes?

I'll be working on that (with help please!) today.  But rougly if you
did make something before, you'd do fedpkg something now.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxQXeYACgkQ4v2HLvE71NXfkgCgvvigBsin477BHe6hFByPzBMA
/M0An2B9siKoTVAH1AiKBU8kUfkn9q/G
=G41h
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Python 2.7 status: python2.7 is in dist-f14

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/28/2010 09:25 AM, David Malcolm wrote:
 Looks like a bug in the script that I used; it was meant to not move
 them, but in fact it did.

D'oh.  Due to an earlier bug in this script (which David successfully
fixed) I didn't notice this later bug, which David is also fixing.  My
fault.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxQX0sACgkQ4v2HLvE71NWMgwCgq7WEht2FEnj4ZYxujoT6MqIJ
1xEAnjr6GMjsdATz3PUwWBUbtXwS83yQ
=4SGI
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox 4 for Fedora 14?

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/28/2010 09:59 AM, Adam Williamson wrote:
 Nope. That's only for things that are declared as features. If you don't
 declare your version update to be a feature, you can happily do it right
 up to the release freeze.
 

I'd like to apply it to all packages, but I tend to get severe push back
whenever I suggest that.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxQZhkACgkQ4v2HLvE71NWaqgCfaUhloxcOP16OEMtmi3IpQLl8
ZqcAnRdP3q/DUQW0N/deazJw4JjyKjl1
=3cND
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: f14 boost-1.44.0 upgrade: notice of intent

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/26/10 5:05 PM, Benjamin Kosnik wrote:
 
 Hey. 
 
 The boost maintainers are planning to update the boost versions
 to the current release (1.44.0) in rawhide for F14. This is in keeping
 with the general plan to sync with boost every six months or so.
 
 See more detail here:
 https://fedoraproject.org/wiki/Features/F14Boost144
 
 Suggested plan is to push this to devel in the next 24 hrs, which will
 be announced on fedora-devel-annou...@redhat.com. 
 
 It is anticipated that this update will be less work than the
 1.39-1.41 transition.
 
 This update changes the SONAME of boost libraries, and adds some new
 libraries. All boost dependencies will have to be rebuilt. As always,
 timely assistance from package maintainers is welcome. 
 
 best,
 -benjamin

Do you have a list of packages which will need to be rebuilt?  This is
the last day before we branch, and with the dist-git outage there will
be a short time to fix things before the Alpha freeze.  Is anything in
the critpath dependent upon boost, or in the primary spins?

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxPGTMACgkQ4v2HLvE71NVfUwCfTqpmNHg4XUN6y6DMAKlyn+j3
h2UAn1zMoExqGHAZRhFiSTjpK2NwJxh8
=+nX+
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 branching and dist-git roll out

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/26/2010 10:25 AM, Chen Lei wrote:
 Can we filter out all .cvsignore and Makefile files it git repo? It
 seems those files are irrelevant to dist-git.

Yes, in the latest conversion scripts branch, import.log, and Makefile
files are removed.  The .cvsignore file is moved to .gitignore

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxNxjYACgkQ4v2HLvE71NVM4wCfUb2EuE1FSbI9bOdJDSVJw08/
avsAn3r1Piq20+NyojPQyxpmlMLina5D
=7LXo
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 branching and dist-git roll out

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/26/10 5:39 PM, Mark Rader wrote:
 Another dumb question.  I uploaded a package, frama-c. Will it be included in 
 14. 

If it has been built for rawhide prior to the branch event, then it will
be in 14.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxOQSQACgkQ4v2HLvE71NXUxQCglvoUN/gAJoEuft9udGInOTrO
jkQAoIplWkRH0HxTPkm4lIhmuyZR4006
=96u/
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora 14 branching and dist-git roll out

[Jesse Keating]

Hey all!  It's that time again, we're gearing up to branch for Fedora 14
this coming Tuesday!  There is a major twist this time around, we're
going to attempt a roll out of dist-git!

Dist-git is our replacement for the CVS system we are currently using.
This is a pretty big deal, but we're going to try to make it as smooth
as possible.  In the next few days I'll be finalizing our git server
setup and polishing up the user interface tool you all will be using to
interact with the source control and build system.

The conversion will take a couple days, which means our normal short
outage for branching will be a bit extended.  I wish there was another
way, but converting over 9K cvs repos into git repos does take some
time.  I really feel that this move is worth the extended outage.

The tool you all will use to interact with git and the buildsystem is
called fedpkg.  It comes from the fedora-packager package.  There is a
version of it available now in all active Fedora and EPEL releases,
although it is built to work against our staging environment where we
have been testing the setup for a while.  This setup is slightly
different than the final version, but you can install it and poke around
the help system to get a feel for what's going on.  Most of the make
targets have made it over and are named the same; build, sources, srpm,
etc...  Many of the targets can take arguments and options.  Where the
make system used shell variables, fedpkg uses options and arguments.
Each target takes a --help argument that will show any available
options.  Fedpkg does not yet have a man page, that may be coming soon.

We're also going to be working on wiki pages to document the new stuff
and archive the old stuff.  We're going to need help on this too, so if
you want to pitch in, by all means!

As I mentioned above, this is an attempt.  We are trying this pretty
early, which I wouldn't normally do.  However we have a good roll back
plan.  We are going to keep the CVS server as is, although turned
read-only during and after the dist-git rollout.  If something fails
beyond reasonable repair with the dist-git attempt we will re-enable
write access to the CVS server (after we branch it for Fedora 14).
Otherwise we will keep it around, in some capacity, as a read-only
reference point.

I'm certain we will run into some bumps along the way, and some wrinkles
to iron out.  I ask that you are patient with us as we work through
these, and as we either get updates pushed out of fedpkg or make
adjustments to the git repos on the git server.  This transition has
been a long time coming, and I'm really happy to be the one to make it
happen.  Keep in mind that this will be the first iteration of our
transition, and it will operate mostly the same as dist-cvs did with a
few improvements.  Later on we will start to explore more interesting
advancements such as automatic patch management with exploded sources,
linking to upstream source repositories, automatic %changelog generation
from git changelogs, or things I haven't even thought about.  Most of
all, we won't be using CVS any more and that feels really good to me.

If you're curious about how the new system will work or have concerns,
or want to help, you can reply to this email thread or find me on IRC as
Oxf13 (that's an o, not a zero).  If you run across bugs in fedpkg,
you can file them in the fedora-packager hosted trac space
https://fedorahosted.org/fedora-packager/ or just find me on IRC as well.

Thanks again for your patience, both in waiting so long for us to make
this move, and for bearing with us during the transition.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [dist-git] gitweb or list of all available Git repositories?

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/22/2010 07:41 AM, Severin Gehwolf wrote:
 Hi,
 
 We are working on an Eclipse plug-in for Fedora Packagers, which
 provides tooling for RPM packaging for Fedora (without needing to
 resort to CLI). Since we are planning on supporting dist-git, it
 would be nice if there was a list of all Git repos we could query.
 For example, somebody interested in packaging, say
 eclipse-fedorapackager, but not knowing the exact name of the Git
 repository, might want to look for something like eclipse-*. Then,
 one would get a list of available Git repos starting with eclipse-
 and the user could proceed with cloning the desired repository. In
 order to do this, we'd need a list of all available Git repositories
 available for Fedora packaging. Is something like that around? Will
 gitweb be available for dist-git any time soon? Are there other
 options we could use?
 
 Thanks! Severin

Hi Severin!  I'm glad to see you'll be working on dist-git.  I urge you
to look at fedpkg, and the pyfedpkg library (in fedora-packager).  I've
tried to keep all the logic in the library in a way that will be usable
to other frontends than the CLI, and keep the CLI frontend just an
option parser and interface to the library.  I hope the library would be
of use to eclipse, but since it's in Python it might not be.

I do plan on having git-web enabled, but for now you could get a list of
packages in dist-rawhide from koji and assume that a repo exists for all
of them.  For the newest packages that isn't quite true, things added
since the last migration snapshot, but for the most part it'll be true.

koji list-pkgs --tag dist-rawhide

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxIn1AACgkQ4v2HLvE71NXC7QCeKBraVBlcR707DtmP27pZAPA0
wY8AoLMuOTj9NPo7ZhAntxhay4o7DA87
=nMmA
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: dist-git wordsmithing wanted

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/20/2010 10:48 PM, Pierre-Yves wrote:
 On Tue, 2010-07-20 at 22:38 -0700, Jesse Keating wrote:
 $ make tag
 Make system retired, please use fedpkg.  See fedpkg --help

 Suggestions on what to put in here?
 Might be nice to already print the equivalent command:
 
 $ make tag
 Make system retired, please use fedpkg. 
 The equivalent function is: 
 For more information see fedpkg --help
 
 But that might be a bit long though.
 
 Pierre
That'd make for an overly complicated Make file too.  Right now what I
have is along the lines of:


$ cat Makefile
# Makefile for source rpm: pungi
# $Id$
.PHONY :: $(ARCHES) sources uploadsource upload export check build-check
build cvsurl chain-build test-srpm srpm tag verrel new clean patch prep
compile install install-short compile-short FORCE local scratch-build
scratch-build-% srpm-scratch-build srpm-scratch-build-% clog

all:
@echo Make system retired, please use fedpkg.  See fedpkg --help

i386 i686 x86_64 ppc ppc64 noarch sources uploadsource upload export
check build-check build cvsurl chain-build test-srpm srpm tag verrel new
clean patch prep compile install install-short compile-short FORCE local
scratch-build srpm-scratch-build clog: all

scratch-build-%: all

srpm-scratch-build-%: all

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxGkrcACgkQ4v2HLvE71NXvKQCgoa9C8dAeTuZ4bLgvrTsUcdUV
7WwAoLw67V1Xltg/3OJ3VSy0PkyJ51ro
=PdzK
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Question regarding dist-git aesthetics with branches

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/21/2010 01:55 AM, Hans Ulrich Niedermann wrote:
 On Tue, 2010-07-20 at 22:15 -0700, Jesse Keating wrote:
 
 On 07/20/2010 08:55 PM, Garrett Holmstrom wrote:
 On 7/20/2010 19:13, Hans Ulrich Niedermann wrote:
 BTW, while typing the above, I have noted that master or devel or
 f13 are quite easy to type, while F-13 with capital letter and
 hyphen is relatively complicated. Perhaps that could be an argument when
 choosing branch names.

 Using names like f13, el5, and so forth would also keep dist-git 
 consistent with git branch naming conventions.  If we were to do 
 something like that we might as well just use the value of %{dist}.

 That was going to be my next question, although that would bring back
 the c in fc13 and fc14 since that's what the dist value is.  We could
 bite the bullet and change the dist value to remove the c, and just
 manually keep track of making sure that builds on older releases won't
 be newer than builds on the newer branches.  not sure if we want to go
 through that pain at this point.
 
 Don't we have a (few) mass rebuilds in front of us before F-14 anyway?
 gold and similar stuff? That would increase the R of N-V-R anyway, so we
 could switch %{dist} from fc14 to f14 at the same time for probably the
 majority of packages.

The majority of packages aren't going to be rebuilt.

 
 Oh. Darn. We still need to make sure that *.fc12 and *.fc13 packages do
 not have the same N-V-R modulo %{dist} as F14 has, until F13 is EOLed,
 i.e. until F15 comes out. That still sounds ugly. Well, all of that is
 ugly regarding the c, whatever we do or do not do.

The other option is to make the dist translation change on the other
branches too, so that future f12 and f13 builds have a dist of .f12
and .f13

 
 If rawhide development is supposed to happen on origin/master, then how 
 do branches for rawhide work?  Does fedpkg just default to building for 
 rawhide when a branch doesn't appear in a release's branch namespace?

 Yes. Branches of rawhide would be of the form origin/branch so if we
 don't find one of our expected f(c)??,el?,olpc? we default to building
 for rawhide.
 
 I was not aware that rawhide would be basically origin/master. In that
 case, it would be really obviously nice to be able to have branches
 master, f13 and f12 (without any slashes) in the local repo and
 have things just work for that case.
 
 Perhaps fedpkg could support both simple clones where the developer's
 local repo has just three branches tracking upstream
 
  master - origin/master
  f13- origin/f13/master
  f12- origin/f12/master
 
 or for people with more complex needs
 
  master - origin/master
  f13/master - origin/f13/master
  f12/master - origin/f12/master

The problem is in inconsistency.  Makes things harder for scripted
rebuilds which I'd expect to run on the f13/master branch.  For the
local clone, I was going to have fedpkg call the branches by their base
name, so

master - origin/master
f13 - origin/f13/master
f12 - origin/f12/master

 
 Which gives me an idea. What if we had
 
  master - origin/master
  f13- origin/f13
  f12- origin/f12
  F13/foo
  F12/bar
 
 and in addition to that, any local branch named like F13/* would be
 built for f13? That would give direct 1:1 git repo cloning, with still
 making it possible to deduce the target from branch names if so desired
 by the packager.

hrm, I'm not really in favor of having both f13 and F13/foo, that
just seems like a recipe for lots of typo disasters.

 
 We could even use fc13 and f13/foo to make the confusion complete
 and nail down the c requirement for the next 20 years... :-)
 
 


- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxHQOMACgkQ4v2HLvE71NWGqwCgoae3JCgIgCosQwQC+fVDGiTs
wK0AoL+bIW8hEdJP/jlsJefhyAgSVBiw
=NDAr
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Question regarding dist-git aesthetics with branches

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/20/2010 11:22 PM, Roland McGrath wrote:
 Using names like f13, el5, and so forth would also keep dist-git 
 consistent with git branch naming conventions.  If we were to do 
 something like that we might as well just use the value of %{dist}.
 
 But that's just too obviously right for us to be allowed to do it!
 
 That was going to be my next question, although that would bring back
 the c in fc13 and fc14 since that's what the dist value is.  We could
 bite the bullet and change the dist value to remove the c, and just
 manually keep track of making sure that builds on older releases won't
 be newer than builds on the newer branches.  not sure if we want to go
 through that pain at this point.
 
 I'd say bite the bullet.  Die, little c, die!  It just looks silly there
 nowadays, since the C-word has not been in our vocabulary for so long now.
 
 What does manually mean, anyway?  A database query and a short script?
 Roll it into existing nag mail or update sanity-checking stuff?  This seems
 like a simple enough matter among all the things we're nowadays trying to
 have some coherent checking for.

Well, we don't have autoqa live as of yet, live enough to prevent n-v-r
mishaps from going out to users.  So it would take some maintainer
diligence.  Honestly though if we were going to make a dist eval change
I'd want to make it across all the active branches and reduce the
potential for n-v-r mishaps.

 
 Yes. Branches of rawhide would be of the form origin/branch so if we
 don't find one of our expected f(c)??,el?,olpc? we default to building
 for rawhide.
 
 Where is the mapping of branch name patterns to koji build targets going to
 live?  Is it just in fedpkg locally and you'll change the norm only by
 pushing a fedora-packager update in each release?  (That doesn't sound very
 likely.  People use older Fedoras with older fedora-packager installed to
 commit and trigger newer dist builds.)  Or is it partly local and partly
 gotten from the (koji?) server, or what?  (In the CVS system this is the
 common/branches file, which is both locally available in that it's a local
 file in your common/ checkout, and centrally maintained in CVS.)

It'll live within fedpkg.  It will basically make the assumption that if
you're on a branch, eg f13, it'll target
'dist-branch-updates-candidate'.  And if you're not on a branch, it'll
target 'dist-rawhide'.  We'll do koji magic to make sure 'dist-rawhide'
points things in the right direction, but the upshot is that nothing
needs to change on the developer's system each time we branch and start
up a new release.

 
 
 Thanks,
 Roland


- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxHQf0ACgkQ4v2HLvE71NX1SQCeOjfx6i8t+eYflJ5NknDZySvQ
zAcAoK9SgJKtQ7n1jSYXEInv4qdWgolp
=xVdV
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Is import.log of any use?

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Not sure if I've asked the wider audience here, but is the import.log
file of any use to anybody?  It's one more file that might differ
between branches even when all else is the same, and I don't necessarily
want to keep munging it with fedpkg when importing items.  Would anybody
cry if this file went away?

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxHUJsACgkQ4v2HLvE71NW6cACgr1C4fNyvlPYTd15118mA4DZ4
gdsAnA6U0UgwgGkezttpRlrhJEihHt4Z
=IBTn
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Question regarding dist-git aesthetics with branches

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/20/2010 05:52 AM, Hans Ulrich Niedermann wrote:
 On Fri, 2010-07-16 at 17:07 -0700, Jesse Keating wrote: 
 
 I've been struggling with a particular wrinkle in dist-git, how fedpkg
 is supposed to reliably discover what Fedora release a packager is
 working on.
 
 In other words: How does fedpkg map the currently checked out git HEAD
 to a Fedora release? (Unless fedpkg is specifically given a Fedora
 release to build for on the command line.) 

That's right.

 
 In the CVS world, we used a branch file.  This is OK, but I think it
 would be cleaner if we didn't have to rely upon that.  It's the last
 file that wouldn't be exact across all the Fedora releases if a package
 is kept in sync.  So what I'd like to do is rely upon discovering the
 top level upstream branch, say F-13.  
 
 100% Ack.
 
 This gets difficult if we allow maintainers to create and operate on
  their own upstream branches (which we should), as I have not found a
  reliable way to work from a local branch to which remote branch it
  tracks to which top level remote branch it was created from.
 
 Is this problem solvable at all? Every merge commit has (at least) two
 parents. If you have once merged the F-12 branch into the F-13 branch,
 how can fedpkg decide which of the parents was the real one to track
 back to?

I don't think it is solvable, without enforcing some form of naming
convention.

 
 One suggestion has been to make use of directory based branching, so
 that any maintainer created branch is in a subdir of a top level branch.
 
 This phrasing might be a little confusing. We are NOT talking about
 having different branches' files in different subdirectories on the
 filesystem here, like we were doing with the CVS checkouts. We are
 talking about branches named like directories (e.g. 'F-13/foo').

I'm going to make it slightly more confusing here, but bear with me.  As
far as the client is concerned and maintainer checkouts, there will not
be a subdirectory.  These are real git branches and you switch between
them which will update your working copy.  The branches would just be
named with a directory like structure.

Now, on the back end, the git repo server, the git metadata would
actually create a F-13 directory and put things like the master and
other files within that directory.  Clients don't care about this, but
it does make some things convenient when looking at the git repo structure.

There is also a fedpkg command that will setup your git checkouts to
look like it did with CVS, where you have module/devel module/F-13
module/F-12 etc...  and there would be a clone/checkout in each of
those subdirs from the appropriate remote branch.

   
 EG we'd a user could create an F-13/kernel-2.7 branch, and call it
 whatever they want locally.  fedpkg would be able to work from the local
 branch name to what it tracks (origin/F-13/kernel-2.7) and walk down the
 path from origin/ to discover F-13.  Then fedpkg can assume F-13 for the
 branch and do all the dist conversions and koji target discovery from
 that.  This doesn't put too much restraint on what maintainers call
 their branches, particularly locally.

 The wrinkle with the above though is the base top level branch.  When we
 do this with directories, it's not possible to have a simple origin/F-13
 branch that a user could interact with (git checkout F-13 would
 automatically detect that there is an origin/F-13 remote branch and
 setup a local F-13 branch to track it and still allow for an
 F-13/foobar branch.  So we have to make the first base upstream branch
 F-13/something.  One suggested something has been to call it HEAD,
 because git seems to have another short cut that would allow you to do
 git checkout -b origin/F-13 and since it finds an origin/F-13/HEAD it
 will automatically use that.  HEAD seems to be a special name in this
 context.  However it is pointed out that using HEAD here could be
 confusing to people who are more familiar with git and naming
 conventions.  Another suggestion is to call it F-13/master since
 master is a more appropriate and expected name.  However that means
 you can't use the short cut and have to do a full git checkout -b F-13
 origin/F-13/master.  Since you have to use the full path here, we
 aren't bound by the name master and we could name it anything we want,
 something that might make sense to Fedora or dist-git.
 
 I would call it something short and sweet and to the point. Using
 F-13/HEAD appears hackish, and does things one might not expect, so I
 would be careful with that. 
 
 Whether it is called F-13/master, F-13/koji, or F-13/official, however,
 I don't care, as long as it is consistent over all packages.
 
 Now, these are fairly low details which can be hidden behind fedpkg
 (there is a proposed patch to give fedpkg a 'switch-branch' command that
 will switch you from one to the other, and we can make calls to F-13
 attempt origin/F-13/master or whatever), but I

Re: Question regarding dist-git aesthetics with branches

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/20/2010 03:07 PM, Adam Williamson wrote:
 On Tue, 2010-07-20 at 09:03 -0400, Toshio Kuratomi wrote:
 On Mon, Jul 19, 2010 at 03:09:50PM -0700, Jesse Keating wrote:

 Seriously?  Nobody has an opinion here?  Or will this just be another
 case of ZOMG WHY DID YOU DO THIS STUPID THING as soon as it rolls out...

 I'm not around enough right now to be able to test anything :-(.

 I also don't really understand the choices you're presenting since they're
 based on git conventions that I don't know.  master is just a convention in
 git?  HEAD is treated specially but doesn't exist normally in a repository?

 I think the only way to do this is to implement one thing and then be
 willing to either change that (or let someone else contribute work to change
 it) once people use it and tell you ZOMG WHY [...].
 
 Definitely this is where I stand. It's too new and different for me to
 have a reliable mental map of it to know what to think.

Thankfully it's pretty easy to move this stuff around if we need to
after the conversion.  It may break people's existing clones, but those
are cheap.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxGH/MACgkQ4v2HLvE71NUxbgCeN3f4zmg4oyiig+f35LqzriUq
YwcAnRbz4aLYDgOGtDtTyDW8IEpegQqH
=5QUJ
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Question regarding dist-git aesthetics with branches

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/20/2010 03:32 PM, Michael Cronenworth wrote:
 Roland McGrath wrote:
 My first suggestion was not to have the magical leading F-n/
 matching at all.  Rather, just have fedpkg front-end commands set and
 show the state of branch.SOMEBRANCH.fedora-target settings.  e.g.,
 'fedpkg checkout foo' would both do 'git checkout foo' and set the
 branch.foo.fedora-target automatically.
 
 +1 to this. After switching from CVS to git for my own projects over the 
 course of the past year I am beginning to see the high value in 
 branching with git. Linus' suggestion of using branches everywhere is 
 something hard to grasp at first but it is the right direction.
 
 Here's one nice feature I'd like to see for a simple scenario of when 
 upstream releases a new stable version:
 
 1. Edit the 'master' branch spec file.
 2. git commit my change.
 3. git rebase my F-* branches to master.
 4. Submit my builds!
 
 Keeping separate directories per release seems cumbersome and I just 
 submitted my first package yesterday. You guys have been doing far too 
 much work with the current method of package upkeep. :P

I think you've misunderstood the proposal.  There won't be separate
directories per release, just separate branches.  The branch names will
look like they have directory structure though, which will help
programatically detect the Fedora target.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxGKrUACgkQ4v2HLvE71NXRAQCfaNvQ78C3OKvp8uSd/uX+Uu1r
wT4An2KH7XmN/QVTBxG1GTGhcbgkbjZM
=FpZ/
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Question regarding dist-git aesthetics with branches

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/20/2010 08:55 PM, Garrett Holmstrom wrote:
 On 7/20/2010 19:13, Hans Ulrich Niedermann wrote:
 BTW, while typing the above, I have noted that master or devel or
 f13 are quite easy to type, while F-13 with capital letter and
 hyphen is relatively complicated. Perhaps that could be an argument when
 choosing branch names.
 
 Using names like f13, el5, and so forth would also keep dist-git 
 consistent with git branch naming conventions.  If we were to do 
 something like that we might as well just use the value of %{dist}.

That was going to be my next question, although that would bring back
the c in fc13 and fc14 since that's what the dist value is.  We could
bite the bullet and change the dist value to remove the c, and just
manually keep track of making sure that builds on older releases won't
be newer than builds on the newer branches.  not sure if we want to go
through that pain at this point.

 
 If rawhide development is supposed to happen on origin/master, then how 
 do branches for rawhide work?  Does fedpkg just default to building for 
 rawhide when a branch doesn't appear in a release's branch namespace?

Yes. Branches of rawhide would be of the form origin/branch so if we
don't find one of our expected f(c)??,el?,olpc? we default to building
for rawhide.


- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxGgokACgkQ4v2HLvE71NV8WwCfcVOK9lNRJwb+RQJC22Ngixk3
Oa0AoMVsIdKMM3xqw28UwibrivN5Fy9z
=hKZP
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

dist-git wordsmithing wanted

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It was suggested to keep the Makefile that exists in every package
module/branch in CVS right now, but set it up so that any Make command
issued would print a reminder to the user that the Make system has been
retired and to use fedpkg.  I could use some word smithing on this
message.  What I have right now is this:

$ make tag
Make system retired, please use fedpkg.  See fedpkg --help

Suggestions on what to put in here?

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxGh8QACgkQ4v2HLvE71NX/XwCfboto3bl8DxzSuVMH6HaSUhja
j1gAnRoBJAjTZhIN5i7JDwxBdo/3UYb1
=cWMe
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Question regarding dist-git aesthetics with branches

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/16/10 5:07 PM, Jesse Keating wrote:
 I've been struggling with a particular wrinkle in dist-git, how fedpkg
 is supposed to reliably discover what Fedora release a packager is
 working on.
 
 In the CVS world, we used a branch file.  This is OK, but I think it
 would be cleaner if we didn't have to rely upon that.  It's the last
 file that wouldn't be exact across all the Fedora releases if a package
 is kept in sync.  So what I'd like to do is rely upon discovering the
 top level upstream branch, say F-13.  This gets difficult if we allow
 maintainers to create and operate on their own upstream branches (which
 we should), as I have not found a reliable way to work from a local
 branch to which remote branch it tracks to which top level remote branch
 it was created from.
 
 One suggestion has been to make use of directory based branching, so
 that any maintainer created branch is in a subdir of a top level branch.
  EG we'd a user could create an F-13/kernel-2.7 branch, and call it
 whatever they want locally.  fedpkg would be able to work from the local
 branch name to what it tracks (origin/F-13/kernel-2.7) and walk down the
 path from origin/ to discover F-13.  Then fedpkg can assume F-13 for the
 branch and do all the dist conversions and koji target discovery from
 that.  This doesn't put too much restraint on what maintainers call
 their branches, particularly locally.
 
 The wrinkle with the above though is the base top level branch.  When we
 do this with directories, it's not possible to have a simple origin/F-13
 branch that a user could interact with (git checkout F-13 would
 automatically detect that there is an origin/F-13 remote branch and
 setup a local F-13 branch to track it and still allow for an
 F-13/foobar branch.  So we have to make the first base upstream branch
 F-13/something.  One suggested something has been to call it HEAD,
 because git seems to have another short cut that would allow you to do
 git checkout -b origin/F-13 and since it finds an origin/F-13/HEAD it
 will automatically use that.  HEAD seems to be a special name in this
 context.  However it is pointed out that using HEAD here could be
 confusing to people who are more familiar with git and naming
 conventions.  Another suggestion is to call it F-13/master since
 master is a more appropriate and expected name.  However that means
 you can't use the short cut and have to do a full git checkout -b F-13
 origin/F-13/master.  Since you have to use the full path here, we
 aren't bound by the name master and we could name it anything we want,
 something that might make sense to Fedora or dist-git.
 
 Now, these are fairly low details which can be hidden behind fedpkg
 (there is a proposed patch to give fedpkg a 'switch-branch' command that
 will switch you from one to the other, and we can make calls to F-13
 attempt origin/F-13/master or whatever), but I feel that this is a
 detail I shouldn't just decide on my own.  So, I welcome the discussion.
  I also welcome anybody challenging the above assumptions and showing us
 an even better way of managing the branch naming and discovering client
 side what Fedora target a maintainer wishes to work against.  I will
 however put some constraints on that.  A maintainer shouldn't have to
 modify anything in their local clone to indicate what target, fedpkg
 should be able to do a clone of a repo, switch to a branch (which may be
 a branch of a branch of a branch) and be able to discover what the
 target should be.
 
 Thanks!
 

Seriously?  Nobody has an opinion here?  Or will this just be another
case of ZOMG WHY DID YOU DO THIS STUPID THING as soon as it rolls out...

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxEzSsACgkQ4v2HLvE71NUemwCcDatkXaTQV1+2Kji7AwtATWkO
dmYAoJaZMAkUY5lLWhIsDqa7moXyymKp
=K2b5
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Question regarding dist-git aesthetics with branches

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've been struggling with a particular wrinkle in dist-git, how fedpkg
is supposed to reliably discover what Fedora release a packager is
working on.

In the CVS world, we used a branch file.  This is OK, but I think it
would be cleaner if we didn't have to rely upon that.  It's the last
file that wouldn't be exact across all the Fedora releases if a package
is kept in sync.  So what I'd like to do is rely upon discovering the
top level upstream branch, say F-13.  This gets difficult if we allow
maintainers to create and operate on their own upstream branches (which
we should), as I have not found a reliable way to work from a local
branch to which remote branch it tracks to which top level remote branch
it was created from.

One suggestion has been to make use of directory based branching, so
that any maintainer created branch is in a subdir of a top level branch.
 EG we'd a user could create an F-13/kernel-2.7 branch, and call it
whatever they want locally.  fedpkg would be able to work from the local
branch name to what it tracks (origin/F-13/kernel-2.7) and walk down the
path from origin/ to discover F-13.  Then fedpkg can assume F-13 for the
branch and do all the dist conversions and koji target discovery from
that.  This doesn't put too much restraint on what maintainers call
their branches, particularly locally.

The wrinkle with the above though is the base top level branch.  When we
do this with directories, it's not possible to have a simple origin/F-13
branch that a user could interact with (git checkout F-13 would
automatically detect that there is an origin/F-13 remote branch and
setup a local F-13 branch to track it and still allow for an
F-13/foobar branch.  So we have to make the first base upstream branch
F-13/something.  One suggested something has been to call it HEAD,
because git seems to have another short cut that would allow you to do
git checkout -b origin/F-13 and since it finds an origin/F-13/HEAD it
will automatically use that.  HEAD seems to be a special name in this
context.  However it is pointed out that using HEAD here could be
confusing to people who are more familiar with git and naming
conventions.  Another suggestion is to call it F-13/master since
master is a more appropriate and expected name.  However that means
you can't use the short cut and have to do a full git checkout -b F-13
origin/F-13/master.  Since you have to use the full path here, we
aren't bound by the name master and we could name it anything we want,
something that might make sense to Fedora or dist-git.

Now, these are fairly low details which can be hidden behind fedpkg
(there is a proposed patch to give fedpkg a 'switch-branch' command that
will switch you from one to the other, and we can make calls to F-13
attempt origin/F-13/master or whatever), but I feel that this is a
detail I shouldn't just decide on my own.  So, I welcome the discussion.
 I also welcome anybody challenging the above assumptions and showing us
an even better way of managing the branch naming and discovering client
side what Fedora target a maintainer wishes to work against.  I will
however put some constraints on that.  A maintainer shouldn't have to
modify anything in their local clone to indicate what target, fedpkg
should be able to do a clone of a repo, switch to a branch (which may be
a branch of a branch of a branch) and be able to discover what the
target should be.

Thanks!

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxA9DgACgkQ4v2HLvE71NU9hwCghhorcU8oz/gAWKk3h76q+h7r
T2sAn0MfdRwHR+niHYQPIAWkaMhHLF1f
=xc1g
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] The systemd unit files I'll post

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/15/10 10:08 AM, Bill Peck wrote:
 Dovecot generating its SSL parameters can take 10 seconds on the first
  startup, so that would be another one with a problem.
 
 What about generating these in %post of the rpm install?  Seems to make 
 sense to me.
 

That will break systems that are deployed via imaging, or live images.
Every system imaged would have the same ssl cert

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkw/Q9MACgkQ4v2HLvE71NXmoQCgrDUyxcphdrg9U5HS1MIbzWEC
VvMAn0pZ26MFiAOcIgVeIS6U1fs83xnL
=zJpf
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: dist-git testers wanted!

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/13/10 1:55 PM, Orion Poplawski wrote:
 On 07/12/2010 05:28 PM, Jesse Keating wrote:
 Thanks in advance! (and find me on IRC or file tickets against
 fedora-packager in fedora hosted if you run into issues)
 
 fedpkg clone --branches fails.
 
 https://fedorahosted.org/fedora-packager/ticket/20
 

Fixed with
https://fedorahosted.org/fedora-packager/changeset/55a04fd2883fadb427525fda32e4e89481cf6314

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkw9a/QACgkQ4v2HLvE71NWR6wCgiswwrSsPP4of6sbHJRbKBGq1
12QAoI4QXSjfE8VGcOloH6+7c1J0499z
=GY0Q
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Want to get your hands dirty with hacking on fedpkg?

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Now that people are testing it, the tickets are rolling in for various
issues.  While I could fix them all, there is an opportunity for folks
to help out here and pick off some of the bugs.

https://fedorahosted.org/fedora-packager/query?status=newstatus=assignedstatus=reopenedcomponent=fedpkgorder=priority

The above link will give you a list of the open tickets.  If you want to
work on something, please take assignment away from me and accept the
ticket.  I'll accept the ones I'm working on too.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkw+ApEACgkQ4v2HLvE71NWwkQCdGwIZa7BaOcVC3OQAqhPiGopx
0/4AoKUJSKXUXOyHdgqTwjZYyqcazQ0Z
=8/8/
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: concept of package ownership

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/13/10 2:43 AM, Patrice Dumas wrote:
 On Tue, Jul 06, 2010 at 09:35:32AM -0700, Jesse Keating wrote:

 The system is fairly open with regard to just about everything except
 attitude.  Currently it's mostly attitude that prevents openness.
 
 The ACL system restrict changes to other people packages to provenpackagers.
 And then the policies restrict a lot what provenpackages can do. So, the
 system is not very open, at least very unlike what Adam described.
 

Right, the attitude has led to policy of what provenpackagers can do,
but the underlying system is open.  All it takes is an attitude change
as nothing else is preventing provenpackagers from doing more.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkw8jdUACgkQ4v2HLvE71NUyggCgrJOtrWOEry+OUh6h6tRn5y1w
RaEAn37hTdMBziF/Zb8+3DQJI4XQNLFy
=hhxu
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: dist-git testers wanted!

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/13/10 4:34 AM, Laurent Rineau wrote:
 On Tuesday 13 July 2010 01:28:50 Jesse Keating wrote:
 We're ready for the next phase of dist-git migration testing.  Building!
  We now have a staging koji server that has been modified to accept
 builds from our test dist-git server.  I've also updated fedpkg (in the
 fedora-packager package) to build against this koji instance.  What I
 would like is for people to do some trials, duplicate what they are
 doing in dist-cvs over on dist-get with fedpkg and try to build things
 so that we can get a picture of where things are falling over, or where
 things are working.

 We're also looking for people that will help create draft modifications
 to documentation regarding CVS.  I can be a source of info for how
 things work in dist-git and I need volunteers to get the info from me
 and translate it into draft wiki pages.

 Another recently done target in fedpkg is the import command, which
 can be used to import contents from an srpm.  I have tested it somewhat,
 but I'd like more people who regularly use cvs-import.sh to try it as well.

 So grab fedora-packager-0.4.2.3 (may have to enable updates-testing)
 
 For the moment, Yum on Fedora 13 says:
 
 Error: Package: fedora-packager-0.4.2.3-1.fc13.noarch (updates-testing)
Requires: GitPython = 0.2.0
Installed: GitPython-0.1.6-2.fc13.noarch 
 (@anaconda-InstallationRepo-201005130101.x86_64)
 

Wait a tic, 0.2.0 is tagged as dist-f13-updates...  so it should be in
stable updates.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkw8jwgACgkQ4v2HLvE71NUOPACfQYCvstZ0iBL2yKVnjQh7JkZL
J3kAn2PLqZ9KdOD9DvGZDpAzGevp6BV9
=jkov
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: dist-git testers wanted!

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/13/10 4:34 AM, Laurent Rineau wrote:
 On Tuesday 13 July 2010 01:28:50 Jesse Keating wrote:
 We're ready for the next phase of dist-git migration testing.  Building!
  We now have a staging koji server that has been modified to accept
 builds from our test dist-git server.  I've also updated fedpkg (in the
 fedora-packager package) to build against this koji instance.  What I
 would like is for people to do some trials, duplicate what they are
 doing in dist-cvs over on dist-get with fedpkg and try to build things
 so that we can get a picture of where things are falling over, or where
 things are working.

 We're also looking for people that will help create draft modifications
 to documentation regarding CVS.  I can be a source of info for how
 things work in dist-git and I need volunteers to get the info from me
 and translate it into draft wiki pages.

 Another recently done target in fedpkg is the import command, which
 can be used to import contents from an srpm.  I have tested it somewhat,
 but I'd like more people who regularly use cvs-import.sh to try it as well.

 So grab fedora-packager-0.4.2.3 (may have to enable updates-testing)
 
 For the moment, Yum on Fedora 13 says:
 
 Error: Package: fedora-packager-0.4.2.3-1.fc13.noarch (updates-testing)
Requires: GitPython = 0.2.0
Installed: GitPython-0.1.6-2.fc13.noarch 
 (@anaconda-InstallationRepo-201005130101.x86_64)
 

Oops, I'll push that into updates-testing.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkw8jnYACgkQ4v2HLvE71NVh+QCcDr4g1eTUQGwcAkqfUOWgwAl3
cU0An2GWysdK9dBL/HbKGwWBId4H6ogu
=JEjS
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

dist-git testers wanted!

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

We're ready for the next phase of dist-git migration testing.  Building!
 We now have a staging koji server that has been modified to accept
builds from our test dist-git server.  I've also updated fedpkg (in the
fedora-packager package) to build against this koji instance.  What I
would like is for people to do some trials, duplicate what they are
doing in dist-cvs over on dist-get with fedpkg and try to build things
so that we can get a picture of where things are falling over, or where
things are working.

We're also looking for people that will help create draft modifications
to documentation regarding CVS.  I can be a source of info for how
things work in dist-git and I need volunteers to get the info from me
and translate it into draft wiki pages.

Another recently done target in fedpkg is the import command, which
can be used to import contents from an srpm.  I have tested it somewhat,
but I'd like more people who regularly use cvs-import.sh to try it as well.

So grab fedora-packager-0.4.2.3 (may have to enable updates-testing) and
start playing with making changes, diffing, committing, building, the
types of things you normally do in CVS.  We still have a chance at
making the cut over at or before we branch, I'd really like to go into
F14 branched phase with dist-get conversion behind us.

Thanks in advance! (and find me on IRC or file tickets against
fedora-packager in fedora hosted if you run into issues)

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkw7pS4ACgkQ4v2HLvE71NXNuACgiL2kOs4bhc2IXbjaLiSSJ+6a
qWMAoKHhXci3JQvAl1vtBxqj9sIOC+vs
=8BtA
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 test release blocker bugs

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/6/10 5:22 PM, Adam Williamson wrote:
 On Tue, 2010-07-06 at 17:10 -0700, John Poelstra wrote:
 Hard to believe, but Fedora QA starts its Pre-Alpha Rawhide Acceptance 
 Test Plan testing this Thursday (2010-07-08).

 We've run out of time and run way to implement a new means of tracking 
 blocker bugs for Fedora--previously discussed in the context of using 
 flags in Bugzilla.  We'll continue to use the same process we've used 
 for past releases.
 
 Erm, really? We could throw the existing proposal in in an afternoon if
 we wanted to. I was fine with it. Jesse, what was your plan here?

My plan was to plant the seed of the idea, and let somebody else take
over (delegation and all).  I don't have the bandwidth to work on it
while I try to get dist-git in place.  I had asked Dennis Gilmore to
take it up, and he started doing some investigation, and then he got
busy with other things.  So now it's on John's plate.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkw02EcACgkQ4v2HLvE71NVZxACglStXEtMQX5U+2RCZx7V1xXrM
iToAoLrsXXxOtWhKTRHXAvBN/57N8+Ex
=NYr2
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 test release blocker bugs

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/7/10 5:43 AM, James Laska wrote:
 If there is a solution that addresses the problems identified during
 F-13, and it can be implemented in *short* time.  It would be
 compelling.  I'm a fan of solving problems with tooling, but I'm not
 convinced that is where our big investment should be for the upcoming
 release, or that it fully addresses the problems encountered during
 F-13.

I can think of one quick and simple way of doing this.

When we review a bug and accept it on the blocker list, we use a keyword
of ACCEPTED or some such.  That way any bug without the word is
assumed to just be proposed and not yet accepted.  A bit more manual
work and a bit harder to query, but it still nets the result of
differentiating between bugs that are proposed and bugs that are
accepted blockers.

Thoughts?

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkw03RsACgkQ4v2HLvE71NVWKwCfWjUTB7DAFNAAwbbPzOrho13y
iFYAnR+BdzdmoYpmzD1/1BMzz/7W7HSH
=Ddz/
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 test release blocker bugs

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/7/10 1:01 PM, Jesse Keating wrote:
 I can think of one quick and simple way of doing this.
 
 When we review a bug and accept it on the blocker list, we use a keyword
 of ACCEPTED or some such.  That way any bug without the word is
 assumed to just be proposed and not yet accepted.  A bit more manual
 work and a bit harder to query, but it still nets the result of
 differentiating between bugs that are proposed and bugs that are
 accepted blockers.
 
 Thoughts?

And I see that this was one of the suggestions, which I didn't read
before firing off this email.  Sorry.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkw03ZcACgkQ4v2HLvE71NUnmACfZfHcc435nKibFsni7foi5IwO
PlkAn3pk28KEpca/WZnQ4HGCaqhHAjRN
=sIAu
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 test release blocker bugs

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/7/10 1:08 PM, Adam Williamson wrote:
 keywords we have to ask to be added to the system, I'm not keen on doing
 that as a temp hack. Whiteboard space is freeform, though. We could just
 pick a word to use in the whiteboard space - AcceptedBlocker, for e.g. -
 and go with that.

Yeah, that's fine by me.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkw0388ACgkQ4v2HLvE71NUK7gCgoe/dUREqwurGHRbDm8DBKq9G
FG0An3u7LrZMAN7ZjCtDtbaRzdiIkAJ5
=c2ch
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: concept of package ownership

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/6/10 2:16 AM, Patrice Dumas wrote:
 Maybe Fedora should do a transition to a more open system, since the dedicated
 packager is less present nowadays. But it should be done carefully, in order
 not to piss off the remaining dedicated packagers, who are those who deliver, 
 in my opinion, the packages with highest quality.

The system is fairly open with regard to just about everything except
attitude.  Currently it's mostly attitude that prevents openness.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwzW1IACgkQ4v2HLvE71NUGigCgkVZUzkxqfhhcS95PbwEpjLxz
9noAn2c7LTeD2CWs6QNhxezm+rXaC07L
=RNzg
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: depcheck test (was Re: measuring success)

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/6/10 8:52 AM, Till Maas wrote:
 On Tue, Jul 06, 2010 at 11:34:25AM -0400, Will Woods wrote:
 
 Once we're satisfied that depcheck does the right thing, we will
 probably set it up to start adding automatic +1 karma from 'autoqa' when
 updates pass the automated test suite (depcheck and possibly other tests
 - rpmlint, rpmguard, etc.). We haven't yet decided if the autokarma will
 apply to all packages or just critpath packages; it may apply
 everywhere, which will make it a bit easier to get to +3 karma for
 automated updates.
 
 IMHO it should not be a +1 karma but some different flag that is set for
 updates that passed the tests.
 

Using karma is viewed as the path of least resistance to getting support
in current bodhi for this.  For future bodhi yes, it makes some sense to
use some different flagging mechanism.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwzXGEACgkQ4v2HLvE71NWG/gCfWBn186RjSugsdftn3fgscVfk
2HgAn0D4gbh7ukm1nLN8lkMXZTffkrIG
=66bz
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: depcheck test (was Re: measuring success)

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/06/2010 10:21 AM, Till Maas wrote:
 Essentially using a different flag is just re-using the code used to
 flag a package as critpath-approved only with a different name.
 Therefore it should not need that much more effort.

critpath approved is based on karma as well, so I'm not sure what you're
suggesting here.

 
 Btw. using the path of least resistance to implement policy
 changes seems to be what makes the new workflows suck for package
 maintainers, e.g. with the change in place using a auto-karma value of 1
 will become 0.

You're welcome to contribute some design/code to make this happen, but
we felt that it was best to get something in place to prevent the broken
deps then to wait for major changes in bodhi code base.


- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkwzdP0ACgkQ4v2HLvE71NUajgCgmFKsIeCiL+g9fRT/1TxzQNG7
S1cAoKdjF7aA0YyMnx7IIMmRlpRk3xQH
=dPfd
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: who is Petr Pisar from redhat ?

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/2/10 9:18 AM, Ralf Corsepius wrote:
 I had to apply and justify the reasons why I wanted to be a
  provenpackager.
 I know you did, but the Petr's did not. Their presumable supervisor @RH 
 (Marcella) rushed them through the process and they had been granted 
 access to several 100 package.

The Petrs were not applying for provenpackager.  They had what was
assumed to be a sig's blessing to be granted write access to a set of
packages.  Not the entire world.  We at that point had no policy that
would stop this, regardless of who requested and who was the people
being added.  Being @RH had absolutely no play in this.

 
  I really don't think there is any kind on conspiracy doing on, honestly.
 I am not talking about conspiracy, I am talking about double standards.
 
 What would do if John Doe would apply for proven packager and write 
 access to 1500 packages?
 
 Seriously, you'd likely tell him he's nuts.

Bad analogy.  There was no provenpackager access granted.  Toshio didn't
blindly accept the request, he called out to what he thought was the
correct governing body over those packages and did not receive any
negative feedback, after a week.


- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwuFzkACgkQ4v2HLvE71NV9twCgxmDU7xDtsjDfUxCWuvPJ51Rd
q3UAnjPrmeyTbHpNxxP51u6bbUAyzT7U
=edXM
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Bodhi 0.7.5 release

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/2/10 11:27 AM, Till Maas wrote:
 On Wed, Jun 30, 2010 at 02:48:26PM -0400, Luke Macken wrote:
 
 For critical path updates to be approved for pushing to the stable
 repository, they now require a minimum karma of 2, consisting of a +1
 from a single proventester, and a +1 from another authenticated user.
 
 I am just wondering, is this some intermediate step until the Package
 update acceptance criteria[0] are implemented? Because these criteria
 only say that updates require positive Bodhi karma from a defined group
 of testers, so there is no need for the +1 from another authenticated
 user. Also they are about the important packages, which is a subset of
 critical path. And the policy says that it is not yet live.
 
 Regards
 Till
 
 [0] https://fedoraproject.org/wiki/Package_update_acceptance_criteria
 
I believe it's a continuation of the criteria we used for F13 branched,
which came from the No Frozen Rawhide proposals.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwuM+EACgkQ4v2HLvE71NVp/ACeJhYvjxvhmhglJR1O+4V+xVO+
4hgAoI3YXJyFlkPv5j3rP4qBlAy159Y7
=wimC
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Bodhi 0.7.5 release

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/1/10 2:48 AM, Till Maas wrote:
 How do you know who is a minority and who is not? I still wonder why
 there are so many claims that the majority of Fedora maintainers or
 users want to manually test all updates, but still the majority is not
 involved in testing the updates. When the discussion started, it was
 claimed that submitting karma was too complicated and took too much
 time. This is not the case for several months, but still there are
 updates that do not receive any karma for more than a month. The last
 Bodhi statistics showed 595 unique karma submitters for F13 and there
 seem to be 1035 approved packagers currently in Fedora. So if only
 packagers submitted karma, it would be the majority. But since there are
 a lotsmore users and also dedicated testers for Fedora, it does not look
 like a majority anymore.
 

Simply, if it's not mandatory, it's too easy to be lazy and not do it.
But when it is mandatory, more people participate.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwtBRMACgkQ4v2HLvE71NWXDQCgxUX/5EQwNK4TVASuAqK39ORI
VKEAnjaND4F98KB0XtEjDeY+wOCdOP+q
=RMEJ
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Bodhi 0.7.5 release

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/1/10 2:55 PM, Till Maas wrote:
 But I guess somehow it boils down to
 the majority wants that other people to work for them, which might
 even be true. But in a FOSS community I doubt it is very healthy to
 follow this too much.
 

I bet if we stopped making package reviews mandatory, none would get
done.  This follows the same.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwtEyAACgkQ4v2HLvE71NXm3gCaA5I3IvWDhjkKEzaZFZXgjVRg
sEYAoMRRWlHg9IXSHr3WuvvN/fTWZFe7
=Skyz
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: concept of package ownership

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/1/10 6:18 PM, Kevin Kofler wrote:
 I think we need to get rid of the concept of ownership entirely, that'd also 
 make orphaned or de-facto orphaned packages less of a problem. You see a 
 problem, you fix it. Who cares whether the package has an active maintainer 
 or not?

While I agree that package ownership should not feel possessive, I do
strongly feel that there still should be some single person (or team I
suppose...) who is ultimately responsible for the package.  A place for
bug reports, for autoqa activity, for reviewing potential patches and
changes from other people, etc...

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwtaF8ACgkQ4v2HLvE71NXCCwCgxoNtzgQ/DDpx78uI4jjodHSu
GTYAnAxN9OwDW/qnXMDnZKfp4zCNG8NO
=F1ef
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Bodhi 0.7.5 release

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/30/10 9:31 AM, Ralf Corsepius wrote:
 On 06/30/2010 06:18 PM, Adam Williamson wrote:
 On Wed, 2010-06-30 at 11:35 -0400, Tom Lane wrote:
 
 The proposed policy might be workable if we had a surplus of
 proventester manpower available, but we obviously have not got that.
 And you think re-allocating the already scarce manpower to this process 
 will help?
 I am having very strong doubts on this.
 
 
One of the big reasons the manpower was scarce is we did not have a
proper system to locate, train, and promote new people into this
manpower.  The QA team has made great strides into fixing that and we
do now have a process in place, and a good stream of incoming people
willing to donate some time and effort to help the project.  We are not
just hoping that people will show up and test, we're actively building
a community of people who will be dedicated to testing these things.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwrcjIACgkQ4v2HLvE71NVvUQCfbNY/aL9u3OVG+hV32Cki4R/7
2QQAoMHiq6MwEV2p2HMRsZC9Fjs30Beo
=r6aw
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Bodhi 0.7.5 release

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/30/10 10:48 AM, Ralf Corsepius wrote:
 My perception is: marketing has directed into a direction which drains
 away man-power into an uncertain process whose only immediate effect is
 bureaucracy, whose long term outcome is uncertain and who foundations
 are very questionable, to say the least.

Well yes, you always can be relied upon for the cheery optimistic outlook :)

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwrhcsACgkQ4v2HLvE71NW9VgCePi19pnrMGuRmkcD973VzaAre
LT4AoIF2N0vPJ/TR0BWHFdyfHdAaNQjs
=1R+D
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Bodhi 0.7.5 release

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/30/10 11:09 AM, Ralf Corsepius wrote:
 On 06/30/2010 07:58 PM, Jesse Keating wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 6/30/10 10:48 AM, Ralf Corsepius wrote:
 My perception is: marketing has directed into a direction which drains
 away man-power into an uncertain process whose only immediate effect is
 bureaucracy, whose long term outcome is uncertain and who foundations
 are very questionable, to say the least.

 Well yes, you always can be relied upon for the cheery optimistic
 outlook :)
 
 If I were perceiving competence in Fedora's leadership, my comments
 would sound differently.

You're welcome to try your hand at leadership, or find a project with
different leadership.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwrjCwACgkQ4v2HLvE71NXV4QCeOBlTKRXmHNS9xShqcox1rxt1
vJQAoK+gR7rANslclt2mhG1eNoX07EKR
=FgEj
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Bodhi 0.7.5 release

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/30/10 12:29 PM, Tom Lane wrote:
 Will Woods wwo...@redhat.com writes:
 On Wed, 2010-06-30 at 15:04 -0400, Tom Lane wrote:
 Yes I can.  I have two critpath packages that are in testing with
 security bugs, both pretty small and easy to test, and both still have
 karma zero.  That seems to me to be adequate proof that there's not the
 manpower out there to do this.
 
 Have you actually asked anyone to test it? Or even considered
 *mentioning the names of the packages* so maybe someone here could help?
 
 I mentioned libtiff in my first comment in this thread.  The other one
 is libpng.  But in any case, are maintainers supposed to have to scare
 up testers on their own?  Especially for packages that are supposed to
 be so central as to be critpath?  If there aren't testers coming out of
 the woodwork, this scheme is doomed to failure.
 
   regards, tom lane


It worked just fine when F13 branched before F13 released.  We're
putting even more resources into it now, ergo it should work just as fine.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwrqMEACgkQ4v2HLvE71NUDxgCgpPyHdKSQi0XVng1fc3HGCEzg
gqEAniEOlhRJrctTk4iKOqrfCz21y4bC
=GLK5
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Bodhi 0.7.5 release

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/30/10 3:38 PM, Tom Lane wrote:
 Jesse Keating jkeat...@j2solutions.net writes:
 On 6/30/10 12:29 PM, Tom Lane wrote:
 I mentioned libtiff in my first comment in this thread.  The other one
 is libpng.  But in any case, are maintainers supposed to have to scare
 up testers on their own?  Especially for packages that are supposed to
 be so central as to be critpath?  If there aren't testers coming out of
 the woodwork, this scheme is doomed to failure.
 
 It worked just fine when F13 branched before F13 released.  We're
 putting even more resources into it now, ergo it should work just as fine.
 
 I see that libtiff.fc13 and libpng.fc13 are now showing critical path
 approved, for which I thank those who did the work.  I remain a bit
 unclear about a couple of things:
 
 1. Bodhi is showing both packages as requested push-to-stable.  Which
 *I* certainly didn't do, and considering they are only at +2 karma,
 this means that the threshold for auto-push is actually lower than it
 was before, not higher.  WTF?  Is the idea here to remove every last
 vestige of the maintainer's judgment from the process?

That is not the idea or intent.  However since we value proventester
karma above all others, it was deemed only necessary to have one
confirming karma beyond the proventester karma.  This is how things
worked throughout the F13 branched phase.  There is a slight wrinkle in
that right now, the bodhi code will automatically request a push of an
item that reaches this karma threshold, and I don't believe there is a
way yet to force it to wait for even greater amounts of karma.  I
believe that fine grained tuning of karma automation is planned for the
next major version (and rewrite) of bodhi.


 2. libtiff.fc12 and libpng.fc12 are still lonely with zero karma.  Is the
 restrictive policy in force for F-12 too?  I'm even less willing to
 believe that we have enough testing manpower to cover both back branches
 right away.
 

I believe only F-13 requires proventester karma at this time.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwryHcACgkQ4v2HLvE71NWduQCgioaA2nrN89eelsinYa0OXLF0
8iYAn0Gt2dc/gwhrzuUtH190GR/dWRmA
=qyet
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Evolution update in F13

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/29/10 3:44 AM, Michael Schwendt wrote:
 On Mon, 28 Jun 2010 23:03:23 -0600, Kevin wrote:
 
 It's only in updates-testing yet. 
 
 Gah! :-/
 
 I wonder whether after years the Fedora N updates-testing report could
 finally be sent to users' list instead of test list? Who can make that
 happen?

The bodhi developer could, through a ticket.  However a change like that
impacts a lot of people, it should be well thought out.  A fesco ticket
perhaps?

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwqJQkACgkQ4v2HLvE71NVF5ACbBSrI99sF61FxdkkRwRVRciCh
BQYAoLA7mKIoAdGlbLgd/tPo1bDOT5Xd
=a5uF
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Feature 14 - official Fedora re-spins

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/27/10 2:12 PM, Micha? Piotrowski wrote:
 Hi,
 
 I wonder if it would be a big problem to create regular (for example,
 every three months) re-spins of main installation images - cd's and
 dvd's for i386 and x86_64 (not livecd's).
 
 Fedoraunity http://fedoraunity.org/re-spins creates such images, but
 it's not regular.
 
 Regards,
 Michal

Re-spins take time and energy.  Part of the reason the Unity project
doesn't do them regularly is because changes in the distribution
packages happen during a release and cause things to no longer work as
designed within the installer.  Anaconda has over the years made use of
more and more existing utilities to get it's job done instead of
maintaining their own versions of things.  While this is good for code
sharing, it means changes in these utilities can break anaconda.
Discovering these changes and preparing / backporting code to take them
into account takes time and energy, time and energy that would have been
spent on making the next release better.  Our releases come fast enough
for our development team, one might say too fast.  If we were to insert
re-spins every 3 months we would be doing a rather insane amount of
release wrangling between the re-spins for each active release and the
ongoing work to prepare the release in development.  Put simply, we
don't have the resources to take this on as an official offering,
requiring devel, releng, QA, marketing, et al resources.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwovu0ACgkQ4v2HLvE71NVPKwCfbHsGJzPgdbhmk39peIzc+t6u
eZoAnRd6PhoZlEL3Q8A7ZRRFTfxu5eoz
=NeLU
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Evolution update in F13

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/25/10 10:50 PM, Adam Williamson wrote:
 Until AutoQA is in place to tackle this, the obvious option is for there
 to be a process improvement whereby whoever's doing stable update pushes
 at least gets notified if a package has received negative karma since
 the submission. I think we discussed something similar on -devel last
 time this happened. Not sure if there's a ticket, or how hard that would
 be to implement.

Likely the easiest thing to do is on the client side we use, filter any
update requests that have too negative of karma.  It would have caught
this issue. They can be displayed for a releng person to further
investigate.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwlnOUACgkQ4v2HLvE71NUVrwCfUw3Ji+33uZk2QwvsfZO1JGeM
jH0An13glytiG7P9a2n7POsdzCqX5MUz
=XHtq
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Evolution update in F13

[Jesse Keating]

On 06/26/2010 05:10 AM, Peter Robinson wrote:
 That would only work if the script that does the push to stable (as
 opposed to processing the request to push to stable) checks if any
 negative karma has appeared since the request has happened.

Well, if there is a update push to stable request that has any amount of 
net negative karma, it needs to be looked at and a human should 
intercept it.


 I believe that a deps autoqa is still a good idea for stable releases.

Correct, this is not a replacement for that, just something we can do 
today while AutoQA work continues.


-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide report: 20100622 changes

[Jesse Keating]

On Wed, 2010-06-23 at 08:16 +0200, Ralf Corsepius wrote:
 
 Yep ... In an ideal world, you would not have pushed packages to rawhide 
 with a smaller NVR than that already in rawhide and no packages with a 
 smaller NVR than that in older releases.
 
 Both cases seem to have happened. 

The script I wrote to avoid these situations must have malfunctioned.  I
did spot check 10 or so of the builds and they all looked fine, it is
unfortunate that in the hundreds of builds I couldn't spot any of the
issues.  I'll be reviewing the script.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Fedora-haskell-list] rawhide report: 20100622 changes

[Jesse Keating]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/23/10 4:39 PM, Jens Petersen wrote:
 - Bruno Wolff III br...@wolff.to wrote:
   Jens Petersen peter...@redhat.com wrote:
 This is now done - so all rebuilds need to be done in the
 dist-f14-ghc buildroot.

 Today's rawhide still seems broken. The report indicates that ghc has
 been removed from rawhide:
 http://lists.fedoraproject.org/pipermail/test/2010-June/091630.html
 Removed package ghc
 
 Hmm, I see ghc-6.12.2-1.fc14 in dist-rawhide.
 
 Any comment from releng?
 
 Jens

As discussed on IRC, this seems like an odd anomoly that happened
perhaps due to moving the latest ghc from one tag to the other.  Really
not sure why at the time of compose koji decided there were no builds of
ghc, however I have replaced the ghc build that went out the last couple
days (even though it is broken).  There is a FESCo ticket being opened
that would grant me the approval to make ghc go backwards to a build
that works while the rebuild is managed in dist-f14-ghc.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwipagACgkQ4v2HLvE71NU7kACeKv07h50Jxql6RHujbVrjZ5Cx
zwYAoI23tEzouQ/kC8z4XXtC//A9x1xH
=oE7q
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide report: 20100622 changes

[Jesse Keating]

On Wed, 2010-06-23 at 02:25 +0900, Mamoru Tasaka wrote:
 Can we query what packages were downgraded due to this mass
 perl-5.12.0-rebuild
 retag? 

Hrm, that's going to be tough.  There were also at least one case of an
F13 update being built that was a newer version ( not just release )
than the rawhide perl rebuild.  I'm afraid somebody might have to go
through package by package and make sure the latest build looks right,
or construct some script that dumps the list of builds in dist-f14 for
each and make sure the latest is n-v-r higher than any previous.  It's
fairly straight forward coding, i just don't have the time for it at the
moment.  Any takers?

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Problem with createrepo for modified DVD ISO

[Jesse Keating]

On Sat, 2010-06-19 at 17:07 -0400, Digimer wrote:
 On 10-06-19 08:51 AM, mike cloaked wrote:
  On Sat, Jun 19, 2010 at 5:37 AM, Bruno Wolff IIIbr...@wolff.to  wrote:
  On Fri, Jun 18, 2010 at 09:15:09 -0400,
Digimerli...@alteeve.com  wrote:
  Hi all,
 
  I asked this on buildsys, so this is something of a repost. I'm not
  sure where to turn at this point, so if this isn't the right list, would
  anyone be able to point me in the right direction?
 
  Probably the question belongs on users.
 
  I've been trying to create my own (minorly) custom distro for Fedora
  13. All it really is is a custom kickstart and a changed up set of RPMs.
 
  I think revisor is the tool that is best for making custom install DVDs.
  I usually make live images using livecd-creator and can't give you specific
  information on using revisor.
 
 
  Surely mock/pungi is the best tool chain for creating install isos?
 
 Perhaps they are, and I will look into them. However, my curiosity has 
 been piqued, so I'd still like to know how it's supposed to be done. It 
 seems to me like it should be a somewhat straight forward task, so I am 
 curious about where my understanding has failed.
 

Creating the right metadata involves using the --baseurl directive, and
something along the lines of --baseurl media://mediaid  That's what
will make the repodata have the right urls listed.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: dist-git project update

[Jesse Keating]

On Sat, 2010-06-19 at 01:08 +0200, Kevin Kofler wrote:
 Jaroslav Reznik wrote:
  Fedpkg should hide the GIT details from you.
 
 But it's a command-line tool. Cervisia (what I use on the CVS repos) is a 
 GUI.
 
 Kevin Kofler
 

fedpkg is also a library, where all the interesting things are done in
the library, so that somebody could write a gui (or even web) frontend
for it.  I'm making a strong effort to keep the separation between
library and frontend as clean as possible.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: dist-git project update

[Jesse Keating]

On Sat, 2010-06-12 at 21:39 +0200, Jochen Schmitt wrote:
 It's seems, that this feature is not implemented in the current
 fedora-packager package.
 
 when I try to make a fedpkg cloone --branches I will get only
 a message which describe the function for this command without
 any visible result. 

Oops, looks like that's another to be done later items (:

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: dist-git project update

[Jesse Keating]

On Mon, 2010-06-14 at 13:01 +0530, Rahul Sundaram wrote:
 
 Is the effort to make it easy to build RPM's directly from git tags
 related to this or is that a separate project? 

That's a different project, and even then we will likely need to
construct a source tarball at some point in the process (behind the
scenes) or make even more significant changes to Koji.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: dist-git project update

[Jesse Keating]

On Sat, 2010-06-12 at 08:22 +0200, Iain Arnell wrote:
 On Fri, Jun 11, 2010 at 11:57 PM, Jesse Keating jkeat...@redhat.com wrote:
  The current url is
  pkgs.stg.fedoraproject.org/package  and that works with git:// and
  ssh://.
 
 Any chance of making that work with http:// and https:// (for pushes) too?
 

I hadn't planned on it.  Is there really a need for this?  Read only via
http is do-able, but undesirable.  Write via https is going to be a long
shot.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: dist-git project update

[Jesse Keating]

On Sun, 2010-06-13 at 17:26 +0100, Christopher Brown wrote:
 Hi Jesse,
 
 On 11 June 2010 22:57, Jesse Keating jkeat...@redhat.com wrote:
  On Fri, 2010-06-11 at 17:21 -0400, Simo Sorce wrote:
 
  Is it necessary to do fedpkg clone ?
  Or can regular git be used ?
 
 
  Not necessary at all.  The current url is
  pkgs.stg.fedoraproject.org/package  and that works with git:// and
  ssh://.  One advantage to using fedpkg clone is that if you like the
  current directory layout where each release is a subdir, you can do
  'fedpkg clone --branches' and you'll get that layout.  You can also do
  fedpkg clone -b branch and get a checkout of the specific branch
  listed.  By no means is fedpkg required for the clones and commits, but
  it is a convenience that some will like to use, and will likely be the
  documented way of doing things.
 
 I'm really keen to see this come off as I think pretty much everyone
 is and look forward to the day when we all bid cvs goodbye. Would it
 not be saner to extend git through a plugin to provide fedora-specific
 stuff rather than use a new, separate command like fedpkg? Might help
 the migration if people understand that they are essentially using git
 with a few fedora options instead.
 

fedpkg is more than just an interaction with the source control, it's
also how you interact with the koji build system and with bodhi, and
potentially with other things in the future.  Bundling those all into
git doesn't necessarily make sense.  For those used to git and prefer to
use git directly to manipulate the sources, they can do that just fine.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: dist-git project update

[Jesse Keating]

On Fri, 2010-06-11 at 12:46 -0700, Ryan Rix wrote:
 How will this affect current packagers' workflow? Will the changes necessary 
 be documented on the wiki? It doesn't seem straight off the bat that this 
 would be a drop-in replacement without packagers needing to tweak their 
 workflow.
 

Packager workflow will indeed be affected.  First and foremost they will
need to make use of 'fedpkg'.  Fedpkg is replacing the Make system, and
adding a few things on top of it.  Today to check out a package and
build it for rawhide you'd essentially do:

cvs junk here checkout module

cd module/devel/

edit junk

cvs add/commit

make tag

make build

With dist-git it's slightly different:

fedpkg clone module

cd module

edit junk

fedpkg commit  (this target is missing right now, alternatively git
commit)

fedpkg build


We've kept the target names the same, so make foo largely becomes
fedpkg foo.  But since fedpkg can take options for the targets much
easier than make can, some targets grew options, like fedpkg build
--scratch  which essentially does fedpkg scratch-build.  Also, where
with the Make system we'd have to pass arguments as env variables (make
new-sources FILES=blah..) we can do it as arguments: fedpkg new-sources
file1 file2 file3.

We also are able to put in a better help system, so that fedpkg --help
and fedpkg target --help provide better help to end users trying to
get things done.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: dist-git project update

[Jesse Keating]

On Fri, 2010-06-11 at 17:21 -0400, Simo Sorce wrote:
 
 Is it necessary to do fedpkg clone ?
 Or can regular git be used ?
 
 
Not necessary at all.  The current url is
pkgs.stg.fedoraproject.org/package  and that works with git:// and
ssh://.  One advantage to using fedpkg clone is that if you like the
current directory layout where each release is a subdir, you can do
'fedpkg clone --branches' and you'll get that layout.  You can also do
fedpkg clone -b branch and get a checkout of the specific branch
listed.  By no means is fedpkg required for the clones and commits, but
it is a convenience that some will like to use, and will likely be the
documented way of doing things.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

dist-git project update

[Jesse Keating]

It's been a while since I last updated folks on dist-git, and in reality
it's been a while since I last worked on it.  Fedora 13 took up all my
time.

Since my last update we've made great progress on fedpkg, the new tool
that will replace the make system.  It is packaged up with
fedora-packager and has the ability to do many tasks that our Make
system handled.  Here is a quick list:

build
chainbuild
clean
clog
clone
compile
gimmespec
install
lint
local
mockbuild
new
new_sources
prep
scratchbuild
sources
srpm
unusedpatches
verrel

Many of these targets take optional arguments which extend their
functionality and replace some other specific Make targets.  This list
is enough to get us checking code out and in, and building in koji.

On the koji front we've recently discovered the changes necessary to
build from dist-git style repos, and those changes are being polished up
and committed upstream.  We have done multiple builds successfully from
dist-git repos.

Where do we go from here?

We're ready for more wide scale testing, and to facilitate that I am
refreshing the git repos from current CVS (people with existing clones
will have to blow them away and re-clone), and getting a koji stage
instance up that we can build against (with limited builders).  We'll
then push out another fedora-packager update that has the right URLs to
build against this stage Koji and announce that it is ready for
building.

Based on this testing, and some decisions around git tagging and branch
usage, we stand a good chance at being able to roll this out prior to
the F14 branch event.  I hope you are all as excited as I am about this!

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: sources file audit - 2010-05-31

[Jesse Keating]

On Thu, 2010-06-03 at 15:02 -0600, Kevin Fenzi wrote:
 jkeating:BADSOURCE:koji-1.3.2.tar.bz2:koji
 jkeating:BADURL:mock-1.1.1.tar.gz:mock
 jkeating:BADURL:pungi-2.1.0.tar.bz2:pungi 

We don't really do tarball drops of these anymore, we just make release
from git.  What should we put in the spec file to reflect this?

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Package maintainers -- want test results by mail?

[Jesse Keating]

On Wed, 2010-06-02 at 19:41 +0200, Till Maas wrote:
 And I doubt that python scripts in below
 /usr/lib/python2.6/site-packages usually need to be executable. Since
 yum works without any problems, these tons of errors are useless, too.
 And they make it only harder to find real errors. I did not think more
 about the other quoted rpmlint messages.
 
 

It's complaining because the files have #! in them, likely to assist in
self tests, but the files aren't marked as executable.  That could
actually be fixed upstream, either mark them as executable or remove the
#!s.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Package maintainers -- want test results by mail?

[Jesse Keating]

On Wed, 2010-06-02 at 19:59 +0200, Till Maas wrote:
 On Wed, Jun 02, 2010 at 10:46:51AM -0700, Jesse Keating wrote:
  On Wed, 2010-06-02 at 19:41 +0200, Till Maas wrote:
   And I doubt that python scripts in below
   /usr/lib/python2.6/site-packages usually need to be executable. Since
   yum works without any problems, these tons of errors are useless, too.
   And they make it only harder to find real errors. I did not think more
   about the other quoted rpmlint messages.
   
   
  
  It's complaining because the files have #! in them, likely to assist in
  self tests, but the files aren't marked as executable.  That could
  actually be fixed upstream, either mark them as executable or remove the
  #!s.
 
 I understand the rpmlint test, but I do not understand why this needs to
 be handled upstream or why this is any problem at all. Are there
 packages with executable files in the python-sitelib that need to be
 executable or are used by users of the installed package as executables?
 

*shrug*  I suppose it's worth checking with upstream over it.  And
discussing whether that rpmlint rule should be removed in our build.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: suggestion: rescue boot extension

[Jesse Keating]

On Wed, 2010-06-02 at 15:39 -0500, Eric Sandeen wrote:
 The ability to create/update a rescue image would be very useful IMHO.


If it was a ramfs that was writable, and you had say yum/rpm in there,
you could update the running code and make use of a newer e2fsck...

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd (Was Re: tmpfs for strategic directories)

[Jesse Keating]

On Wed, 2010-05-26 at 14:08 -0400, Jon Masters wrote:
 On Wed, 2010-05-26 at 08:54 -0400, Seth Vidal wrote:
  
  On Wed, 26 May 2010, Simo Sorce wrote:
  
   While you don't edit them *all* the time, it is something that is done
   regularly, and it is something most admins can do with ease.
   Turn them in a C program and you left admins out in the cold, most of
   them.
  
   I would be very, very wary of accepting a C init script.
   An unmanageable system is a useless system.
  
  +20 million.
  
  I couldn't agree more. They need to be scripts, considering how seldom 
  they actually run it makes even less sense to chase down optimization in 
  them by making them compiled.
 
 I *very* strongly agree also. I do change init scripts, but even more
 than this, I see a growing trend for Linux systems to be less friendly
 to user modification. We are not so smart that we should do this.
 
 Jon.
 
 

So everybody seems to keep assuming that if more of the start up is done
in the daemon itself that you'll lose the ability to configure it.  I
don't think that's the desired case, just that configuration will move
to the configuration files, and not in the startup script.  Separation
of config from code seems smart to me, particularly come rpm update
time.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd (Was Re: tmpfs for strategic directories)

[Jesse Keating]

On Wed, 2010-05-26 at 23:39 +0200, Kevin Kofler wrote:
 seth vidal wrote:
  It appears this subject has been picked up on lwn - so I'm certain there
  will be a fruitful, productive and constructive discussion there.
 
 Hahaha! You gotta be kidding! LWN keeps posting flamewars as news and 
 their comments are infested by trolls like no other place!
 
 Kevin Kofler
 

May I introduce you to sarcasm?

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: base kernel to build fedora

[Jesse Keating]

On Sun, 2010-05-23 at 17:21 -0400, Genes MailLists wrote:
 On 05/23/2010 02:25 PM, Mike McGrath wrote:
 
  
  I don't think anyone thinks rebuilding the builders every 6 months (and
  fixing all the bugs that comes with that) is a good use of their time.
  
  -Mike
 
  But a release really  should be boot strapped with itself once when it
 gets stable enough .. or at least built with Fedora N-1 as someone else
 suggested.
 
  I sort of recall someone mumbling about using a VM but I don't know
 what would be involved in keeping the vm updated to Fedora N-1 ?

It is built with itself, all except the running kernel behind the mock
chroot.


-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel