<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.kde.scm-interest">
    <title>gmane.comp.kde.scm-interest</title>
    <link>http://blog.gmane.org/gmane.comp.kde.scm-interest</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.kde.scm-interest/2128"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.kde.scm-interest/2126"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.kde.scm-interest/2112"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.kde.scm-interest/2110"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.kde.scm-interest/2107"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.kde.scm-interest/2105"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.kde.scm-interest/2099"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.kde.scm-interest/2097"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.kde.scm-interest/2071"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.kde.scm-interest/2063"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.kde.scm-interest/2057"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.kde.scm-interest/2051"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.kde.scm-interest/2033"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.kde.scm-interest/2032"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.kde.scm-interest/2026"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.kde.scm-interest/2012"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.kde.scm-interest/2007"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.kde.scm-interest/1962"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.kde.scm-interest/1959"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.kde.scm-interest/1953"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.kde.scm-interest/2128">
    <title>KDESDK to git migration: Build system changes</title>
    <link>http://comments.gmane.org/gmane.comp.kde.scm-interest/2128</link>
    <description>&lt;pre&gt;Hi,
how does the new structure works in terms of building?

So far we have one top-level CMakeLists.txt for the whole of KDESDK.
This seems to be useful for releasing a KDESDK tarball to end users /
distributions. However I suppose that every single repository should
have an independently-working build file in its own root directory,
i.e. one that does not depend on the KDESDK one for finding stuff out
(as is the case now).

Can anyone confirm or correct this?

Regards
Sebastian
&lt;/pre&gt;</description>
    <dc:creator>Sebastian Dörner</dc:creator>
    <dc:date>2012-05-23T21:29:51</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.kde.scm-interest/2126">
    <title>KDESDK to git migration: how many repos for thesmall developer utils?</title>
    <link>http://comments.gmane.org/gmane.comp.kde.scm-interest/2126</link>
    <description>&lt;pre&gt;Hi,

[[cc: to kde-scm-interest just for heads-up,
  follow-ups _only_ on kde-sdk-devel please]]

so we are in Phase 1 of the process:
"Decide which repos should be created from which submodules".

For the kind-of-standalone programs and the plugins it seems there is 
consensus how they should be split, a repo per program as well as a repo per 
plugin type.

But what about all those small developer utils?
There are some for developers using... 
... KDE libs/framework: 
* kpartloader - David Faure 
* scripts - Michael Pyne 

... Qt libs/framework: 
* kuiviewer - Benjamin C. Meyer 
* kprofilemethod - David Faure 

... X libs: 
* kstartperf - Geert Jansen 

... C++(/C?): 
* kmtrace - ? 

How should these submodules be split? 
a) One repo with all? 
b) "scripts" in a separate repo, rest in one? 
c) Each an own repo?
d) ?

(Above from http://community.kde.org/KDESDK/Git_Migration#Development_utils )

I currently would vote for b) or a). But I have no real hard rules besides the 
amount of files in the submodules.&lt;/pre&gt;</description>
    <dc:creator>Friedrich W. H. Kossebau</dc:creator>
    <dc:date>2012-05-22T16:31:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.kde.scm-interest/2112">
    <title>Migration of KDESDK to git, finally? :)</title>
    <link>http://comments.gmane.org/gmane.comp.kde.scm-interest/2112</link>
    <description>&lt;pre&gt;Hi,

KDESDK currently is still in svn. At least for Okteta I would like to have
a move from svn to git as soon as possible.

While there have been two threads about this on this list,
"migration of kdesdk to git - status?" from 18.12.2010 and
"Idea: Converting KDESDK incrementally" from 28.03.2011, so far
nothing has happened, besides Kate and kdesrc-build having moved out
of KDESDK to other modules. I would like to change that and have something
happening :)

The gist from the threads is that
* the KDESDK module should be split into separate repos, as the single
  submodules do not have anything in common, like libs or stuff
* the whole of KDESDK should be moved to git in one step, to reduce the mess
  for release managers, packagers and friends
Anyone disagrees?

Some brave people seem to have prepared set of rules for all the components
of the KDESDK module (thanks to them), see
https://projects.kde.org/projects/playground/sdk/kde-
ruleset/repository/revisions/master/show/kdesdk
What is the state of these&lt;/pre&gt;</description>
    <dc:creator>Friedrich W. H. Kossebau</dc:creator>
    <dc:date>2012-05-08T15:11:51</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.kde.scm-interest/2110">
    <title>svn2git: Representing old work that does not have a direct connection to current master</title>
    <link>http://comments.gmane.org/gmane.comp.kde.scm-interest/2110</link>
    <description>&lt;pre&gt;Hi,

