Daily KDE4 Subversion Packages

Last of the Wolves · 2009-08-19 09:21:03

I thought the same in the beginning of building. But I soon realized that I would be too lazy too reboot everytime to build the packages.

deej · 2009-08-19 09:24:06

After doing it a few times, I will probably wish I'd listened to you :lol::lol:

Deej

atomopawn · 2009-08-19 09:35:50

I tried running this in VirtualBox for awhile, but it turned out that the VM made lots of things break (files would randomly disappear sometimes and stuff). Wasn't worth the management risk. Like Stephan, I'm just going to run this on my production system. I always have my Gentoo box for backup if I need it.

markc · 2009-08-19 21:18:53

Four of us so far at http://gitorious.org/+kde-git-pkgbuilders/memberships. Everyone is an administrator so any of us can do anything to the project, like add more users, so you don't wait for me to do anything.

Now, we just need a set of packages pushed into the project repo. My only hesitation is I'm still not sure of the state of the KDE svn -> git move and whether relying on the Git repo is viable yet. My first attempt at building kde-qt failed so I haven't managed to build any KDE related anything from gitorious yet. Anyone have any clues to offer? I did a manual update of my /home/sources/KDE svn tree and it's definitely still being updated. It would be kind of neat to be able to change all the svn references to git @ gitorious and then push up the first set up packages, but not if there is going to be a delay of many weeks. I'm easy, if we are keen to just get the packages into gitorious sooner than later anyone is free to pull from github and go through the motions. Someone will have to rtfm eventually :-)

As for running the packages I really suggest setting up a hard drive with at least 3 x 11Gb + the remainder paritions (+ swap of course) so that you can have a main desktop system and simply chroot into the other 2 (or 1, whatever) to build and test the packages. I use "the remainder" as my /home partition and my mpkg_chroot() script function bind mounts it so it's still available as /home within the chrooted partition. Then when I boot into into that partition, /etc/fstab also mounts it as /home and I generally use the same uid 1000 for the same or different user IDs. Point being is my same fairly large /home/sources and /home/packages trees are available regardless if I chroot or boot into any of my (6) 11Gb system partitions. It's really handy to have a couple of spare partitions to quickly throw any OS on for any reason. I've got xPUD, Tinycore, Kubuntu plus a test 64bit and 32bit Archlinuxs just a chroot or reboot away. As a side benefit, I use mpkg chroot skype rather than install extra 32bit libs, or worry about a multilib system, and it works fine for the few times I need it. Of course setting up these extra partitions is not so easy to do after already formatting a drive so I mention it again here for consideration for the next time anyone sets up a HDD from scratch.

@venky80: are you sure you have some standard system fonts installed, like say ttf-dejavu and/or ttf-ms-fonts ?

@Last of the Wolves: as per the above rave, no need to reboot just to build either 64bit and 32bit (assuming a 64bit CPU/kernel) packages. No doubt the more friendly rewrite of my mpkg script will make this easier. I build the current 32bit packages from a 64bit partition using mpkg chroot "mpkg kde/svn/ upload".

mpkg_chroot()
{
  [ $DBG -gt 1 ] && echo "==> START mpkg_chroot() $1,$2,$3"

  local EXEC="";     [ -n "$1" ] && EXEC=$1
  local USER="$U32"; [ -n "$2" ] && USER=$2
  local ROOT="$X32"; [ -n "$3" ] && ROOT=$3

  test -f $ROOT/etc/makepkg.conf && source $ROOT/etc/makepkg.conf

  sudo mount --bind /dev $ROOT/dev
  sudo mount --bind /sys $ROOT/sys
  sudo mount --bind /proc $ROOT/proc
  sudo mount --bind /home $ROOT/home

  if [ $(uname -m) = "x86_64" -a "$CARCH" = "i686" ]; then
    if [ -n "$EXEC" ]; then
      [ $DBG -gt 0 ] && echo "==> sudo linux32 chroot $ROOT su -c \"$EXEC\" $USER"
      sudo linux32 /usr/sbin/chroot $ROOT su -c "$EXEC" $USER
    else
      [ $DBG -gt 0 ] && echo "==> sudo linux32 chroot $ROOT su -l $USER"
      sudo linux32 /usr/sbin/chroot $ROOT su -l $USER
    fi
  else
    [ $DBG -gt 0 ] && echo "==> sudo chroot $ROOT"
    sudo /usr/sbin/chroot $ROOT
  fi

  sudo umount $ROOT/dev
  sudo umount $ROOT/sys
  sudo umount $ROOT/proc
  sudo umount $ROOT/home

  [ $DBG -gt 0 ] && echo "==> END mpkg_chroot()"
}

