[prev in list] [next in list] [prev in thread] [next in thread]
List: klik-devel
Subject: Re: [klik-devel] klik-devel Digest, Vol 11, Issue 5
From: "Jason Taylor" <killerkiwi2005 () gmail ! com>
Date: 2006-12-28 0:34:37
Message-ID: 94dd8f6f0612271634td44a1a5g4c78717ce415d4d5 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
First off Lionel, very nice !!
I'm on dialup today (Christmas holidays in NZ :) )
> fuse-devel (not provided with the standard 10.2 DVD,
> not in free, not even in the boxed set)
> compiling patched fuse-iso
> compiling fakechroot
All most full circle aren't we back to binary compat again :)
Does fakechroot have many dependencies, I havnt looked at fuse-iso but i
know fuse-cmg had almost no dependencies (we need both iso and cmg btw)
Agree we should have 2 clients in medium term, current bash and binary
install
Lionel's version looks nice, need to find away to not have to have a script
in the CMG though. NO scripts in the cmg would be the better option if
possible. Else packages will become only compatible with clients (which
could be an issue shortly with existing cmgs).
I think I'm at the point of conceding appending the 'app' meta data to the
end of the CMG, if for no other reason then having a bash version still
workable.
My thinking with binary is if we can cover at least Ubuntu/Debian +
Fedora/Redhat + Suse/open suse then we would cover 95% of GUI linux users,
by providing source code other ppl/distros can always compile the binary
(The client) or use the bash version. I know Probono may disagree with this
Should we replace the bash script version with a python/mount option that
shares 90% code with the binary option?
Lastly Lionel, how can we handle security access to $HOME ? A real concern
is that a cmg could wipe $HOME... Plash dealt with this issue by overriding
the GTK file chooser...
Merry Christmas All
KillerKiwi
On 12/28/06, klik-devel-request@kde.org <klik-devel-request@kde.org> wrote:
>
> Send klik-devel mailing list submissions to
> klik-devel@kde.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.kde.org/mailman/listinfo/klik-devel
> or, via email, send a message with subject or body 'help' to
> klik-devel-request@kde.org
>
> You can reach the person managing the list at
> klik-devel-owner@kde.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of klik-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: fuseiso patched to support chroot jail (Alexey Eremenko)
> 2. fuseiso-p5 + fakechroot-p1 : No need to --bind now !
> (lionel.tricon@free.fr)
> 3. The future direction of klik development (Alexey Eremenko)
> 4. our website seems not to work fully: (Alexey Eremenko)
> 5. Re: fuseiso-p5 + fakechroot-p1 : No need to --bind now !
> (Alexey Eremenko)
> 6. Re: The future direction of klik development
> (lionel.tricon@free.fr)
> 7. Re: The future direction of klik development (Alexey Eremenko)
> 8. Re: The future direction of klik development
> (lionel.tricon@free.fr)
> 9. Re: The future direction of klik development (Alexey Eremenko)
> 10. Re: The future direction of klik development (probono)
> 11. Re: The future direction of klik development (Alexey Eremenko)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 27 Dec 2006 18:56:49 +0200
> From: "Alexey Eremenko" <al4321@gmail.com>
> Subject: Re: [klik-devel] fuseiso patched to support chroot jail
> To: klik-devel@kde.org
> Message-ID:
> <7fac565a0612270856j62697c10x80efa09c8bc355c0@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hello Lionel and klikers !
>
> Now there is a new problem - compatibility across Linuxes.
>
> Until now klik-client used bash-technology, so we stayed more-or-less
> compatible across distros. That means we didn't need to compile stuff
> and single client worked across many distros.
>
> Now if we adopt the new fuse technology, how we will be able to
> install a klik client ?
>
> The standards OSes don't provide that functionality (even newest
> openSUSE 10.2 boxed version doesn't) !
>
> make a klik-client distro-specific or what ?
>
> I can try to make a klik-client to be openSUSE 10.2 specific, but how
> do we cover installation on all other distros?
>
> Possible solution:
> 1. "fork" the client to "fuseklik-client" which will be distro specific.
> NOTE: forking the client does NOT mean forking the project.
>
> Rather, I see this option as to go forward and stay compatible at
> once. Because that move (i.e. compiling and depending) is risky.
>
> 2. I want this new solution (fuse-klik), the other alternative (plash)
> and the old solution (normal klik-client) to be compatible at both
> server level (klik://myapp) *and* image-level -- final .cmg's or
> .app's.
>
> 3. This way we will be able to both stay compatible on all distros,
> *and* move forward not into one, but two directions simultaneously.
>
> 4. How to implement my crazy idea?
>
> A. make the klik server generate ".cmg's" that include all that new
> information.
> B. modify the new experimental clients to support the standard images
> (I don't know if it's possible to add the generic mounting info into
> the clients instead of the cmg.
> C. if the above is not possible, we should sit together and define a
> new image format that will be able to run across different clients.
> (i.e. new format must contain generic data as well as specific data
> for all 3 clients - normal, plash and fuse)
>
> 5. I know that the conservatives will hate me for that, but the
> Open-Minded will love me for that idea. Basically my idea ensures
> progress, while not risking with anything.
> We don't risk losing Lionel. We don't risk broke compatibility with
> older distros. No risk at all.
>
> What do klikers think of it? Any ideas?
>
> -Alexey Eremenko. 27.12.2006.
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 27 Dec 2006 18:30:02 +0100
> From: lionel.tricon@free.fr
> Subject: [klik-devel] fuseiso-p5 + fakechroot-p1 : No need to --bind
> now !
> To: Alexey Eremenko <al4321@gmail.com>
> Cc: klik-devel@kde.org
> Message-ID: <1167240602.4592ad9a6e050@imp8-g19.free.fr>
> Content-Type: text/plain; charset=utf-8
>
> Today is a good day !
>
> I have patched fakechroot with success to allow us to access special
> devices
> despite of the internal behavior of fuseiso. Fakechroot read directly real
> directories like /dev, /proc, /tmp and the $HOME of the user instead of
> the
> ones from fuseiso.
>
> So, if you install fuseiso-p5 and fakechroot-p1, you can run my testing
> cmg
> files without any troubles i hope (if you have fuse installed) and without
> the
> need of having bindmount or some other hack on the system. The
> /etc/fuse.conf
> file is not useful any more.
>
> I have updated the wiki pages if you want to comment.
>
> Lionel
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 27 Dec 2006 19:35:00 +0200
> From: "Alexey Eremenko" <al4321@gmail.com>
> Subject: [klik-devel] The future direction of klik development
> To: klik-devel@kde.org
> Message-ID:
> <7fac565a0612270935x2dfcf05agb06d63bc6c5bee8f@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> ---------- Forwarded message ----------
> From: Alexey Eremenko <al4321@gmail.com>
> Date: Dec 27, 2006 6:56 PM
> Subject: Re: [klik-devel] fuseiso patched to support chroot jail
> To: klik-devel@kde.org
>
>
> Hello klikers !
>
> Now there is a new problem - compatibility across Linuxes.
>
> Until now klik-client used bash-technology, so we stayed more-or-less
> compatible across distros. That means we didn't need to compile stuff
> and single client worked across many distros.
>
> Now if we adopt the new fuse technology, how we will be able to
> install a klik client ?
>
> The standards OSes don't provide that functionality (even newest
> openSUSE 10.2 boxed version doesn't) !
>
> make a klik-client distro-specific or what ?
>
> Probono will never approve that, and I agree with his stance.
>
> I can try to make a klik-client to be openSUSE 10.2 specific, but how
> do we cover installation on all other distros?
>
>
> Possible solution:
> 1. "fork" the client to "fuseklik-client" which will be distro specific.
> NOTE: forking the client does NOT mean forking the project.
>
> Rather, I see this option as to go forward and stay compatible at
> once. Because that move (i.e. compiling and depending) is risky.
>
> 2. I want this new solution (fuse-klik), the other alternative (plash)
> and the old solution (normal klik-client) to be compatible at both
> server level (klik://myapp) *and* image-level -- final .cmg's or
> .app's.
>
> 3. This way we will be able to both stay compatible on all distros,
> *and* move forward not into one, but two directions simultaneously.
>
> 4. How to implement my crazy idea?
>
> A. make the klik server generate ".cmg's" that include all that new
> information.
> B. modify the new experimental clients to support the standard images
> (I don't know if it's possible to add the generic mounting info into
> the clients instead of the cmg.
> C. if the above is not possible, we should sit together and define a
> new image format that will be able to run across different clients.
> (i.e. new format must contain generic data as well as specific data
> for all 3 clients - normal, plash and fuse)
>
> 5. I know that the conservatives will hate me for that, but the
> Open-Minded will love me for that idea. Basically my idea ensures
> progress, while not risking with anything.
> We don't risk losing Lionel. We don't risk broke compatibility with
> older distros. No risk at all.
>
> What do klikers think of it? Any ideas?
>
> -Alexey Eremenko. 27.12.2006.
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 27 Dec 2006 19:36:44 +0200
> From: "Alexey Eremenko" <al4321@gmail.com>
> Subject: [klik-devel] our website seems not to work fully:
> To: klik-devel@kde.org
> Message-ID:
> <7fac565a0612270936y2ff95e5dl8c05f9697cdaca31@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> for example this page:
> http://klik.atekon.de/docs/?page=Contributors
>
> doesn't load anymore on my system. the main page still runs fine.
> anyone else experiencing the same problems?
>
> -Alexey Eremenko. 27.12.2006.
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 27 Dec 2006 19:41:56 +0200
> From: "Alexey Eremenko" <al4321@gmail.com>
> Subject: Re: [klik-devel] fuseiso-p5 + fakechroot-p1 : No need to
> --bind now !
> To: klik-devel@kde.org
> Message-ID:
> <7fac565a0612270941o6575a4c2sab96aad747f70e0c@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 12/27/06, lionel.tricon@free.fr <lionel.tricon@free.fr> wrote:
> > Today is a good day !
> >
> > I have patched fakechroot with success to allow us to access special
> devices
> > despite of the internal behavior of fuseiso. Fakechroot read directly
> real
> > directories like /dev, /proc, /tmp and the $HOME of the user instead of
> the
> > ones from fuseiso.
> >
> > So, if you install fuseiso-p5 and fakechroot-p1, you can run my testing
> cmg
> > files without any troubles i hope (if you have fuse installed) and
> without the
> > need of having bindmount or some other hack on the system. The
> /etc/fuse.conf
> > file is not useful any more.
> >
> > I have updated the wiki pages if you want to comment.
> >
> > Lionel
> >
>
> Very good !
> Excellent work !
> What do you think about my email of "future direction" ?
>
> -Alexey Eremenko. 27.12.2006.
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 27 Dec 2006 18:53:31 +0100
> From: lionel.tricon@free.fr
> Subject: Re: [klik-devel] The future direction of klik development
> To: Alexey Eremenko <al4321@gmail.com>
> Cc: klik-devel@kde.org
> Message-ID: <1167242011.4592b31beeb41@imp8-g19.free.fr>
> Content-Type: text/plain; charset=utf-8
>
> Selon Alexey Eremenko <al4321@gmail.com>:
> > The standards OSes don't provide that functionality (even newest
> > openSUSE 10.2 boxed version doesn't) !
>
> I disagree, fuse is provided by default since 2.6.14. No need to install
> it on
> SUSE 10.0 and 10.1 for example, and i guess for SUSE 10.2.
>
> > Possible solution:
> > 1. "fork" the client to "fuseklik-client" which will be distro specific.
> > NOTE: forking the client does NOT mean forking the project.
>
> I you want to use fuseiso+fakechroot or fuseiso+Plash, i fear there is no
> workaround. And as you need cmg-thumbnail as well (or equivalent to gnome)
> to
> get meta-data from the iso/cram file and presenting them to the user
> (icon,
> summary, ...), why not imagine a klik2 package that distro in short term
> could
> even provide by default ... And if it works great, why not an inclusion
> directly inside kde4 for example ?
>
> There is no perfect solution.
>
> Lionel
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 27 Dec 2006 20:14:10 +0200
> From: "Alexey Eremenko" <al4321@gmail.com>
> Subject: Re: [klik-devel] The future direction of klik development
> To: "lionel.tricon@free.fr" <lionel.tricon@free.fr>
> Cc: klik-devel@kde.org
> Message-ID:
> <7fac565a0612271014y346ba527v56bb6b0812fa4f2e@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 12/27/06, lionel.tricon@free.fr <lionel.tricon@free.fr> wrote:
> > Selon Alexey Eremenko <al4321@gmail.com>:
> > > The standards OSes don't provide that functionality (even newest
> > > openSUSE 10.2 boxed version doesn't) !
> >
> > I disagree, fuse is provided by default since 2.6.14. No need to install
> it on
> > SUSE 10.0 and 10.1 for example, and i guess for SUSE 10.2.
> >
>
> Not true.
> FUSE and kernel 2.6.14 is just the first part of the requirements.
>
> There is second part of the requirements (the nasty part):
>
> - fuse-devel (not provided with the standard 10.2 DVD, not in free,
> not even in the boxed set)
> - compiling patched fuse-iso
> - compiling fakechroot
>
> So while the kernel modules don't need to be compiled (thank god) we
> still need compilation of some user-space utils.
>
> -Alexey Eremenko
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 27 Dec 2006 20:45:38 +0100
> From: lionel.tricon@free.fr
> Subject: Re: [klik-devel] The future direction of klik development
> To: Alexey Eremenko <al4321@gmail.com>
> Cc: klik-devel@kde.org
> Message-ID: <1167248738.4592cd627d1ec@imp6-g19.free.fr>
> Content-Type: text/plain; charset=ISO-8859-1
>
> It seems difficult to ask to an end user to compile fuseiso and
> fakechroot. Some
> user-space utility should be available in a binary version, for example a
> klikutil package. That does not disturb me if you want to have a good
> integration into the Desktop (kde, gnome or others) with cmg-thundnails
> etc ...
>
> For fuse-devel, strange thing since it's available on
> http://download.opensuse.org/distribution/10.2/repo/oss/suse/i586/
>
> But the question is : is there an another solution ? Even with Plash, you
> will
> need fuseiso so ...
>
> Lionel
>
> Selon Alexey Eremenko <al4321@gmail.com>:
> > Not true.
> > FUSE and kernel 2.6.14 is just the first part of the requirements.
> >
> > There is second part of the requirements (the nasty part):
> >
> > - fuse-devel (not provided with the standard 10.2 DVD, not in free,
> > not even in the boxed set)
> > - compiling patched fuse-iso
> > - compiling fakechroot
> >
> > So while the kernel modules don't need to be compiled (thank god) we
> > still need compilation of some user-space utils.
> >
> > -Alexey Eremenko
> >
>
>
>
>
> ------------------------------
>
> Message: 9
> Date: Thu, 28 Dec 2006 00:15:27 +0200
> From: "Alexey Eremenko" <al4321@gmail.com>
> Subject: Re: [klik-devel] The future direction of klik development
> To: klik-devel@kde.org
> Message-ID:
> <7fac565a0612271415s79269063mb23ecc6da963c0d6@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> > But the question is : is there an another solution ?
>
> YES !!! there is - look at what I have proposed earlier - move forward
> but stay compatible - i.e. make multiple clients that are compatible
> at the image level (either cmg or app).
>
> That is: for full klik experience, users will have to download the
> "binary klik client", that includes full KDE and fuse integration.
>
> But for the lazy people with non-major distros, that don't have
> precompiled client, we will make available the "standard klik client",
> bash based, running on old technology, loop-mount *but* with ability
> to run the latest images. (that is: i recommend building minor update
> to old klik-client to make it compatible with newer images.)
>
> This will basically mean, that if we, for example will not provide a
> binary fuseklik client for say, Fedora Core 7, users will be able to
> run with the old bash klik client.
>
> Users will have a choice which client is right for them.
>
> -Alexey Eremenko.
>
>
> ------------------------------
>
> Message: 10
> Date: Thu, 28 Dec 2006 00:11:06 +0100
> From: probono <probono@myrealbox.com>
> Subject: Re: [klik-devel] The future direction of klik development
> To: klik-devel@kde.org
> Message-ID:
> <85d71c370612271511j1312bb71kfe2e078bc675803f@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> > fuse-devel (not provided with the standard 10.2 DVD,
> > not in free, not even in the boxed set)
> > compiling patched fuse-iso
> > compiling fakechroot
>
> Why do you think the user has to compile those?
> Wouldn't it be possible for the klik client to come bundled with these
> binaries?
> Would there then be another requirement for FUSE besides a recent kernel?
>
> Regards,
> probono
>
>
> ------------------------------
>
> Message: 11
> Date: Thu, 28 Dec 2006 01:47:50 +0200
> From: "Alexey Eremenko" <al4321@gmail.com>
> Subject: Re: [klik-devel] The future direction of klik development
> To: klik-devel@kde.org
> Message-ID:
> <7fac565a0612271547r7672297qfe93c8130f6e3b81@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 12/28/06, probono <probono@myrealbox.com> wrote:
> > > fuse-devel (not provided with the standard 10.2 DVD,
> > > not in free, not even in the boxed set)
> > > compiling patched fuse-iso
> > > compiling fakechroot
> >
> > Why do you think the user has to compile those?
> > Wouldn't it be possible for the klik client to come bundled with these
> binaries?
> > Would there then be another requirement for FUSE besides a recent
> kernel?
> >
>
> How stable are the binary interfaces ?
> How stable is the FSH ?
>
> I am not sure if single binary can run across RedHat, SUSE, Debian and
> Gentoo...
> we can try - and run extensive testing - but providing cross-Linux
> binaries is not easy.
> Alternatively we can provide a script that compiles all the needed
> stuff on the client's system (semi-)automatically. But I don't know if
> this will be easier solution...
>
> -Alexey Eremenko.
>
>
> ------------------------------
>
> _______________________________________________
> klik-devel mailing list
> klik-devel@kde.org
> https://mail.kde.org/mailman/listinfo/klik-devel
>
>
> End of klik-devel Digest, Vol 11, Issue 5
> *****************************************
>
[Attachment #5 (text/html)]
First off Lionel, very nice !!<br><br>I'm on dialup today (Christmas holidays in \
NZ :) )<br><br>> fuse-devel (not provided with the standard 10.2 DVD,<br>> not \
in free, not even in the boxed set)<br>> compiling patched fuse-iso <br>> \
compiling fakechroot<br><br>All most full circle aren't we back to binary compat \
again :)<br><br>Does fakechroot have many dependencies, I havnt looked at fuse-iso \
but i know fuse-cmg had almost no dependencies (we need both iso and cmg btw) \
<br><br>Agree we should have 2 clients in medium term, current bash and binary \
install<br><br>Lionel's version looks nice, need to find away to not have to have \
a script in the CMG though. NO scripts in the cmg would be the better option if \
possible. Else packages will become only compatible with clients (which could be an \
issue shortly with existing cmgs). <br><br>I think I'm at the point of conceding \
appending the 'app' meta data to the end of the CMG, if for no other reason \
then having a bash version still workable.<br><br>My thinking with binary is if we \
can cover at least Ubuntu/Debian + Fedora/Redhat + Suse/open suse then we would cover \
95% of GUI linux users, by providing source code other ppl/distros can always compile \
the binary (The client) or use the bash version. I know Probono may disagree with \
this <br><br>Should we replace the bash script version with a python/mount option \
that shares 90% code with the binary option?<br><br>Lastly Lionel, how can we \
handle security access to $HOME ? A real concern is that a cmg could wipe \
$HOME... Plash dealt with this issue by overriding the GTK file chooser... \
<br><br>Merry Christmas All<br><br>KillerKiwi<br><br><br><br><br><br><div><span \
class="gmail_quote">On 12/28/06, <b class="gmail_sendername"><a \
href="mailto:klik-devel-request@kde.org">klik-devel-request@kde.org</a></b> < <a \
href="mailto:klik-devel-request@kde.org">klik-devel-request@kde.org</a>> \
wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Send klik-devel mailing \
list submissions to<br> <a \
href="mailto:klik-devel@kde.org">klik-devel@kde.org</a><br><br>To subscribe or \
unsubscribe via the World Wide Web, \
visit<br> <a \
href="https://mail.kde.org/mailman/listinfo/klik-devel"> \
https://mail.kde.org/mailman/listinfo/klik-devel</a><br>or, via email, send a message \
with subject or body 'help' \
to<br> <a \
href="mailto:klik-devel-request@kde.org">klik-devel-request@kde.org</a><br><br>You \
can reach the person managing the list at \
<br> <a \
href="mailto:klik-devel-owner@kde.org">klik-devel-owner@kde.org</a><br><br>When \
replying, please edit your Subject line so it is more specific<br>than "Re: \
Contents of klik-devel digest..."<br><br> <br>Today's \
Topics:<br><br> 1. Re: fuseiso patched to support chroot jail (Alexey \
Eremenko)<br> 2. fuseiso-p5 + fakechroot-p1 : No need to --bind now \
!<br> (<a \
href="mailto:lionel.tricon@free.fr">lionel.tricon@free.fr </a>)<br> 3. \
The future direction of klik development (Alexey Eremenko)<br> 4. our \
website seems not to work fully: (Alexey Eremenko)<br> 5. Re: fuseiso-p5 \
+ fakechroot-p1 : No need to --bind \
now !<br> (Alexey Eremenko) \
<br> 6. Re: The future direction of klik \
development<br> (<a \
href="mailto:lionel.tricon@free.fr">lionel.tricon@free.fr</a>)<br> 7. Re: \
The future direction of klik development (Alexey Eremenko)<br> 8. Re: The \
future direction of klik development <br> (<a \
href="mailto:lionel.tricon@free.fr">lionel.tricon@free.fr</a>)<br> 9. Re: \
The future direction of klik development (Alexey Eremenko)<br> 10. Re: The \
future direction of klik development (probono)<br> 11. Re: The future \
direction of klik development (Alexey Eremenko) \
<br><br><br>----------------------------------------------------------------------<br><br>Message: \
1<br>Date: Wed, 27 Dec 2006 18:56:49 +0200<br>From: "Alexey Eremenko" \
<<a href="mailto:al4321@gmail.com">al4321@gmail.com </a>><br>Subject: Re: \
[klik-devel] fuseiso patched to support chroot jail<br>To: <a \
href="mailto:klik-devel@kde.org">klik-devel@kde.org</a><br>Message-ID:<br> <<a \
href="mailto:7fac565a0612270856j62697c10x80efa09c8bc355c0@mail.gmail.com"> \
7fac565a0612270856j62697c10x80efa09c8bc355c0@mail.gmail.com</a>><br>Content-Type: \
text/plain; charset=UTF-8; format=flowed<br><br>Hello Lionel and klikers !<br><br>Now \
there is a new problem - compatibility across Linuxes. <br><br>Until now klik-client \
used bash-technology, so we stayed more-or-less<br>compatible across distros. That \
means we didn't need to compile stuff<br>and single client worked across many \
distros.<br><br>Now if we adopt the new fuse technology, how we will be able to \
<br>install a klik client ?<br><br>The standards OSes don't provide that \
functionality (even newest<br>openSUSE 10.2 boxed version doesn't) !<br><br>make \
a klik-client distro-specific or what ?<br><br>I can try to make a klik-client to be \
openSUSE 10.2 specific, but how<br>do we cover installation on all other \
distros?<br><br>Possible solution:<br>1. "fork" the client to \
"fuseklik-client" which will be distro specific.<br>NOTE: forking the \
client does NOT mean forking the project. <br><br>Rather, I see this option as to go \
forward and stay compatible at<br>once. Because that move (i.e. compiling and \
depending) is risky.<br><br>2. I want this new solution (fuse-klik), the other \
alternative (plash)<br> and the old solution (normal klik-client) to be compatible at \
both<br>server level (klik://myapp) *and* image-level -- final .cmg's \
or<br>.app's.<br><br>3. This way we will be able to both stay compatible on all \
distros, <br>*and* move forward not into one, but two directions \
simultaneously.<br><br>4. How to implement my crazy idea?<br><br>A. make the klik \
server generate ".cmg's" that include all that new information.<br>B. \
modify the new experimental clients to support the standard images <br>(I don't \
know if it's possible to add the generic mounting info into<br>the clients \
instead of the cmg.<br>C. if the above is not possible, we should sit together and \
define a<br>new image format that will be able to run across different clients. \
<br>(i.e. new format must contain generic data as well as specific data<br>for all 3 \
clients - normal, plash and fuse)<br><br>5. I know that the conservatives will hate \
me for that, but the<br>Open-Minded will love me for that idea. Basically my idea \
ensures <br>progress, while not risking with anything.<br>We don't risk losing \
Lionel. We don't risk broke compatibility with<br>older distros. No risk at \
all.<br><br>What do klikers think of it? Any ideas?<br><br>-Alexey Eremenko. \
27.12.2006.<br><br><br>------------------------------<br><br>Message: 2<br>Date: Wed, \
27 Dec 2006 18:30:02 +0100<br>From: <a \
href="mailto:lionel.tricon@free.fr">lionel.tricon@free.fr</a><br>Subject: \
[klik-devel] fuseiso-p5 + fakechroot-p1 : No need to --bind \
<br> now !<br>To: Alexey Eremenko \
<<a href="mailto:al4321@gmail.com">al4321@gmail.com</a>><br>Cc: <a \
href="mailto:klik-devel@kde.org">klik-devel@kde.org</a><br>Message-ID: <<a \
href="mailto:1167240602.4592ad9a6e050@imp8-g19.free.fr"> \
1167240602.4592ad9a6e050@imp8-g19.free.fr</a>><br>Content-Type: text/plain; \
charset=utf-8<br><br>Today is a good day !<br><br>I have patched fakechroot with \
success to allow us to access special devices<br>despite of the internal behavior of \
fuseiso. Fakechroot read directly real <br>directories like /dev, /proc, /tmp and the \
$HOME of the user instead of the<br>ones from fuseiso.<br><br>So, if you install \
fuseiso-p5 and fakechroot-p1, you can run my testing cmg<br>files without any \
troubles i hope (if you have fuse installed) and without the <br>need of having \
bindmount or some other hack on the system. The /etc/fuse.conf<br>file is not useful \
any more.<br><br>I have updated the wiki pages if you want to \
comment.<br><br>Lionel<br><br><br>------------------------------ <br><br>Message: \
3<br>Date: Wed, 27 Dec 2006 19:35:00 +0200<br>From: "Alexey Eremenko" \
<<a href="mailto:al4321@gmail.com">al4321@gmail.com</a>><br>Subject: \
[klik-devel] The future direction of klik development <br>To: <a \
href="mailto:klik-devel@kde.org">klik-devel@kde.org</a><br>Message-ID:<br> <<a \
href="mailto:7fac565a0612270935x2dfcf05agb06d63bc6c5bee8f@mail.gmail.com">7fac565a0612270935x2dfcf05agb06d63bc6c5bee8f@mail.gmail.com
</a>><br>Content-Type: text/plain; charset=UTF-8; format=flowed<br><br>---------- \
Forwarded message ----------<br>From: Alexey Eremenko <<a \
href="mailto:al4321@gmail.com">al4321@gmail.com</a>><br>Date: Dec 27, 2006 6:56 PM \
<br>Subject: Re: [klik-devel] fuseiso patched to support chroot jail<br>To: <a \
href="mailto:klik-devel@kde.org">klik-devel@kde.org</a><br><br><br>Hello klikers \
!<br><br>Now there is a new problem - compatibility across Linuxes. <br><br>Until now \
klik-client used bash-technology, so we stayed more-or-less<br>compatible across \
distros. That means we didn't need to compile stuff<br>and single client worked \
across many distros.<br><br>Now if we adopt the new fuse technology, how we will be \
able to <br>install a klik client ?<br><br>The standards OSes don't provide that \
functionality (even newest<br>openSUSE 10.2 boxed version doesn't) !<br><br>make \
a klik-client distro-specific or what ?<br><br>Probono will never approve that, and I \
agree with his stance. <br><br>I can try to make a klik-client to be openSUSE 10.2 \
specific, but how<br>do we cover installation on all other \
distros?<br><br><br>Possible solution:<br>1. "fork" the client to \
"fuseklik-client" which will be distro specific. <br>NOTE: forking the \
client does NOT mean forking the project.<br><br>Rather, I see this option as to go \
forward and stay compatible at<br>once. Because that move (i.e. compiling and \
depending) is risky.<br><br>2. I want this new solution (fuse-klik), the other \
alternative (plash) <br>and the old solution (normal klik-client) to be compatible at \
both<br>server level (klik://myapp) *and* image-level -- final .cmg's \
or<br>.app's.<br><br>3. This way we will be able to both stay compatible on all \
distros, <br>*and* move forward not into one, but two directions \
simultaneously.<br><br>4. How to implement my crazy idea?<br><br>A. make the klik \
server generate ".cmg's" that include all that new information.<br>B. \
modify the new experimental clients to support the standard images <br>(I don't \
know if it's possible to add the generic mounting info into<br>the clients \
instead of the cmg.<br>C. if the above is not possible, we should sit together and \
define a<br>new image format that will be able to run across different clients. \
<br>(i.e. new format must contain generic data as well as specific data<br>for all 3 \
clients - normal, plash and fuse)<br><br>5. I know that the conservatives will hate \
me for that, but the<br>Open-Minded will love me for that idea. Basically my idea \
ensures <br>progress, while not risking with anything.<br>We don't risk losing \
Lionel. We don't risk broke compatibility with<br>older distros. No risk at \
all.<br><br>What do klikers think of it? Any ideas?<br><br>-Alexey Eremenko. \
27.12.2006.<br><br><br>------------------------------<br><br>Message: 4<br>Date: Wed, \
27 Dec 2006 19:36:44 +0200<br>From: "Alexey Eremenko" <<a \
href="mailto:al4321@gmail.com">al4321@gmail.com</a>><br>Subject: [klik-devel] our \
website seems not to work fully: <br>To: <a \
href="mailto:klik-devel@kde.org">klik-devel@kde.org</a><br>Message-ID:<br> <<a \
href="mailto:7fac565a0612270936y2ff95e5dl8c05f9697cdaca31@mail.gmail.com">7fac565a0612270936y2ff95e5dl8c05f9697cdaca31@mail.gmail.com
</a>><br>Content-Type: text/plain; charset=UTF-8; format=flowed<br><br>for \
example this page:<br><a \
href="http://klik.atekon.de/docs/?page=Contributors">http://klik.atekon.de/docs/?page=Contributors</a><br><br>doesn't \
load anymore on my system. the main page still runs fine. <br>anyone else \
experiencing the same problems?<br><br>-Alexey Eremenko. \
27.12.2006.<br><br><br>------------------------------<br><br>Message: 5<br>Date: Wed, \
27 Dec 2006 19:41:56 +0200<br>From: "Alexey Eremenko" < <a \
href="mailto:al4321@gmail.com">al4321@gmail.com</a>><br>Subject: Re: [klik-devel] \
fuseiso-p5 + fakechroot-p1 : No need \
to<br> --bind \
now !<br>To: <a \
href="mailto:klik-devel@kde.org">klik-devel@kde.org</a> \
<br>Message-ID:<br> <<a \
href="mailto:7fac565a0612270941o6575a4c2sab96aad747f70e0c@mail.gmail.com">7fac565a0612270941o6575a4c2sab96aad747f70e0c@mail.gmail.com</a>><br>Content-Type: \
text/plain; charset=UTF-8; format=flowed <br><br>On 12/27/06, <a \
href="mailto:lionel.tricon@free.fr">lionel.tricon@free.fr</a> <<a \
href="mailto:lionel.tricon@free.fr">lionel.tricon@free.fr</a>> wrote:<br>> \
Today is a good day !<br>><br>> I have patched fakechroot with success to allow \
us to access special devices <br>> despite of the internal behavior of fuseiso. \
Fakechroot read directly real<br>> directories like /dev, /proc, /tmp and the \
$HOME of the user instead of the<br>> ones from fuseiso.<br>><br>> So, if \
you install fuseiso-p5 and fakechroot-p1, you can run my testing cmg <br>> files \
without any troubles i hope (if you have fuse installed) and without the<br>> need \
of having bindmount or some other hack on the system. The /etc/fuse.conf<br>> file \
is not useful any more.<br>><br> > I have updated the wiki pages if you want to \
comment.<br>><br>> Lionel<br>><br><br>Very good !<br>Excellent work \
!<br>What do you think about my email of "future direction" \
?<br><br>-Alexey Eremenko. \
27.12.2006.<br><br><br>------------------------------<br><br>Message: 6<br>Date: Wed, \
27 Dec 2006 18:53:31 +0100<br>From: <a \
href="mailto:lionel.tricon@free.fr">lionel.tricon@free.fr</a><br>Subject: Re: \
[klik-devel] The future direction of klik development <br>To: Alexey Eremenko <<a \
href="mailto:al4321@gmail.com">al4321@gmail.com</a>><br>Cc: <a \
href="mailto:klik-devel@kde.org">klik-devel@kde.org</a><br>Message-ID: <<a \
href="mailto:1167242011.4592b31beeb41@imp8-g19.free.fr"> \
1167242011.4592b31beeb41@imp8-g19.free.fr</a>><br>Content-Type: text/plain; \
charset=utf-8<br><br>Selon Alexey Eremenko <<a \
href="mailto:al4321@gmail.com">al4321@gmail.com</a>>:<br>> The standards OSes \
don't provide that functionality (even newest <br>> openSUSE 10.2 boxed \
version doesn't) !<br><br>I disagree, fuse is provided by default since 2.6.14. \
No need to install it on<br>SUSE 10.0 and 10.1 for example, and i guess for SUSE \
10.2.<br><br>> Possible solution: <br>> 1. "fork" the client to \
"fuseklik-client" which will be distro specific.<br>> NOTE: forking the \
client does NOT mean forking the project.<br><br>I you want to use fuseiso+fakechroot \
<br>even provide by default ... And if it works great, why not an \
inclusion<br>directly inside kde4 for example ?<br><br>There is no perfect \
solution.<br><br>Lionel<br><br><br>------------------------------<br><br>Message: 7 \
<br>Date: Wed, 27 Dec 2006 20:14:10 +0200<br>From: "Alexey Eremenko" <<a \
href="mailto:al4321@gmail.com">al4321@gmail.com</a>><br>Subject: Re: [klik-devel] \
The future direction of klik development<br>To: " <a \
href="mailto:lionel.tricon@free.fr">lionel.tricon@free.fr</a>" <<a \
href="mailto:lionel.tricon@free.fr">lionel.tricon@free.fr</a>><br>Cc: <a \
href="mailto:klik-devel@kde.org">klik-devel@kde.org</a><br>Message-ID: \
<br> <<a \
href="mailto:7fac565a0612271014y346ba527v56bb6b0812fa4f2e@mail.gmail.com">7fac565a0612271014y346ba527v56bb6b0812fa4f2e@mail.gmail.com</a>><br>Content-Type: \
text/plain; charset=UTF-8; format=flowed<br> <br>On 12/27/06, <a \
href="mailto:lionel.tricon@free.fr">lionel.tricon@free.fr</a> <<a \
href="mailto:lionel.tricon@free.fr">lionel.tricon@free.fr</a>> wrote:<br>> \
Selon Alexey Eremenko <<a href="mailto:al4321@gmail.com"> \
al4321@gmail.com</a>>:<br>> > The standards OSes don't provide that \
functionality (even newest<br>> > openSUSE 10.2 boxed version doesn't) \
!<br>><br>> I disagree, fuse is provided by default since 2.6.14. No need to \
install it on<br>> SUSE 10.0 and 10.1 for example, and i guess for SUSE \
10.2.<br>><br><br>Not true.<br>FUSE and kernel 2.6.14 is just the first part of \
the requirements.<br><br>There is second part of the requirements (the nasty part): \
<br><br>- fuse-devel (not provided with the standard 10.2 DVD, not in free,<br>not \
even in the boxed set)<br>- compiling patched fuse-iso<br>- compiling \
fakechroot<br><br>So while the kernel modules don't need to be compiled (thank \
god) we <br>still need compilation of some user-space utils.<br><br>-Alexey \
Eremenko<br><br><br>------------------------------<br><br>Message: 8<br>Date: Wed, 27 \
Dec 2006 20:45:38 +0100<br>From: <a href="mailto:lionel.tricon@free.fr"> \
lionel.tricon@free.fr</a><br>Subject: Re: [klik-devel] The future direction of klik \
development<br>To: Alexey Eremenko <<a \
href="mailto:al4321@gmail.com">al4321@gmail.com</a>><br>Cc: <a \
href="mailto:klik-devel@kde.org"> klik-devel@kde.org</a><br>Message-ID: <<a \
href="mailto:1167248738.4592cd627d1ec@imp6-g19.free.fr">1167248738.4592cd627d1ec@imp6-g19.free.fr</a>><br>Content-Type: \
text/plain; charset=ISO-8859-1<br><br>It seems difficult to ask to an end user to \
compile fuseiso and fakechroot. Some <br>user-space utility should be available in a \
binary version, for example a<br>klikutil package. That does not disturb me if you \
want to have a good<br>integration into the Desktop (kde, gnome or others) with \
cmg-thundnails etc ... <br><br>For fuse-devel, strange thing since it's available \
on<br><a href="http://download.opensuse.org/distribution/10.2/repo/oss/suse/i586/">http://download.opensuse.org/distribution/10.2/repo/oss/suse/i586/</a><br><br>
But the question is : is there an another solution ? Even with Plash, you \
will<br>need fuseiso so ...<br><br>Lionel<br><br>Selon Alexey Eremenko <<a \
href="mailto:al4321@gmail.com">al4321@gmail.com</a>>:<br>> Not true. <br>> \
FUSE and kernel 2.6.14 is just the first part of the requirements.<br>><br>> \
There is second part of the requirements (the nasty part):<br>><br>> - \
fuse-devel (not provided with the standard 10.2 DVD, not in free, <br>> not even \
in the boxed set)<br>> - compiling patched fuse-iso<br>> - compiling \
fakechroot<br>><br>> So while the kernel modules don't need to be compiled \
(thank god) we<br>> still need compilation of some user-space utils. \
<br>><br>> -Alexey \
Eremenko<br>><br><br><br><br><br>------------------------------<br><br>Message: \
9<br>Date: Thu, 28 Dec 2006 00:15:27 +0200<br>From: "Alexey Eremenko" \
<<a href="mailto:al4321@gmail.com"> al4321@gmail.com</a>><br>Subject: Re: \
[klik-devel] The future direction of klik development<br>To: <a \
href="mailto:klik-devel@kde.org">klik-devel@kde.org</a><br>Message-ID:<br> <<a \
href="mailto:7fac565a0612271415s79269063mb23ecc6da963c0d6@mail.gmail.com"> \
7fac565a0612271415s79269063mb23ecc6da963c0d6@mail.gmail.com</a>><br>Content-Type: \
text/plain; charset=UTF-8; format=flowed<br><br>> But the question is : is there \
an another solution ?<br><br>YES !!! there is - look at what I have proposed earlier \
- move forward <br>but stay compatible - i.e. make multiple clients that are \
compatible<br>at the image level (either cmg or app).<br><br>That is: for full klik \
experience, users will have to download the<br>"binary klik client", that \
includes full KDE and fuse integration. <br><br>But for the lazy people with \
non-major distros, that don't have<br>precompiled client, we will make available \
the "standard klik client",<br>bash based, running on old technology, \
loop-mount *but* with ability <br>to run the latest images. (that is: i recommend \
building minor update<br>to old klik-client to make it compatible with newer \
images.)<br><br>This will basically mean, that if we, for example will not provide \
a<br>binary fuseklik client for say, Fedora Core 7, users will be able to <br>run \
with the old bash klik client.<br><br>Users will have a choice which client is right \
for them.<br><br>-Alexey \
Eremenko.<br><br><br>------------------------------<br><br>Message: 10<br>Date: Thu, \
28 Dec 2006 00:11:06 +0100 <br>From: probono <<a \
href="mailto:probono@myrealbox.com">probono@myrealbox.com</a>><br>Subject: Re: \
[klik-devel] The future direction of klik development<br>To: <a \
href="mailto:klik-devel@kde.org">klik-devel@kde.org \
</a><br>Message-ID:<br> <<a \
href="mailto:85d71c370612271511j1312bb71kfe2e078bc675803f@mail.gmail.com">85d71c370612271511j1312bb71kfe2e078bc675803f@mail.gmail.com</a>><br>Content-Type: \
text/plain; charset=ISO-8859-1; format=flowed <br><br>> fuse-devel (not provided \
with the standard 10.2 DVD,<br>> not in free, not even in the boxed set)<br>> \
compiling patched fuse-iso<br>> compiling fakechroot<br><br>Why do you think the \
user has to compile those? <br>Wouldn't it be possible for the klik client to \
come bundled with these binaries?<br>Would there then be another requirement for FUSE \
besides a recent kernel?<br><br>Regards,<br>probono<br><br><br>------------------------------
<br><br>Message: 11<br>Date: Thu, 28 Dec 2006 01:47:50 +0200<br>From: "Alexey \
Eremenko" <<a \
href="mailto:al4321@gmail.com">al4321@gmail.com</a>><br>Subject: Re: [klik-devel] \
The future direction of klik development <br>To: <a \
href="mailto:klik-devel@kde.org">klik-devel@kde.org</a><br>Message-ID:<br> <<a \
href="mailto:7fac565a0612271547r7672297qfe93c8130f6e3b81@mail.gmail.com">7fac565a0612271547r7672297qfe93c8130f6e3b81@mail.gmail.com
</a>><br>Content-Type: text/plain; charset=UTF-8; format=flowed<br><br>On \
12/28/06, probono <<a \
href="mailto:probono@myrealbox.com">probono@myrealbox.com</a>> wrote:<br>> > \
fuse-devel (not provided with the standard 10.2 DVD,<br>> > not in free, not \
even in the boxed set)<br>> > compiling patched fuse-iso<br>> > compiling \
fakechroot<br>><br>> Why do you think the user has to compile those?<br>> \
Wouldn't it be possible for the klik client to come bundled with these binaries? \
<br>> Would there then be another requirement for FUSE besides a recent \
kernel?<br>><br><br>How stable are the binary interfaces ?<br>How stable is the \
FSH ?<br><br>I am not sure if single binary can run across RedHat, SUSE, Debian and \
Gentoo... <br>we can try - and run extensive testing - but providing \
cross-Linux<br>binaries is not easy.<br>Alternatively we can provide a script that \
compiles all the needed<br>stuff on the client's system (semi-)automatically. But \
I don't know if <br>this will be easier solution...<br><br>-Alexey \
Eremenko.<br><br><br>------------------------------<br><br>_______________________________________________<br>klik-devel \
mailing list<br><a href="mailto:klik-devel@kde.org"> klik-devel@kde.org</a><br><a \
href="https://mail.kde.org/mailman/listinfo/klik-devel">https://mail.kde.org/mailman/listinfo/klik-devel</a><br><br><br>End \
of klik-devel Digest, Vol 11, Issue 5<br>***************************************** \
<br></blockquote></div><br>
_______________________________________________
klik-devel mailing list
klik-devel@kde.org
https://mail.kde.org/mailman/listinfo/klik-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic