- Arch-dev-public - lists.archlinux.org

Re: [arch-dev-public] arch-dev-public, or am i just too dumb?
by Aaron Griffin 23 Jan '09

23 Jan '09

On Fri, Jan 23, 2009 at 10:41 AM, Jan Mette <jan.mette(a)berlin.de> wrote: > > Hi there, > > i have just tried it 4 times to respond to this thread: > > http://www.archlinux.org/pipermail/arch-dev-public/2009-January/010005.html > > Although i have registered today, i get only a "not open for public" message > that tells me i should respond to your mail address, so maybe i have no > sufficient rights to post something on this list... > > It would be very nice if you can forward my mail to the list. > > I am just a "mailing list procrastinator" and have almost no experience with > this stuff, sorry for bothering you and my dumbness :) Hey Jan, Typically what people do is reply to the message and change to address to arch-general to transfer the thread there. I've sent this on to the dev list anyway. Cheers, Aaron > --------------------------------------------------------------------------------------------------------------------- > >> Hey guys, >> >> providing splitted KDE packages is one of most wanted feature request sine >> there was KDE in Arch. And people have good reasons demanding it. Let's >> have a look at the problem: >> >> The KDE project does not provide source packages for every single >> application but they put them in some kind of categories. E.g. there are >> kdenetwork, kdemultimedia, kdegraphics etc.. So if you want an VNC client >> you have to install kdenetwork and you'll get an instant messanger, >> download manager, nvc server, samba client and others including their >> dependencies for free. >> >> ... >> >> After 4.2 will hit [extra] I'd like to work on this. This will also be a >> good test case for the makepkg implementation. >> >> ... >> >> My idea of splitting is to create one package for each app like kopete and >> not split by data, lib, docs etc.. Those packages will be members of a >> group; so pacamn -S kdenetwork still results in the same apps being >> installed. >> >> And last but not least: You might wonder why we not just include kdemod. I >> had a little talk with funkyou about this. KDEmod/Chakra has different >> goals and philosophy and is not really compatible with the Arch way. So >> they'd like to keep doing their own thing. >> >> Greetings, >> >> Pierre >> > > Hi there, > > At first: sorry for not responding to the original thread. I have just > registered on this ML, and i cannot reply to it... > > As you may know i am the so-called "lead developer" of KDEmod, although i dont > like those titles at all and all other people in our team seem to be much more > capable than myself - so this is just that you can recognize me ;) > > I have already talked to Pierre about the whole split stuff and want to add my > view about it, and also set the record straight on some points he mentioned. > > At first, the goals and philosophy of the KDE packages in extra and KDEmod are > not very different, both are (now) aiming for split KDE modules. I also told > Pierre that we can remove all of our backports from KDEmod (currently there is > just one small backported patch in our KDE 4.2 packages) and keep it clean. We > planned that anyway for the 4.2 version, as it is now completed enough to live > without those backports. > > From my point of view, there isnt a real difference in terms of goals and > philosophy... And when KDEmod is not compatible to the Arch way, what about > split KDE packages in extra? Are these conform to the Arch way then? If thats > the case, i would like to know why... As i see it, splitting up KDE in Arch > doesn't really conform to the Arch way anymore, at least as i understand > "...without unnecessary additions, modifications, or complications..." and > "...an elegant, minimalist approach..." > > Oh, and i never said that we would like to continue doing our own thing, just > to say that... We are absolutely open to make KDEmod more conform to Arch, and > thats exactly what i told Pierre. We have also just started to port KDEmod to > the new makepkg with split support, which we plan to use with the release of > 4.2.1... All in all, KDEmod is also a good testcase for the split support in > makepkg, and so far there have been no problems with it, good work :) > > There is some more stuff i would like to add here, basically my view about the > whole "split KDE packages in Archs extra repo" idea: > > 1. If you split up KDE in Arch, you will basically reinvent the wheel, > including all mistakes we did during the past ~2 years, which will also affect > the users of course. It will be the same learning effect that we had, repeated > by someone else - and splitting up KDE is not as trivial as it may seem. You > cannot do just one package per app for example. While this may work for > kdenetwork, most other KDE modules have shared components that need something > like a "-common" package, so this needs quite a lot of planning and testing. > To outline the needed efforts: With KDE 4.2 we just have reached a point where > we can say "ok, its really solid now", and that took a lot of time and efforts > (since KDE3, to be exact). > > 2. Choice is better than two competing projects. Currently, Arch has the > absolutely best selection of KDE packages available. We have KDE in extra, > KDEmod, KDEmod KDE 3 packages and of course Tanis repo and Markc's daily SVN > repo. The result of that is that users have a real choice... And from my > experience there are also a lot of users who dont like split KDE packages, but > just want the "plain default". > > 3. Our aim with KDEmod is to deliver a "high-class selection" of KDE packages, > which are both suitable for users and developers. There are quite some KDE > devs who are using our packages, because we are providing packaged debugging > symbols for example, and because we are not "tied to any rules" we are also > able to do weekly updates from the stable KDE branch and such stuff, which > makes bug-hunting a lot easier. > > 4. We are 8 people and several contributors (who test and give feedback) who > work on the KDEmod packages. This is a lot more manpower than it is available > for Archs KDE packages - and i can guarentee that doing split packages with > only 1-2 people is a lot of work, especially when it comes to testing > packages and packaging a new major release. > > 5. If KDE in extra will be split, there will be two competing package sets and > a lot of doubled efforts. This will maybe result in some confusion for the > users, and in the end no one really gains something from it. It will also be > more work for us, because we have to adapt our stuff to the changed KDE > packages in extra. > > Now, please dont misunderstand me here, but from my point of view the current > plans are not very well-grounded and need some more communication, as they > will lead to doubled efforts, confusion of users and of course a lot more > complexity for packagers (like us). (oops, i am repeating myself, sorry...) > > The two solutions i see are: > > 1. If people want split packages in Arch, we would be absolutely happy to make > KDEmod (more) conform to Arch and then put it into [extra]. Of course we would > also help maintaining it, if you guys accept people as devs who were not very > active "the official way" before :) Oh, and if that would be the case, we > would also need to discuss about makepkg support for -debug packages (i have > already ported the debug patch to the new makepkg with split support), as > these are quite a standard among distros and would attract a lot more people > who like to use Arch + KDE, but miss some important features. > > 2. We can just continue doing what we did before, let users decide what they > want to use and keep the choice. That would mean "standard" non-split KDE > packages in [extra] and of course KDEmod as an alternative, with some more > features and more agile developers who are not bound to any rules applying to > Arch. Also, the argument that there are just too much dependencies for KDE in > [extra] seem a bit like a personal thing of Pierre to me (no offence > intended). I mean, the KDE 4.2 packages in extra are missing 6 dependencies so > far, and these are really small and easy to add, and that doesnt justify > splitting up KDE from my point of view. > > I am quite unsure about which way to prefer, so i would like to read some > opinions about that from you guys... However, i am slightly tending to option > 2 = leave it like it is and let the users have their choice - of course with > some more collaborating between us and you guys... > > Greetings > > Jan (aka funkyou) >