I'm working on kdegames/palapeli-rules. Palapeli lived in
playground/games for a very long time. 1.5 years into its development,
I decided to rewrite it from scratch using the lessons I learned over
the time.

So I moved the directory trunk/playground/games/palapeli to
trunk/playground/games/palapeli.old and started development of the
rewrite at the old path trunk/playground/games/palapeli. I kept the
old source code in the "palapeli.old" directory for a month to use it
as a reference when writing the new code. (I did not know about "svn
checkout -R" back then.)

In the rules, I'm thinking of

1. using the parentmap to make the first commit on the new Palapeli
(1028102) the parent of the last commit of the old Palapeli (1024816)
and

2. omitting those commits which move the old code to "palapeli.old"
(1028097) and delete this directory a month later (1043580).

This should maintain temporal and contextual order without introducing
additional branches. Is this a good idea? If not, what do you suggest?

G&lt;/pre&gt;</description>
    <dc:creator>Stefan Majewsky</dc:creator>
    <dc:date>2012-03-11T21:32:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.kde.scm-interest/2107">
    <title>superbuild: git clone dir gets removed whenrebuilding cache</title>
    <link>http://comments.gmane.org/gmane.comp.kde.scm-interest/2107</link>
    <description>&lt;pre&gt;Hello Alex,

Looking for a hint to better superbuild.
Here is my case (once again :) )

I configured superbuild to get the sources in a separate, global, 
directory. I added this into the GlobalSuperbuildOptions.cmake:

set(SB_SRC_CLONE_DIR $ENV{KDEDIR}/src)
(please see my last commit 3ec2909821e408fad6, which introduces this 
variable)

I then do this:
cd kdesupport/
mkdir build
cd build
cmake ..
cmake-gui .. [then I configure the build]
make

Please note that before doing this, my KDEDIR/src already has clones of 
the ldesupport components.
However, doing make would delete the corresponding directories, then 
re-clone them.
Here is an example of the output for LibStreamAnalyzer

Scanning dependencies of target LibStreamAnalyzer
[ 50%] Creating directories for 'LibStreamAnalyzer'
[ 50%] Performing download step (git clone) for 'LibStreamAnalyzer'
Cloning into 'LibStreamAnalyzer'...
remote: Counting objects: 24940, done.
remote: Compressing objects: 100% (5085/5085), done.
remote: Total 24940 (delta 19797), &lt;/pre&gt;</description>
    <dc:creator>Valentin Rusu</dc:creator>
    <dc:date>2011-12-17T10:47:57</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.kde.scm-interest/2105">
    <title>Moving a directory from one KDE repository toanother</title>
    <link>http://comments.gmane.org/gmane.comp.kde.scm-interest/2105</link>
    <description>&lt;pre&gt;What is the best way to move a directory from one KDE repository to another, while preserving history? Is the sequence of commands in http://lists.kde.org/?l=kde-scm-interest&amp;amp;m=129019711601449&amp;amp;w=2 a good way? I wonder whether the --tag-name-filter option to git filter-branch should also be used to preserve tags.

&lt;/pre&gt;</description>
    <dc:creator>David Jarvie</dc:creator>
    <dc:date>2011-10-17T23:49:43</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.kde.scm-interest/2099">
    <title>Deactivating this list</title>
    <link>http://comments.gmane.org/gmane.comp.kde.scm-interest/2099</link>
    <description>&lt;pre&gt;Hello

The Git conversion of the KDE repositories is almost complete. There have been 
a grand total of 2 emails in the past 30 days on this mailing list. Meanwhile, 
the spam traffic has increased quite considerably (&amp;gt; 1 spam per day).

I'd like to propose this list be deactivated on Dec 1st. That gives us 45 days 
to wrap up any subjects pending.

Any objections?

&lt;/pre&gt;</description>
    <dc:creator>Thiago Macieira</dc:creator>
    <dc:date>2011-10-14T08:18:38</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.kde.scm-interest/2097">
    <title>Git User's Survey 2011</title>
    <link>http://comments.gmane.org/gmane.comp.kde.scm-interest/2097</link>
    <description>&lt;pre&gt;
