From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001
From: Nicolas Vigier <boklm@mageia.org>
Date: Sun, 14 Apr 2013 13:46:12 +0000
Subject: Add zarb MLs html archives

---
 zarb-ml/mageia-dev/2012-September/018673.html | 231 ++++++++++++++++++++++++++
 1 file changed, 231 insertions(+)
 create mode 100644 zarb-ml/mageia-dev/2012-September/018673.html

(limited to 'zarb-ml/mageia-dev/2012-September/018673.html')

diff --git a/zarb-ml/mageia-dev/2012-September/018673.html b/zarb-ml/mageia-dev/2012-September/018673.html
new file mode 100644
index 000000000..2a1f507f3
--- /dev/null
+++ b/zarb-ml/mageia-dev/2012-September/018673.html
@@ -0,0 +1,231 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+ <HEAD>
+   <TITLE> [Mageia-dev] unity on mageia
+   </TITLE>
+   <LINK REL="Index" HREF="index.html" >
+   <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20unity%20on%20mageia&In-Reply-To=%3CCAPVS_ccTw%3D2Rv6s6fJRit%3Dr6XJZum12ebxO82F%2Bk2xSTAAxEMA%40mail.gmail.com%3E">
+   <META NAME="robots" CONTENT="index,nofollow">
+   <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
+   <LINK REL="Previous"  HREF="018672.html">
+   <LINK REL="Next"  HREF="018678.html">
+ </HEAD>
+ <BODY BGCOLOR="#ffffff">
+   <H1>[Mageia-dev] unity on mageia</H1>
+    <B>Damian Ivanov</B> 
+    <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20unity%20on%20mageia&In-Reply-To=%3CCAPVS_ccTw%3D2Rv6s6fJRit%3Dr6XJZum12ebxO82F%2Bk2xSTAAxEMA%40mail.gmail.com%3E"
+       TITLE="[Mageia-dev] unity on mageia">damianatorrpm at gmail.com
+       </A><BR>
+    <I>Fri Sep 14 14:03:46 CEST 2012</I>
+    <P><UL>
+        <LI>Previous message: <A HREF="018672.html">[Mageia-dev] unity on mageia
+</A></li>
+        <LI>Next message: <A HREF="018678.html">[Mageia-dev] unity on mageia
+</A></li>
+         <LI> <B>Messages sorted by:</B> 
+              <a href="date.html#18673">[ date ]</a>
+              <a href="thread.html#18673">[ thread ]</a>
+              <a href="subject.html#18673">[ subject ]</a>
+              <a href="author.html#18673">[ author ]</a>
+         </LI>
+       </UL>
+    <HR>  
+<!--beginarticle-->
+<PRE>Hi Colin,
+
+Thanks for you're answer!
+
+&gt;<i> The &quot;Here is my PPA where I do x, y and z&quot; style approach to software
+</I>&gt;<i> repositories is always one we've deliberately avoided. It's creates
+</I>&gt;<i> significant problems for our (relatively) small teams when doing QA and
+</I>&gt;<i> addressing bug reports.
+</I>Agreed, I'm quite sure 90% of users use additional repos anyway, in
+Mageia this percentage is
+most likely lower than on Fedora and openSUSE (where you need 3rd
+party repos for mp3 and binary drivers)
+due to included multimedia, nvidia/ati stuff in nonfree and tainted,
+still Mageia users will want to install chrome, skype repos. In future
+they may want to have a steam repo, if Valve is cheerful. So one
+option would be to have unity repo as a 3rd party repo, where I
+understand it would be even worse for some people since it is
+tinkering with gtk2,gtk3 and few other packages. The other thing
+getting it in main Mageia repo would be much easier in OBS (will
+explain below).
+
+&gt;<i> This is Canonical's choice
+</I>&gt;<i> when they designed things this way. I'd rather see more upstream
+</I>&gt;<i> collaboration, and I'd personally want Mageia to encourage that general
+</I>&gt;<i> principle,  I don't like divergence and I favour collaboration.
+</I>I favour collaboration too, but the Canoncial actually tried there
+best for upstream collaboration.
+I reviewed some of the patches in gtk, gnome-control-center etc. Most
+have filed bugs upstream,
+e.g
+1. bug gnome-control-center to have an option in power to set an
+action for what happens when closing laptop lid
+including Canoncials patch =&gt; closed won't fix =&gt; irritating user with
+too much options
+2. gtk's appmenu =&gt; closed won't fix because Gmenu exists and gtk is
+designed for gnome-shell...,
+on Ubuntu both things work appmenu and Gmenu, on vanilla gtk only Gmenu,
+
+It's just people &quot;upstream&quot; even denying things that are optional.
+Actually Canoncials did the gtk2 and gtk3
+packages can be looked like a fork, but they choose to not have there
+own git/svn/bzr gtk3-ubuntu,
+but to patch the vanilla sources so it is easier to stay close to
+upstream and not going in different direction,
+where the code base would be un-revertable scattered across different
+projects (so IMO they did the community a favor).
+Would it be acceptable to have in the main repos gtk3 and gtk3-ubuntu
+(both providing gtk3, but conflicting)?
+The other thing I thought of, but I am not sure if we can actually do
+this, is having %dir/gtk3 and dir %dir/gtk3-ubuntu
+and libgtk3, libgtk3-ubuntu installed at the same time and being a
+choice by alternative chooser.
+
+&gt;<i> 3. Ignoring the above points and thinking more practically, would you
+</I>&gt;<i> propose to use the same specs for Fedora, OpenSuse and Mageia for the
+</I>&gt;<i> packages or would you use separate ones? If they are the same, then I suspect this would
+</I>&gt;<i> cause even more issues as the distros obviously diverge in their
+</I>&gt;<i> packaging structure.
+</I>Yes and no. Lot of the packages could be even with one spec file, the
+naming and dir structures
+are only a problem for few packages where distro specific rules
+differ, the most diff we actually have
+are the build time macros. In most packages that are not half-forks
+(e.g gtk is a half-fork) only 2-3 lines in the whole
+spec file differs. For these packages we have the following OBS strucutre:
+$Package (folder)
+==&gt;sources.tar.gz
+===&gt; a) %name-openSUSE_12.2.spec (or only %name.spec)
+===&gt; b) %name-Fedora_17.spec
+I made a script that keeps track of each packages spec's diff and on
+a whole repo's diff (
+<A HREF="https://build.opensuse.org/package/view_file?file=obsdiff&amp;package=0_TODOS_SCRIPTS_ETC&amp;project=GNOME%3AAyatana">https://build.opensuse.org/package/view_file?file=obsdiff&amp;package=0_TODOS_SCRIPTS_ETC&amp;project=GNOME%3AAyatana</A>
+) and we are trying to eliminate these few bits by collaborating with
+distros to get closer their macros. The Requires section is quite well
+working
+with pkgconfig.
+
+&gt;<i> 4. How do you handle automatic rebuilds when a package changes? e.g.
+</I>&gt;<i> when we change our official gtk, I presume you would want to
+</I>&gt;<i> automatically rebuild yours too? Also what if lower level things change,
+</I>&gt;<i> e.g. automated provides/requires extraction stuff provided at a lower
+</I>&gt;<i> level. I presume all this stuff &quot;just works&quot; in OBS?
+</I>Ok so here we come to our half-fork packages like gtk. Yes this just
+works on OBS for OBS based repos/distros/projects.
+We can branch openSUSE/gtk3 to Ayatana/gtk3 and we can optionally
+choose merge future changes from upstream, making it possible
+Ayatana/gtk3 to be just the openSUSE/gtk3 with Ayatana patches, if
+openSUSE/gtk3 adds a gtk3-omg-crash.patch our package will be rebuild
+too with our patches and this new patch. For Fedora we need to monitor
+it on our own since Fedora is not using OBS (partially with scripts
+notifying us).
+
+&gt;<i> 5. Regarding using OBS generally for Mageia, I would not personally be
+</I>&gt;<i> against it in principle, but there are lots and lots of barriers there.
+</I>&gt;<i> We do already have a working build infrastructure and we can control it
+</I>&gt;<i> and have experience of fixing, tweaking it etc. We know it's quirks.
+</I>&gt;<i> With OBS it would be like starting again. That's not to say it wouldn't
+</I>&gt;<i> be the &quot;right choice&quot;, but it could very easily not be the &quot;right choice
+</I>&gt;<i> right now&quot;. It would take the primary sysadmins to be really
+</I>&gt;<i> enthusiastic and keen on any transition and know exactly what benefits
+</I>&gt;<i> it would bring us. Although I can't speak for everyone, I just don't
+</I>&gt;<i> think there is enough in the way of resources right now for that to be
+</I>&gt;<i> the case.
+</I>Well what benefits would it bring.
+- Connection of instances, build.mageia.org can link/aggregate to
+packages at build.opensuse.org
+- Can autofetch from git/svn/bzr
+- Automatic rebuild
+- Webinterface
+- OBS is the most widely-used build system
+(openSUSE, SLES, Meego, Dell Community Repository, United States
+Postal Service, various universities and others)
+
+-It will be lot easier for packagers to maintain packages for various
+distributions (even when they are in the main
+  repo of these distribution).
+     ==&gt; Upload new version for package ==&gt; Change in spec's ==&gt;
+Create one push request per distro
+
+Sure there is &quot;never change a running system&quot;.
+What we could do is, for a soft beginning:
+1. get OBS build Mageia .rpm's
+2. get OBS run on Mageia as host (it is running already on centOS, so
+it is portable)
+3. use in parallel Mageias build structure and OBS (OBS can rsync
+Mageia source packages and rebuild them)
+   for a soft transition.
+
+PS: and well I would help, Adrian Schroeter, the man who does the most
+things for OBS may offer help too, as he offered it to Mandriva (see
+comments: <A HREF="http://blog.mandriva.com/en/2011/07/19/we-start-collecting-wishes-for-new-build-system/">http://blog.mandriva.com/en/2011/07/19/we-start-collecting-wishes-for-new-build-system/</A>
+)
+
+&gt;<i> 6. While I'm sure the web interface is nice, I presume it must link
+</I>&gt;<i> directly to a RCS in the background? e.g. we'd need it to hook into our
+</I>&gt;<i> subversion system right now. AFAIUI OBS had a some crazy custom RCS
+</I>&gt;<i> behind it. Is this now more generic? Can it hook up to subversion and/or
+</I>&gt;<i> git these days, how would it deal with user authentication?
+</I>OBS has a non-git/svn RCS (I don't think the default would change, but
+may a backend is possible).
+OBS's RCS works great with user authentication. Every project e.g on
+the obs instance build.mageia.org each project can have set different
+users set. e.g <A HREF="OBS://Mageia">OBS://Mageia</A> has 2 maintainers (only these are allowed
+to accept request and change the sources and delete or create new
+packages), 5 Bugowner	10 Reviewer 10 Downloaders	 5 Readers. It also
+support groups rather than users. Revision control is great, one
+command or 4 clicks in the WebUI to rollback to any revision with also
+the possibility to see the diff of each to each repository in the
+webui and directly browse sources of old revisions)
+
+Cheers,
+Damian
+</PRE>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+<!--endarticle-->
+    <HR>
+    <P><UL>
+        <!--threads-->
+	<LI>Previous message: <A HREF="018672.html">[Mageia-dev] unity on mageia
+</A></li>
+	<LI>Next message: <A HREF="018678.html">[Mageia-dev] unity on mageia
+</A></li>
+         <LI> <B>Messages sorted by:</B> 
+              <a href="date.html#18673">[ date ]</a>
+              <a href="thread.html#18673">[ thread ]</a>
+              <a href="subject.html#18673">[ subject ]</a>
+              <a href="author.html#18673">[ author ]</a>
+         </LI>
+       </UL>
+
+<hr>
+<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev
+mailing list</a><br>
+</body></html>
-- 
cgit v1.2.1