atomopawn · 2009-08-19 21:39:48

My understanding is that qt-copy and amarok have moved to git, but everything else will still use svn until at least the 4.4 release. I've never used "git-svn", but my understanding is that it's possible to use git as a frontend to svn. We might be able to make that work.

I use this on my production system (and not in a chroot) for one big reason: it works far better than the official KDE 4.3 packages in extra. I rely very heavily on the kdepim utilities (I also do some development there) and the Akonadi server from the "extra" packages has been so flaky I can't use it. These svn builds have actually been more stable and reliable for me! So -- good work, Mark!

deej · 2009-08-19 21:57:01

From one of the TWO videos I've now watched on git ( get a life !*!* ) I recall that git can
meld in with svn. Don't recall how... that comes in video III :D:D

Before I re-partition, does anyone know how kde-svn works with kde-meta ? I recall
trying to install kde-svn with kde-meta and came up with all sorts of problems.

Deej

markc · 2009-08-19 22:02:50

Okay, it's many months before KDE moves the current svn trunk to git master @ gitorious so we may as well get the current packages into gitorious kind of asap. I need to rtfm so give me 48 hours, or if anyone feels the need then just say so here and go for it. Points to consider...

* should we merge kde/svn and kde/stephan or keep them separate ?
* if we have a single "flat" space then kde/extra should be inside it rather than a separate area
* kde-qt and amarok should be added, the current qt-copy dropped
* I'm not sure how to handle amarok vs the current extragear-multimedia (which also includes amarok, or did)
* we need some kind of script management folder for mpkg-ng so the active build stuff comes with the repo
* I'll manage my eth-os packages @ http://git.eth-os.org, so we really only need a single kde-git-pkgbuilds tree

Re stability, wow, that's good to hear but rather counter-intuitive, especially considering how little attention the kde/svn packages get (and zero testing by me).

Hopefully the new kdebase is okay. It hasn't built since [testing] got pacman 3.3 a week or more ago.

flamelab · 2009-08-19 22:08:12

Oh, where did you read that ? (that KDE moves to git)

markc · 2009-08-19 22:25:03

@deej: I have no clue about kde-meta but with multi system partitions it kind of doesn't matter, you can blend or keep them separate. As for using git-svn, there are 2 distinct parts of what we are doing, using Git to manage the Archlinux source packages and currently pulling KDE source from KDEs subversion repo (although apparently now we can get amarok and kde-qt from git @ gitorious instead of from KDEs "old" subversion repo). The original set of these source packages was under subversion control at Google Code and if they still were then, yes, we could use git-svn to help manage the transition to gitorious. However, the current set of source packages are at github so it's a fairly simple pull and push to a different upstream git repo kind of thing. Now if we were maniacally inclined enough to use git-svn to move all ~10Gb of KDEs current subversion repo to Git control at gitorious, and successfully pull it off, then we'd all get a medals, or end up in the loony bin from trying. Heh. Just for our source packages at (soon) gitorious, we dont' need to worry about using git-svn.

markc · 2009-08-19 22:44:45

@flamelab: the mailing-list archives for [Kde-scm-interest] would have the most detailed info. As far as I can tell it's a done deal except for when. Some launchpad/bzr advocates might not be happy but having Qt already at gitorious kind of (I guess) sealed the deal. The reason for chosing gitorious.org is because, unlike like say github.com, the whole RUby on Rails based hosting system is open source and freely downloadable. I think Nokia was going to use the gitorious code and host it themselves (they started to do so) but did a deal with the gitorious developer(s) to do the hosting instead (good move as then Qt is truly Nokia independent which is important if Nokia want other companies to use and also drive Qt development and adoption).

atomopawn · 2009-08-19 23:04:16

I agree that it would be crazy to try to move all of KDE to gitorious by ourselves (although you're right -- the community would love us). I guess what I'm envisioning is something more like this:

1. We store the PKGBUILDs and associated scripts on gitorious. We might also put a package on AUR that will automatically git clone/git update the PKGBUILD repository.

2. The PKGBUILDs and scripts create an active copy of KDE trunk somewhere on the user's harddrive using git/git-svn. This gives us a common interface for manipulating the source code. Instead of having to do one thing for kde-qt and another thing for kdepimlibs, we can just use git commands for everything.

3. The PKGBuilds interact with the scripts and use this copy of KDE trunk to create binaries.

Is that more or less what you had in mind? Maybe I'm barking up the wrong tree...

markc · 2009-08-20 03:36:28

We might also put a package on AUR that will automatically git clone/git update the PKGBUILD repository.

Excellent idea. That way there is only a single standard Archlinux compliant PKGBUILD in AUR to maintain and it sets up the rest. Indeed, a jolly grand idea.

The PKGBUILDs and scripts create an active copy of KDE trunk somewhere on the user's harddrive using git/git-svn.

Also a very good idea although it involves more work for use to do it this way... but once it's figured out and scripted up it should be painless. It would be a great learning exercise!

Must be a great view from whatever tree it is that you are barking up :-)

venky80 · 2009-08-20 04:22:03

markc wrote:

We might also put a package on AUR that will automatically git clone/git update the PKGBUILD repository.
Excellent idea. That way there is only a single standard Archlinux compliant PKGBUILD in AUR to maintain and it sets up the rest. Indeed, a jolly grand idea.
The PKGBUILDs and scripts create an active copy of KDE trunk somewhere on the user's harddrive using git/git-svn.
Also a very good idea although it involves more work for use to do it this way... but once it's figured out and scripted up it should be painless. It would be a great learning exercise!
Must be a great view from whatever tree it is that you are barking up :-)

i dont understand most of the things discussed here but that was a funny one..;) seems something interesting is cooking!

atomopawn · 2009-08-20 06:05:00

markc wrote:

Re stability, wow, that's good to hear but rather counter-intuitive, especially considering how little attention the kde/svn packages get (and zero testing by me).

You're just that good, I guess. Or maybe it's just plain dumb luck. But I've certainly had fewer problems running these packages.

I think a big part of it is that the akonadi_next stuff is only in KDE trunk right now, not in 4.3. The new entitytreemodel classes and things like that are a lot better designed than the old stuff.

About merging kde-svn and kde-stephan. I'm all for it, but I guess it's really "LastOfTheWolves" who needs to decide what he'd prefer. It's a lot easier to manage one tree than two, but if he wants to go off in his own direction with this and maintain things separately, more power to him.

Last of the Wolves · 2009-08-20 07:33:17

I really like the dynamic coming up now.

Regarding kde-stephan I would prefer something like we do one tree and everyone changing bigger parts can clone the gitorious-repo and work there a little bit until everything works fine and we merge it again. I read an article about github some days ago where the procedure of this is explained and for me it sound the best way.

@markc: amarok isn't in extragear-multimedia anymore so I created it's own package and removed amarok from extragear-multimedia's PKGBUILD.

@all: What do you think about following ArchLinux with splitting up the packages. I think that should be done with changing to git/git-svn for pulling as therefore we have to change every PKGBUILD.

markc · 2009-08-20 08:07:36

I think we can work with branches instead of entire separate trees, like the current kde/svn vs kde/stephan sets of packages. The default master branch should be what I build from and what folks get when they first checkout the whole system (perhaps using the future package from AUR) but any of us can easily create a local branch and make any changes we want (like a "stephan" or "debug" branch) and if it proves useful then merge some worthy changes into the master branch or push that entire local branch to gitorious for others to use. On top of that flexibility, anyone can easily clone or "fork" (in github speak) the whole package set and push them into any other account or upstream host and manage them independently.

Well well, how about that, I went to start pushing my package set up but I can't find any docs about to even start the first stage of a new project. Github has excellent docs but I can't find anything useful on gitorious. I must be going blind! Has anyone noticed a how to get started tutorial on gitorious?

atomopawn · 2009-08-20 08:54:46

There is a section called "How do I point my local Git repository at Gitorious?" at

http://gitorious.org/about/faq

that discusses how to upload a local git repository. It's not much, but it's something. Pity I can't get it to work

deej · 2009-08-20 08:58:23

Try this:

http://git-scm.com/documentation

Deej

[EDIT]

This may be useful as well:

http://rapidshare.com/files/269414278/V … ithGit.pdf

Learn how to use Git in several real-world enviroments.
Gain insight into Gits common-use cases, initial tasks and basic functions.
Understand how to use Git for both centralized and distributed version control.
Use Git to manage patches, diffs, merges and conflicts.
Acquire advanced techniques such as rebasing, hooks and ways to handle submodules ( sub-projects ).
Learn how to use Git with Subversion.

That should help a lot of folk [ me included ! ]

Deej

Last edited by deej (2009-08-20 09:29:40)

atomopawn · 2009-08-20 09:14:33

Okay. So it turns out that if you go to the project page and click "Add repository", it gives you instructions for pushing once you've created an empty repo:

* Clone this repository (Git / HTTP) : git clone git://gitorious.org/kde-git-pkgbuilds/kde-git-pkgbuilds.git git clone http://git.gitorious.org/kde-git-pkgbui … builds.git
* Push url: git@gitorious.org:kde-git-pkgbuilds/kde-git-pkgbuilds.git (?)
You can run git push git@gitorious.org:kde-git-pkgbuilds/kde-git-pkgbuilds.git master
Or you can setup a remote like this:

git remote add origin git@gitorious.org:kde-git-pkgbuilds/kde-git-pkgbuilds.git
# to push the master branch to the origin remote we added above:
git push origin master
# after that you can just do:
git push

Getting started
Configure Git

If you haven't done so already, download and install Git

git config --global user.name "Your full name"
git config --global user.email "robert@narnia.homeunix.com"

Pushing your local repository to Gitorious

git checkout master
git remote add origin git@gitorious.org:kde-git-pkgbuilds/kde-git-pkgbuilds.git
git push origin master

atomopawn · 2009-08-20 09:15:31

Okay. I think I've moved everything that was on github over to a repo named "kde-git-pkgbuilds".

atomopawn · 2009-08-20 09:28:34

A little trick I learned from Kelvie Wong (who works on basKet) is to use git pull --rebase instead of a plain old git pull. It keep the git tree a little cleaner, but it can be confusing to use. We should think about whether we want to do that or not.

deej · 2009-08-21 16:57:56

Following on from my post above, here's another source of information on GIT
which may be useful:

Learn how to use how to use Git to protect all the pieces of your project
Work collaboratively in a distributed environment
Learn how to use Git's cheap branches to streamline your development
Install and administer a Git server to share your repository

http://rapidshare.com/files/269894347/p … er-kit.pdf

Deej

Last of the Wolves · 2009-08-21 17:06:38

Today I started splitting the packages and wanted to try git-svn to pull the sources.

Also I got my server today but I still have some problems with Arch on it but I hope I'll get it working until monday. So then I'll be back with compiling the packages.

Greetings
Stephan

UPDATE:Compiling works. Just got QT through. But till now without using mpkg. And I just finished spliting kdesupport. Maybe someone should check my PKGBUILDs. They are in svn/kdesupport/* now.

Last edited by Last of the Wolves (2009-08-22 10:17:41)

atomopawn · 2009-08-22 12:28:35

Did you commit? I can't seem to pull them off of either git repository.

atomopawn · 2009-08-22 12:37:23

Oh. I see. You created a new branch. My bad.

Arch Linux

#1451 2009-08-19 09:21:03

Re: Daily KDE4 Subversion Packages

#1452 2009-08-19 09:24:06

Re: Daily KDE4 Subversion Packages

#1453 2009-08-19 09:35:50

Re: Daily KDE4 Subversion Packages

#1454 2009-08-19 21:18:53

Re: Daily KDE4 Subversion Packages

#1455 2009-08-19 21:39:48

Re: Daily KDE4 Subversion Packages

#1456 2009-08-19 21:57:01

Re: Daily KDE4 Subversion Packages

#1457 2009-08-19 22:02:50

Re: Daily KDE4 Subversion Packages

#1458 2009-08-19 22:08:12

Re: Daily KDE4 Subversion Packages

#1459 2009-08-19 22:25:03

Re: Daily KDE4 Subversion Packages

#1460 2009-08-19 22:44:45

Re: Daily KDE4 Subversion Packages

#1461 2009-08-19 23:04:16

Re: Daily KDE4 Subversion Packages

#1462 2009-08-20 03:36:28

Re: Daily KDE4 Subversion Packages

#1463 2009-08-20 04:22:03

Re: Daily KDE4 Subversion Packages

#1464 2009-08-20 06:05:00

Re: Daily KDE4 Subversion Packages

#1465 2009-08-20 07:33:17

Re: Daily KDE4 Subversion Packages

#1466 2009-08-20 08:07:36

Re: Daily KDE4 Subversion Packages

#1467 2009-08-20 08:54:46

Re: Daily KDE4 Subversion Packages

#1468 2009-08-20 08:58:23

Re: Daily KDE4 Subversion Packages

#1469 2009-08-20 09:14:33

Re: Daily KDE4 Subversion Packages

#1470 2009-08-20 09:15:31

Re: Daily KDE4 Subversion Packages

#1471 2009-08-20 09:28:34

Re: Daily KDE4 Subversion Packages

#1472 2009-08-21 16:57:56

Re: Daily KDE4 Subversion Packages

#1473 2009-08-21 17:06:38

Re: Daily KDE4 Subversion Packages

#1474 2009-08-22 12:28:35

Re: Daily KDE4 Subversion Packages

#1475 2009-08-22 12:37:23

Re: Daily KDE4 Subversion Packages

Board footer