Go forth and participate: https://www.survs.com/survey/VCAGZA8CT5


&lt;/pre&gt;</description>
    <dc:creator>Eike Hein</dc:creator>
    <dc:date>2011-09-23T17:28:30</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.kde.scm-interest/2071">
    <title>Moving code across repositories</title>
    <link>http://comments.gmane.org/gmane.comp.kde.scm-interest/2071</link>
    <description>&lt;pre&gt;Hi

I think we need a nice howto on how to move code from one repository to
another.

I at least need some code from kde-runtime over in kdelibs for the
frameworks effort, and is a bit unsure how to actually do that.

Any help, ideas and nice scripts are welcome.

/Sune

&lt;/pre&gt;</description>
    <dc:creator>Sune Vuorela</dc:creator>
    <dc:date>2011-08-11T16:57:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.kde.scm-interest/2063">
    <title>pushing rebased shared branches</title>
    <link>http://comments.gmane.org/gmane.comp.kde.scm-interest/2063</link>
    <description>&lt;pre&gt;Hi,

I have been fixing branches of SoK students, removing some dirty manual merges 
and branch mixups, by interactive rebase.
I'm fully aware of the implications of rewriting history. 

I had the recollection we could now force-push branches, but:

remote: + refs/heads/sok/presentation digikam mwiesweg DENIED by fallthru
remote: error: hook declined to update refs/heads/sok/presentation
To ssh://git-50bAvAUIC9NAfugRpC6u6w&amp;lt; at &amp;gt;public.gmane.org/digikam
 ! [remote rejected] presentation -&amp;gt; sok/presentation (hook declined)

Missing something here?

I believe I can delete branches, so the alternative procedure would be to 
delete the branch and recreate it under the same name?

Marcel
&lt;/pre&gt;</description>
    <dc:creator>Marcel Wiesweg</dc:creator>
    <dc:date>2011-08-08T10:39:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.kde.scm-interest/2057">
    <title>git BoF</title>
    <link>http://comments.gmane.org/gmane.comp.kde.scm-interest/2057</link>
    <description>&lt;pre&gt;I'm thinking we should have a KDE Git transition BoF. One thought is that
the Git BoF happen after the release team BoF so that they can be given the
opportunity to add stuff to our agenda.

I could use another co-host, anyone want to help?

Ian
&lt;/pre&gt;</description>
    <dc:creator>Ian Monroe</dc:creator>
    <dc:date>2011-06-23T19:13:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.kde.scm-interest/2051">
    <title>GSoc branch best practices</title>
    <link>http://comments.gmane.org/gmane.comp.kde.scm-interest/2051</link>
    <description>&lt;pre&gt;Hi all,

I would be interested on best practices with git branches for our gsoc 
students, assuming the students do not work on master.

With SVN, we always had one dedicated branch for all students, regularly 
synced with trunk. With git, I see some more possibilities:

1) One branch per student
1a) regularly rebased on master
1b) changes regularly merged from master, merged to master at finish
2) One branch for all students, merged at finish

Any KDE projects with experience from last year? Plans for this year?

(Btw, is it now possible to rebase branches in KDE git like 1a?)

Marcel
&lt;/pre&gt;</description>
    <dc:creator>Marcel Wiesweg</dc:creator>
    <dc:date>2011-04-30T19:39:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.kde.scm-interest/2033">
    <title>Idea: Converting KDESDK incrementally</title>
    <link>http://comments.gmane.org/gmane.comp.kde.scm-interest/2033</link>
    <description>&lt;pre&gt;Hi,

KDESDK is still using svn up to now and there doesn't seem to be much
progress to make the transition for the whole repository. Also see the
brief discussion on December 18th on kde-scm-interest.
I guess one of the reasons is that KDESDK is rather an ensemble of
individual sub-projects than one coherent module, so there is nobody who
knows all the code and its history (correct me if wrong). Also, as
stated in the a. m. discussion, the current maintainer doesn't have time
to do it.

I wonder if it would be feasible/sensible to do the conversion
incrementally. In this model, people feeling responsible for parts of
KDESDK write rules for their part and move the part to git individually.
This would require them to know the history only for their part (which
they certainly do) instead of knowing the history of whole kdesdk (which
they less likely do).
E.g. I would feel competent to write rules for kdesdk/dolphin-plugins,
but don't know anything about the rest.

