Re: KDE 4.7.2 (try#1) uploaded
The docs for Kommander are not being installed, is this correct? http://www.chakra-project.org/packages/pkg-ls.php?package=kdewebdev- doc-4.7.90-1-x86_64.pkg.tar.xzsubdir=kde-unstable/x86_64 I tried to run make install directly in the doc/kommander folder: make: *** No rule to make target `install'. Stop. Best regards. Manuel Tortosa ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7.2 (try#1) uploaded
On Sun, Oct 2, 2011 at 5:04 PM, Dirk Mueller muel...@kde.org wrote: Let me know of any issues (my own build is still running). kde-l10n is still being generated and will be uploaded in ~ 3 hours. it built fine on freebsd. is there any idea on the release date? just to understand if it can match our own schedule (it's a matter of days before we freeze our repo) -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7.2 (try#1) uploaded
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/08/2011 06:21 PM, Andreas Pakulat wrote: On 08.10.11 15:24:57, Nicolas Alvarez wrote: Andreas Pakulat wrote: On 08.10.11 01:10:50, Nicolas Alvarez wrote: Andras Mantia wrote: On Sunday, October 02, 2011 17:04:42 Dirk Mueller wrote: Hi, I just finished uploading KDE 4.7.2 tarballs. Unlike previous tarballs, these have been consistently taken from KDE/4.7 branch in git. What does this mean, no 4.7.2 tag was created in git? I don't see anything like that with git tag in kdepim and would like to check if some bugfix made into 4.7.2 or not. dc60f1116dad12fbdd443a964d58eec7e5ed09fc (kdepim-runtime) 84edd007f903763b61296a84768e2f4c9f98113a (kdepimlibs) Tags are created *after* the tarballs. If packagers find problems in a non-final tarball, Dirk can release a new one, but tags are immutable, so they should be created only once we're sure everything is okay. Sorry thats wrong: git tag -a 4.7.2 edit source file git commit -a -m Blah git tag -f -a 4.7.2 works just fine and you can push the result without needing the force-parameter as long as the commit the tag points to now is a successor of the one it pointed to before. As far as I know, that's not the case for annotated tags. If a tag points at a commit A, it can be updated to commit B if A is an ancestor of B. But if the tag points at an annotated tag object which in turn points at commit A, you can't update it at all. There is nothing that can be a successor of the tag object. Did you actually try it out? I've done this twice in the last 4 weeks at work and did not run into any problems. And neither did I when I tried right now :) Andreas That works very well *until the tag is pushed*. Once the tag has been pushed, if you try and push a changed tag, anyone that pulled the repo with the old tag *will not see the tag change*. This behavior is by design, the following excerpt from git-tag(1) explains why: On Re-tagging What should you do when you tag a wrong commit and you would want to re-tag? If you never pushed anything out, just re-tag it. Use -f to replace the old one. And you’re done. But if you have pushed things out (or others could just read your repository directly), then others will have already seen the old tag. In that case you can do one of two things: 1. The sane thing. Just admit you screwed up, and use a different name. Others have already seen one tag-name, and if you keep the same name, you may be in the situation that two people both have version X, but they actually have _different_ X's. So just call it X.1 and be done with it. 2. The insane thing. You really want to call the new version X too, _even though_ others have already seen the old one. So just use `git tag -f again`, as if you hadn’t already published the old one. However, Git does *not* (and it should not) change tags behind users back. So if somebody already got the old tag, doing a `git pull` on your tree shouldn’t just make them overwrite the old one. If somebody got a release tag from you, you cannot just change the tag for them by updating your own one. This is a big security issue, in that people MUST be able to trust their tag-names. If you really want to do the insane thing, you need to just fess up to it, and tell people that you messed up. You can do that by making a very public announcement saying: Ok, I messed up, and I pushed out an earlier version tagged as X. I then fixed something, and retagged the *fixed* tree as X again. If you got the wrong tag, and want the new one, please delete the old one and fetch the new one by doing: git tag -d X git fetch origin tag X to get my updated tag. You can test which tag you have by doing git rev-parse X which should return 0123456789abcdef.. if you have the new version. Sorry for the inconvenience. Does this seem a bit complicated? It *should* be. There is no way that it would be correct to just fix it automatically. People need to know that their tags might have been changed. [end excerpt] - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJOknWNAAoJELHSF2kinlg4ELAP/iypplNPfMrdsCODfFG/tlCn ILk+VQPJPdeB4x3NyHKHOlsX04+K+h0Voj0IQjy51fUGurAylaJ/cX+IDv6eTpNy Xb4JX3uYCBzkzZFUfxhMvmpQXjx2h3ZRWjyQnfkGZXGF4rm+60CFD91ChjVlb6Bq uJc4SlfFq+Zf7CrJ1pYjV6X/8hSKXjxKic5bZqXSZNErXI/VLThrGaJucXgheQkG PeGjxZWEw1o/Wkz1//4v+muevYnK43k1EAn5/AOUWE4mybQfSMZuXyJWZhezQnn2
Re: KDE 4.7.2 (try#1) uploaded
On 10.10.11 00:33:17, Jonathan Callen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/08/2011 06:21 PM, Andreas Pakulat wrote: On 08.10.11 15:24:57, Nicolas Alvarez wrote: Andreas Pakulat wrote: On 08.10.11 01:10:50, Nicolas Alvarez wrote: Andras Mantia wrote: On Sunday, October 02, 2011 17:04:42 Dirk Mueller wrote: Hi, I just finished uploading KDE 4.7.2 tarballs. Unlike previous tarballs, these have been consistently taken from KDE/4.7 branch in git. What does this mean, no 4.7.2 tag was created in git? I don't see anything like that with git tag in kdepim and would like to check if some bugfix made into 4.7.2 or not. dc60f1116dad12fbdd443a964d58eec7e5ed09fc (kdepim-runtime) 84edd007f903763b61296a84768e2f4c9f98113a (kdepimlibs) Tags are created *after* the tarballs. If packagers find problems in a non-final tarball, Dirk can release a new one, but tags are immutable, so they should be created only once we're sure everything is okay. Sorry thats wrong: git tag -a 4.7.2 edit source file git commit -a -m Blah git tag -f -a 4.7.2 works just fine and you can push the result without needing the force-parameter as long as the commit the tag points to now is a successor of the one it pointed to before. As far as I know, that's not the case for annotated tags. If a tag points at a commit A, it can be updated to commit B if A is an ancestor of B. But if the tag points at an annotated tag object which in turn points at commit A, you can't update it at all. There is nothing that can be a successor of the tag object. Did you actually try it out? I've done this twice in the last 4 weeks at work and did not run into any problems. And neither did I when I tried right now :) Andreas That works very well *until the tag is pushed*. Once the tag has been pushed, if you try and push a changed tag, anyone that pulled the repo with the old tag *will not see the tag change*. This behavior is by design, the following excerpt from git-tag(1) explains why: Indeed, though unlike the documentation suggests a simple git fetch --targs will do the job without the necessity to first delete the old tag. Andreas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7.2 (try#1) uploaded
If you can't tag the release in Git initially because you might need to re-roll the tarballs with fixes, then please include the commit IDs in the announcement. However, it seem to me that the main problem is that you are generally not fond of doing bumps of the version after a e.g. 4.7.x release. We often get these additional patches we need to apply also, instead of a 4.7.1.1 release. Would it be too much work to do these updated releases? Then the tags would always match the tarball versions Best, Kim ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7.2 (try#1) uploaded
On 08.10.11 01:10:50, Nicolas Alvarez wrote: Andras Mantia wrote: On Sunday, October 02, 2011 17:04:42 Dirk Mueller wrote: Hi, I just finished uploading KDE 4.7.2 tarballs. Unlike previous tarballs, these have been consistently taken from KDE/4.7 branch in git. What does this mean, no 4.7.2 tag was created in git? I don't see anything like that with git tag in kdepim and would like to check if some bugfix made into 4.7.2 or not. dc60f1116dad12fbdd443a964d58eec7e5ed09fc (kdepim-runtime) 84edd007f903763b61296a84768e2f4c9f98113a (kdepimlibs) Tags are created *after* the tarballs. If packagers find problems in a non-final tarball, Dirk can release a new one, but tags are immutable, so they should be created only once we're sure everything is okay. Sorry thats wrong: git tag -a 4.7.2 edit source file git commit -a -m Blah git tag -f -a 4.7.2 works just fine and you can push the result without needing the force-parameter as long as the commit the tag points to now is a successor of the one it pointed to before. Andreas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7.2 (try#1) uploaded
Andreas Pakulat wrote: On 08.10.11 01:10:50, Nicolas Alvarez wrote: Andras Mantia wrote: On Sunday, October 02, 2011 17:04:42 Dirk Mueller wrote: Hi, I just finished uploading KDE 4.7.2 tarballs. Unlike previous tarballs, these have been consistently taken from KDE/4.7 branch in git. What does this mean, no 4.7.2 tag was created in git? I don't see anything like that with git tag in kdepim and would like to check if some bugfix made into 4.7.2 or not. dc60f1116dad12fbdd443a964d58eec7e5ed09fc (kdepim-runtime) 84edd007f903763b61296a84768e2f4c9f98113a (kdepimlibs) Tags are created *after* the tarballs. If packagers find problems in a non-final tarball, Dirk can release a new one, but tags are immutable, so they should be created only once we're sure everything is okay. Sorry thats wrong: git tag -a 4.7.2 edit source file git commit -a -m Blah git tag -f -a 4.7.2 works just fine and you can push the result without needing the force-parameter as long as the commit the tag points to now is a successor of the one it pointed to before. This would not automagically change tags in all local clones (at least until their owners will `git pull` again). -- Yury G. Kudryashov, mailto: ur...@mccme.ru ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7.2 (try#1) uploaded
Andreas Pakulat wrote: On 08.10.11 01:10:50, Nicolas Alvarez wrote: Andras Mantia wrote: On Sunday, October 02, 2011 17:04:42 Dirk Mueller wrote: Hi, I just finished uploading KDE 4.7.2 tarballs. Unlike previous tarballs, these have been consistently taken from KDE/4.7 branch in git. What does this mean, no 4.7.2 tag was created in git? I don't see anything like that with git tag in kdepim and would like to check if some bugfix made into 4.7.2 or not. dc60f1116dad12fbdd443a964d58eec7e5ed09fc (kdepim-runtime) 84edd007f903763b61296a84768e2f4c9f98113a (kdepimlibs) Tags are created *after* the tarballs. If packagers find problems in a non-final tarball, Dirk can release a new one, but tags are immutable, so they should be created only once we're sure everything is okay. Sorry thats wrong: git tag -a 4.7.2 edit source file git commit -a -m Blah git tag -f -a 4.7.2 works just fine and you can push the result without needing the force-parameter as long as the commit the tag points to now is a successor of the one it pointed to before. As far as I know, that's not the case for annotated tags. If a tag points at a commit A, it can be updated to commit B if A is an ancestor of B. But if the tag points at an annotated tag object which in turn points at commit A, you can't update it at all. There is nothing that can be a successor of the tag object. -- Nicolas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7.2 (try#1) uploaded
On 08.10.11 15:24:57, Nicolas Alvarez wrote: Andreas Pakulat wrote: On 08.10.11 01:10:50, Nicolas Alvarez wrote: Andras Mantia wrote: On Sunday, October 02, 2011 17:04:42 Dirk Mueller wrote: Hi, I just finished uploading KDE 4.7.2 tarballs. Unlike previous tarballs, these have been consistently taken from KDE/4.7 branch in git. What does this mean, no 4.7.2 tag was created in git? I don't see anything like that with git tag in kdepim and would like to check if some bugfix made into 4.7.2 or not. dc60f1116dad12fbdd443a964d58eec7e5ed09fc (kdepim-runtime) 84edd007f903763b61296a84768e2f4c9f98113a (kdepimlibs) Tags are created *after* the tarballs. If packagers find problems in a non-final tarball, Dirk can release a new one, but tags are immutable, so they should be created only once we're sure everything is okay. Sorry thats wrong: git tag -a 4.7.2 edit source file git commit -a -m Blah git tag -f -a 4.7.2 works just fine and you can push the result without needing the force-parameter as long as the commit the tag points to now is a successor of the one it pointed to before. As far as I know, that's not the case for annotated tags. If a tag points at a commit A, it can be updated to commit B if A is an ancestor of B. But if the tag points at an annotated tag object which in turn points at commit A, you can't update it at all. There is nothing that can be a successor of the tag object. Did you actually try it out? I've done this twice in the last 4 weeks at work and did not run into any problems. And neither did I when I tried right now :) Andreas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7.2 (try#1) uploaded
Andras Mantia wrote: On Sunday, October 02, 2011 17:04:42 Dirk Mueller wrote: Hi, I just finished uploading KDE 4.7.2 tarballs. Unlike previous tarballs, these have been consistently taken from KDE/4.7 branch in git. What does this mean, no 4.7.2 tag was created in git? I don't see anything like that with git tag in kdepim and would like to check if some bugfix made into 4.7.2 or not. dc60f1116dad12fbdd443a964d58eec7e5ed09fc (kdepim-runtime) 84edd007f903763b61296a84768e2f4c9f98113a (kdepimlibs) Tags are created *after* the tarballs. If packagers find problems in a non-final tarball, Dirk can release a new one, but tags are immutable, so they should be created only once we're sure everything is okay. -- Nicolas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7.2 (try#1) uploaded
On Wednesday 05 October 2011, Alberto Villa wrote: it built fine on freebsd. is there any idea on the release date? just to understand if it can match our own schedule (it's a matter of days before we freeze our repo) We plan to push the announcement out today. Thanks, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7.2 (try#1) uploaded
On Sun, 2 Oct 2011, Dirk Mueller wrote: Hi, I just finished uploading KDE 4.7.2 tarballs. Unlike previous tarballs, these have been consistently taken from KDE/4.7 branch in git. Let me know of any issues (my own build is still running). kde-l10n is still being generated and will be uploaded in ~ 3 hours. Thanks, Dirk Hi Dirk Thanks for finally uploading the l10n tarballs, but still missing are kdeutils and kdeaccessibility. Could you upload those too please? Cheers, Eric -- Eric Hameleers al...@slackware.com Jabber: al...@jabber.xs4all.nl ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7.2 (try#1) uploaded
On Tuesday 04 October 2011, Eric Hameleers wrote: Thanks for finally uploading the l10n tarballs, but still missing are kdeutils and kdeaccessibility. Could you upload those too please? Sure, thanks for the reminder: 1669d5179e339ebc2d88502c7af050d3 kdeaccessibility-4.7.2.tar.bz2 ea7888ad0752009b427065ceedc9e265 kdeutils-4.7.2.tar.bz2 Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7.2 (try#1) uploaded
On Sunday, October 02, 2011 17:04:42 Dirk Mueller wrote: Hi, I just finished uploading KDE 4.7.2 tarballs. Unlike previous tarballs, these have been consistently taken from KDE/4.7 branch in git. What does this mean, no 4.7.2 tag was created in git? I don't see anything like that with git tag in kdepim and would like to check if some bugfix made into 4.7.2 or not. dc60f1116dad12fbdd443a964d58eec7e5ed09fc (kdepim-runtime) 84edd007f903763b61296a84768e2f4c9f98113a (kdepimlibs) Andras ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7.2 (try#1) uploaded
On Sunday 02 of October 2011, Dirk Mueller wrote: Hi, I just finished uploading KDE 4.7.2 tarballs. Unlike previous tarballs, these have been consistently taken from KDE/4.7 branch in git. Let me know of any issues (my own build is still running). kde-l10n is still being generated and will be uploaded in ~ 3 hours. kdeaccessibility tarball is missing (was in 4.7.1) -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.7.2 (try#1) uploaded
On 10/02/2011 06:27 PM, Arkadiusz Miśkiewicz wrote: On Sunday 02 of October 2011, Dirk Mueller wrote: Hi, I just finished uploading KDE 4.7.2 tarballs. Unlike previous tarballs, these have been consistently taken from KDE/4.7 branch in git. Let me know of any issues (my own build is still running). kde-l10n is still being generated and will be uploaded in ~ 3 hours. kdeaccessibility tarball is missing (was in 4.7.1) Add kdeutils to that list, making it both split packages that are missing. Philip Muskovac ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
