Dirk Mueller | 1 Apr 01:50 2005
Picon

Re: ktown downtime

On Wednesday 30 March 2005 01:06, Dirk Mueller wrote:

> after almost 18months of uptime, ktown will be down today in the
> afternoon/evening for system maintenance.

its up again, looks to me like everything is still working. let me know if you 
find problems. 

--

-- 
Dirk//\

Anne-Marie Mahfouf | 1 Apr 02:47 2005
Picon

Re: Fonts in a KDE application

On March 31, 2005 05:24 pm, Kurt V. Hindenburg wrote:
> On Thursday 31 March 2005 10:03 am, Anne-Marie Mahfouf wrote:
> | Hi all,
> |
> | For KDE-Edu fancyness we would like to use specific fonts in some
> | applications. We are thinking in making the Makefile.am install the new
> | font (it's very easy and the user can install it locally or system-wide).
>
> Not to hijack this thread as I'm not sure if Anne-Marie was asking about
> this exactly, but in Konsole we install the console bitmap font in
> $KDEDIR/share/fonts.  In order for those fonts to show up in the
> KFontDialog, the user must first install them via KControl->System
> Administor->Font Installer (I've thrown up simple instruction on
> konsole.kde.org).  Is there a way to automatic at installation time or at
> KDE init?
My question was in 2 parts, one is cleared about freedom and the GPL. The 
other is about the install.
We thought we would install it with the following in the Makefile.am (in a 
fonts subdir)
install: font_name.ttf
	kfmclient copy font_name.ttf fonts:/

It works well for our purpose (I was quite amazed by the easiness and the neat 
dialogue, very friendly in my opinion) and then the font is called in the 
program (if it's not there, Qt will default it to something else). The font 
can also be used from any KDE font dialog. No need to be root if you install 
in Personal.
But packagers (we had a nice debate on IRC) pointed out that for building RPMs 
it's not the best so we'll have to see how to do it. For packagers, it would 
be easier to make a separate font package. For example kdeedu-fonts.
(Continue reading)

Kevin Puetz | 1 Apr 04:44 2005

Re: SVN timing

Stephan Kulow wrote:

> Am Mittwoch 30 März 2005 17:34 schrieb Charles Samuels:
>> On Wednesday 30 March 2005 4:28, Stephan Kulow wrote:
>> > Why is that? charles <at>  should work fine
>> I'm a ssh, not a pserver user, though.  I forgot to mention that before.
>> 
>> ssh+svn will work fine (presumably), it's if I accidentally use https
>> with my username.
> From what I know, you can change protocols at any time without recheckout.
> You just need to use svn commit with a full URL.

no, not svn commit, but
svn switch --relocate svn+ssh://etc

will rewrite the URL base in your working copy without redoing the checkout
(this is not the same thing as normal svn switch, would would try and
determine diffs to change between tags/branches; --relocate is specifically
for changing between different protocols or mirrors of the same repository)

> Greetings, Stephan

Oswald Buddenhagen | 1 Apr 07:47 2005
Picon

Re: SVN timing

On Thu, Mar 31, 2005 at 07:05:56PM -0300, Thiago Macieira wrote:
> Old modules in /trunk are erased before release(*).
> 
> (*) Depending on how Ossi's script performs on detecting our server-side 
> moves, most now-empty modules will not even show on /trunk after the 
> conversion.
>
that's the goal.
the simplest case of moving already works. i'm now desperately trying to
come up with some voodoo to auto-detect the more contrieved cases.

> Or, another option, is to completely ignore them in the conversion.
>
yup, but then we'd lose the old tags on most of these modules. also, it
would be impossible to get a consistent old checkout (you really want
this, right? :).

--

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.

Stephan Kulow | 1 Apr 10:38 2005
Picon

Re: SVN timing

Am Freitag 01 April 2005 07:47 schrieb Oswald Buddenhagen:
> the simplest case of moving already works. i'm now desperately trying to
> come up with some voodoo to auto-detect the more contrieved cases.
Sure that it's worth it? The time you're wasting in trying to find some
strange logic could just as well spent in reviewing some output and filter
it to give an input file.

Greetings, Stephan

Oswald Buddenhagen | 1 Apr 10:42 2005
Picon

Re: SVN timing

On Fri, Apr 01, 2005 at 10:38:29AM +0200, Stephan Kulow wrote:
> Am Freitag 01 April 2005 07:47 schrieb Oswald Buddenhagen:
> > the simplest case of moving already works. i'm now desperately trying to
> > come up with some voodoo to auto-detect the more contrieved cases.
> Sure that it's worth it? The time you're wasting in trying to find some
> strange logic could just as well spent in reviewing some output and filter
> it to give an input file.
> 
i've been wondering myself ... ;)
anyway, i hope this to be useful not only for kde.
i had some breakthough ideas just a moment ago, so maybe i can get it
working soon. otherwise i give up and polish the basic variant a bit.

--

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.

Stephan Kulow | 1 Apr 11:02 2005
Picon

Re: SVN: What happens to homeless modules?

Am Donnerstag 31 März 2005 23:57 schrieb Thiago Macieira:
> Stephan Kulow wrote:
[moving to kde-core-devel]

> >kde-common is very tricky as you need it everywhere with symlinks. So
> >it better stays in toplevel - even though it needs to be branched too ;(
> >Or we branch kde-common into /branches/KDE/ when releasing KDE and
> >into /branches/k3b when Sebastian releases k3b. Did you think this to
> > the end ;(
> 
> Since Sebastian will have to update the symlink in the branch anyway, he 
> can just do:
> 
> svn cp trunk/extragear/k3b branches/k3b/0.13
> cd branches/k3b/0.13
> rm admin
> ln -sf ../KDE/3.5/kde-common/admin admin
> cd ..
> svn commit
> 
> That means: k3b 0.13 depends on KDE 3.5.
Hmm, this means everyone has to check out KDE/3.5 exactly this way, no? 
I don't like this at all. I want to have full control where to place my kdelibs,
I don't want to be forced to put it in $mypath/KDE/3.5/kdelibs

And this does not only apply to branches but also in trunk you would need
to have a KDE subdir checked out - if you want or not. The symlinks have 
to fit. Call me stubborn, but this is the killing argument against either symlinks
or nested structures. What were the disadvantages of external properties
again? One was that they are absolute so they had to be redone in branches,
(Continue reading)

Alejandro Exojo | 1 Apr 11:19 2005
X-Face

Re: SVN timing

> Stephan Kulow wrote:
> >I don't like a cluttered trunk - sorting apps into modules is already
> >artificial enough. We could discuss moving kdeplayground-admin into
> >kdeplayground/kdeadmin - but even that I don't really like. We have
> >77 modules so far in svn.kde.org, that's quite a lot but still easy to
> >overview. Easier than wondering if qt-copy is KDE/ or misc/ when
> >browsing.

IMHO, a bit of classification is very useful, especially for the modules that 
follow the release cycle. In general lines, I agree with Thiago's proposal in 
the howto.

El Jueves, 31 de Marzo de 2005 17:25, Thiago Macieira escribió:
> True, but I proposed this for another reason: branching.
>
> When an app is released (say, amarok), the operations are:
> svn cp trunk/kdeextragear/amarok branches/maintenance/amarok/1.3
> svn cp trunk/kdeextragear/amarok tags/amarok/1.3.0
>
> However, when KDE is released, we would have either:
> svn cp trunk/KDE branches/maintenance/KDE/4.0
> svn cp trunk/KDE tags/KDE/4.0.0
>
> OR
>
> svn mkdir branches/maintenance/KDE/4.0
> svn mkdir tags/KDE/4.0.0
> for module in kdesupport kdelibs kdebase [...]; do
>   svn cp trunk/$module branches/maintenance/KDE/4.0/
>   svn cp trunk/$module tags/KDE/4.0
(Continue reading)

Thiago Macieira | 1 Apr 12:48 2005
Picon

Re: SVN: What happens to homeless modules?

Stephan Kulow wrote:
>Hmm, this means everyone has to check out KDE/3.5 exactly this way, no?

At least kde-common inside it.

>I don't like this at all. I want to have full control where to place my
> kdelibs, I don't want to be forced to put it in $mypath/KDE/3.5/kdelibs

That's a downside of using relative paths.

>And this does not only apply to branches but also in trunk you would
> need to have a KDE subdir checked out - if you want or not. The
> symlinks have to fit. Call me stubborn, but this is the killing
> argument against either symlinks or nested structures. What were the
> disadvantages of external properties again? One was that they are
> absolute so they had to be redone in branches, but if I look at your
> example this would also be an argument for KDE/ as every other app or
> module would need to redo them anyway.

True.

But I don't understand what you're proposing. Where would kde-common be?

--

-- 
  Thiago Macieira  -  thiago (AT) macieira (DOT) info
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

1. On frumscafte, hwonne time_t wæs náht, se scieppend þone circolwyrde 
wundorcræftlíge cennede and seo eorðe wæs idel and hit wæs gód.
(Continue reading)

Stephan Kulow | 1 Apr 14:31 2005
Picon

Re: SVN: What happens to homeless modules?

Am Freitag 01 April 2005 12:48 schrieb Thiago Macieira:

> True.
> 
> But I don't understand what you're proposing. Where would kde-common be?
That doesn't matter when we have absolute paths within kdelibs/admin

Greetings, Stephan


Gmane