Is there anything that makes this proposal a ba&lt;/pre&gt;</description>
    <dc:creator>Sebastian Dörner</dc:creator>
    <dc:date>2011-03-28T20:48:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.kde.scm-interest/2032">
    <title>GSoC coding workflow</title>
    <link>http://comments.gmane.org/gmane.comp.kde.scm-interest/2032</link>
    <description>&lt;pre&gt;Hi,

I feel some guidelines need to be established in order to have a nice workflow 
from GSoC students. Below are some points I think should help, I propose to 
put them on a Community wiki page if you all agree about them.

Code
- for additional features to Foo project still in svn, develop the GSoC in a 
svn branch  (naming convention?)
- for additional features to Foo project in Git, develop the GSoC in a Git 
branch of foo (naming convention?)
- for new code, use a Git personal repository as described here 
http://community.kde.org/Sysadmin/GitFAQ#Personal_scratch_repositories and 
when the code is mature and stable enough, move it to git playground.

Licencing
- all coded files should have a licence header as explained in 
http://techbase.kde.org/Policies/Licensing_Policy

(I saw student code without proper licencing so I think this needs to be 
clear)

Anything else? Is that OK?

Best regards,

Anne-Marie
&lt;/pre&gt;</description>
    <dc:creator>Anne-Marie Mahfouf</dc:creator>
    <dc:date>2011-03-27T16:39:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.kde.scm-interest/2026">
    <title>moving code from a KDE project to another one...</title>
    <link>http://comments.gmane.org/gmane.comp.kde.scm-interest/2026</link>
    <description>&lt;pre&gt;Hi all,

I would to move wikimedia kipi-plugin source code from this place :

https://projects.kde.org/projects/playground/base/silk/repository/revisions/master/show/mediawiki/kipi-plugin

to this place :

https://projects.kde.org/projects/extragear/graphics/kipi-plugins/repository

How to do it without to lost Git history ?

Thanks in advance

Gilles Caulier
&lt;/pre&gt;</description>
    <dc:creator>Gilles Caulier</dc:creator>
    <dc:date>2011-03-24T14:42:28</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.kde.scm-interest/2012">
    <title>svn2git playground publictransport</title>
    <link>http://comments.gmane.org/gmane.comp.kde.scm-interest/2012</link>
    <description>&lt;pre&gt;Hi,

I want to move my PublicTransport Plasma data engines, applet and runner from 
SVN playground to git, into a single repository.
I already have a "publictransport-rules" file, that moves the stuff into 
"scratch/fkpulz/publictransport".

- Should I move it to "scratch/fkpulz/publictransport" or to "publictransport" 
as playground repository? It should be quite stable and was in SVN playground 
since 2009.

- I'm unsure about one rule. It movest 
"/trunk/playground/base/plasma/applets/publictransport/" to 
"scratch/fkpulz/publictransport/plasma-applet-publictransport". The 
subdirectory in SVN named 
"/trunk/playground/base/plasma/applets/publictransport/publictransporthelper" 
gets moved to "scratch/fkpulz/publictransport/libpublictransporthelper" by 
another rule. Does the first one also move the subdirectory to 
"scratch/fkpulz/publictransport/plasma-applet-publictransport"? If not, 
everything should be fine. Otherwise I want to ignore the subdirectory in that 
rule..

- Do I really need to download t&lt;/pre&gt;</description>
    <dc:creator>Friedrich Pülz</dc:creator>
    <dc:date>2011-02-25T15:01:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.kde.scm-interest/2007">
    <title>My proposal for a git workflow</title>
    <link>http://comments.gmane.org/gmane.comp.kde.scm-interest/2007</link>
    <description>&lt;pre&gt;Hi,

I've added a section for proposed workflows. I think eean wants to create a 
couple of proposals too.

http://community.kde.org/20110213_GitWorkflowAgenda#Proposed_workflows

Please poke holes in mine and let me know if something just won't work in 
it:

http://community.kde.org/20110213_GitWorkflowAgenda/StevesIdea

All the best,

Steve.

&lt;/pre&gt;</description>
    <dc:creator>Stephen Kelly</dc:creator>
    <dc:date>2011-02-15T23:12:16</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.kde.scm-interest/1962">
    <title>kde-edu git repos to validate</title>
    <link>http://comments.gmane.org/gmane.comp.kde.scm-interest/1962</link>
    <description>&lt;pre&gt;I've only done a basic look over on each repo (looked at branches,
made sure each only had one parentless commit), plan on doing more
tonight. But really it helps to know the history of the code  to know
if everything looks right. Also if folks could do build tests that
would be helpful.

The repos are dated from the 13th or so.

You can see them under scratch/ianmonroe at http://quickweb.kde.org

To clone them all, launch `ruby`, copy the following code and end on a
newline + ctrl-d.

[
"blinken",
"cantor",
"kalgebra",
"kalzium",
"kanagram",
"kbruch",
"kgeography",
"khangman",
"kig",
"kiten",
"klettres",
"kmplot",
"kstars",
"ktouch",
"kturtle",
"kwordquiz",
"libkdeedu",
"marble",
"parley",
"rocs",
"step"
].each { |project|
`git clone git://anongit.kde.org/scratch/ianmonroe/#{project}`
}
&lt;/pre&gt;</description>
    <dc:creator>Ian Monroe</dc:creator>
    <dc:date>2011-02-07T22:35:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.kde.scm-interest/1959">
    <title>odd kdeedu conversion crashes</title>
    <link>http://comments.gmane.org/gmane.comp.kde.scm-interest/1959</link>
    <description>&lt;pre&gt;I could use another pair of eyes to help diagnose what is going wrong
with most of the kdeedu repository conversions. They crash on:
"fatal: Invalid ref name or SHA1 expression: refs/tags/v4.6.0"
but when I go through and look at the logs, everything seems to be
fine. The logs talk about creating a 4.6 branch and then creating a
tag out of it. I suspect that there is nothing wrong with the v4.6.0
tag in particular, it just happens to be the last tag.

I was having lots of trouble, including '00000000000' commits related
to the 4.4.85 tag. First it was tagged, untagged and then retagged
from a different branch. But now I've ignored the original tagging, so
I don't see errors related to it anymore.

I've put a tar of all the logs and the aborted repo of Step at:
http://kollide.net/~eean/step-svn2gitcrash.tar.bz2

The rules are in the kde-ruleset repo, under the kdeedu sub-directory.

The following repos do not crash (all others do):
rocs
marble (which uses a completely different set of rules)
kwordquiz
kstars
&lt;/pre&gt;</description>
    <dc:creator>Ian Monroe</dc:creator>
    <dc:date>2011-02-07T16:32:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.kde.scm-interest/1953">
    <title>KDE/ branch prefixes missing from kdepimlibs andplasma-addons</title>
    <link>http://comments.gmane.org/gmane.comp.kde.scm-interest/1953</link>
    <description>&lt;pre&gt;I notice that the remote branches for kdepimlibs and plasma-addons do not have 
the "KDE/" prefix for the "official" 4.x branches.  Is this a known issue?

WIll
&lt;/pre&gt;</description>
    <dc:creator>Will Stephenson</dc:creator>
    <dc:date>2011-02-04T08:46:43</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.kde.scm-interest/1949">
    <title>problem pushing to kdelibs</title>
    <link>http://comments.gmane.org/gmane.comp.kde.scm-interest/1949</link>
    <description>&lt;pre&gt;Hi. I wanted to push some fixes for kross (this would be my first git push), but ran into the following problem:

[nick&amp;lt; at &amp;gt;mepis1 kross]$ git push origin
Counting objects: 13, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 775 bytes, done.
Total 7 (delta 6), reused 0 (delta 0)
remote: Audit failure - Commit 4029cca96e04d7435c41922dafca61820cece260 - Email Address - nick&amp;lt; at &amp;gt;mepis1.(none)
remote: Push declined - commits failed audit
remote: error: hook declined to update refs/heads/master
To ssh://git-50bAvAUIC9NAfugRpC6u6w&amp;lt; at &amp;gt;public.gmane.org/kdelibs
 ! [remote rejected] master -&amp;gt; master (hook declined)
error: failed to push some refs to 'ssh://git-50bAvAUIC9NAfugRpC6u6w&amp;lt; at &amp;gt;public.gmane.org/kdelibs'

what should i do to pass the audit?
&lt;/pre&gt;</description>
    <dc:creator>Николай Шафоростов</dc:creator>
    <dc:date>2011-02-03T15:32:19</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.kde.scm-interest">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.kde.scm-interest</link>
  </textinput>
</rdf:RDF>