2 1

[arch-dev-public] Preparing new mono release
by Daniel Isenmann 23 Jan '09

23 Jan '09

Hi, just a small note to the list. I'm preparing the update for the next mono release. I will do the necessary rebuilds (if there are any) of the affected packages. I don't think, that I will update it today/tonight, but it should be in the repo the next two or three days. See this mail just as a small information... :) Bye, Daniel

2 3

[arch-dev-public] Mplayer: switching to svn
by Hugo Doria 23 Jan '09

23 Jan '09

Hi guys, I was thinking in use the svn version of mplayer. The latest stable release is marked as outdated and has several security problems. Also, the official project recommends using svn version [1]. It is generally stable and works well. There is a problem with that? Should i change the name of the package for mplayer-svn or can I keep "mplayer"? [1] http://www.mplayerhq.hu/design7/dload.html -- Hugo

6 15

[arch-dev-public] new package: policykit-kde
by Pierre Schmitz 23 Jan '09

23 Jan '09

FYI: I have added policykit-kde to testing. It contains a frontend for policykit configuration and future application will make use of it. ATM it is distributed within extragear; but it will be part of KDE 4.3. (They had asked for integration just after the feature freeze ;-)) -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre(a)jabber.archlinux.de WWW http://www.archlinux.de

1 0

[arch-dev-public] phonon: gstreamer support will be dropped
by Pierre Schmitz 23 Jan '09

23 Jan '09

In short: I have tested several use cases and gstreamer seems not to be usable. So Id' like to disable support for it in upcoming phonon releases. My problems with gstreamer: * graphical glitches when playing some (most) mpeg files * sometimes no sound * bad image quality (no deinterlacing?) * plugins depend on gnome * it plays some videos with wrong aspect ratio * does not seem to be a phonon problem; I had the same problems with totem; using totem-xine fixed those. So, future versions of phonon will only have the xine-backend enabled. Maybe I'll provide other backends when we have the ability to split packages. If you think this is a bad idea, let me know. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre(a)jabber.archlinux.de WWW http://www.archlinux.de

5 5

[arch-dev-public] Integrity Check x86_64 23-01-2009
by repomaint＠archlinux.org 23 Jan '09

23 Jan '09

====================================== = Integrity Check i686 of core,extra = ====================================== Performing integrity checks... ==> parsing pkgbuilds ==> checking mismatches ==> checking archs ==> checking dependencies ==> checking makedepends ==> checking for circular dependencies Summary --------- Missing PKGBUILDs: 0 Invalid PKGBUILDs: 0 Mismatching PKGBUILD names: 0 Duplicate PKGBUILDs: 0 Invalid archs: 0 Missing (make)dependencies: 0 Repo hierarchy problems: 0 Circular dependencies: 0

1 0

[arch-dev-public] Integrity Check i686 23-01-2009
by repomaint＠archlinux.org 23 Jan '09

23 Jan '09

====================================== = Integrity Check i686 of core,extra = ====================================== Performing integrity checks... ==> parsing pkgbuilds ==> checking mismatches ==> checking archs ==> checking dependencies ==> checking makedepends ==> checking for circular dependencies Summary --------- Missing PKGBUILDs: 0 Invalid PKGBUILDs: 0 Mismatching PKGBUILD names: 0 Duplicate PKGBUILDs: 0 Invalid archs: 0 Missing (make)dependencies: 0 Repo hierarchy problems: 0 Circular dependencies: 0

1 0

[arch-dev-public] Divide and Konquer - Splitting KDE packages
by Pierre Schmitz 23 Jan '09

23 Jan '09

Hey guys, providing splitted KDE packages is one of most wanted feature request sine there was KDE in Arch. And people have good reasons demanding it. Let's have a look at the problem: The KDE project does not provide source packages for every single application but they put them in some kind of categories. E.g. there are kdenetwork, kdemultimedia, kdegraphics etc.. So if you want an VNC client you have to install kdenetwork and you'll get an instant messanger, download manager, nvc server, samba client and others including their dependencies for free. But there is hope: future versions of makepkg will be able to help splitting those packages in an easy way: http://dev.archlinux.org/~allan/makepkg- git.html In fact KDE ist already prepared to be splitted; all you need to do is running make install in the right directory. After 4.2 will hit [extra] I'd like to work on this. This will also be a good test case for the makepkg implementation. In addition to this we'll need to update our devtools and db-scripts to handle those packages right. extrapkg should be quite simple; archrelease and repo- add should work just fine; only the db-scripts will really fail because they cannot guess the svn-dir just from the package name anymore. My idea of splitting is to create one package for each app like kopete and not split by data, lib, docs etc.. Those packages will be members of a group; so pacamn -S kdenetwork still results in the same apps being installed. And last but not least: You might wonder why we not just include kdemod. I had a little talk with funkyou about this. KDEmod/Chakra has different goals and philosophy and is not really compatible with the Arch way. So they'd like to keep doing their own thing. Greetings, Pierre PS: I have attached a quick&dirty example to just show you that this would not increase complexity that much; indeed I think this makes things a lot cleaner. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre(a)jabber.archlinux.de WWW http://www.archlinux.de

3 9

[arch-dev-public] [new package] nouveau-drm / xf86-video-nouveau
by Andreas Radke 23 Jan '09

23 Jan '09

I'd like to bring in these packages in a slightly modified version from AUR to testing and later to extra repos. Both packages have a nice amount of votes in AUR. http://nouveau.freedesktop.org/wiki/ nouveau-drm provides a mesa/drm git version with new drm-nouveau code not yet implemented in the mainline kernel drm.ko. xf86-video-nouveau is the opensource Xorg driver under heavy developement. 2D support is stable using EXA and much faster than the "nv" driver developed by Nvidia company for Xorg. I'm running the xf86-video-nouveau driver in a DualHead configuration with RandR1.2 for some time now. It's stable and a good opensource alternative to the Nvidia closed one and to the slow and poor of features "nv" driver. 3D support is under development with Gallium3d and will show major changes as well as radeon/ati and intel driver do with K(ernel) M(ode) S(ettings). But that's something different and will happen past Xorg-Server 1.6 and Mesa7.3. Any objections moving in that open source driver for Nvidia cards? -Andy

3 8

[arch-dev-public] [signoff] mkinitcpio 0.5.22
by Aaron Griffin 22 Jan '09

22 Jan '09

This is a quick fix for FS#12867 http://bugs.archlinux.org/task/12867 The problem: mkinitcpio doesn't detect the USB modules properly when using the usbhid or usb hooks. Please test this ASAP as this can be a big deal, and it's a showstopper for the ISO. Cheers, Aaron

2 1