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

[arch-dev-public] [signoff] kernel26 2.6.28.2-1
by Tobias Powalowski 26 Jan '09

26 Jan '09

Hi guys, new kernel adresses the following things: - bump to latest version please signoff for both arches greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

5 4

[arch-dev-public] /usr/share/info/dir?
by Thomas Bächler 25 Jan '09

25 Jan '09

I don't know what this file is, but source-highlight contains /usr/share/info/dir, which existed in my filesystem but didn't belong to any package. Looks wrong to me ...

5 5

[arch-dev-public] [signoff] gcc{,-libs} 4.3.3-1
by Andreas Radke 25 Jan '09

25 Jan '09

a new compiler release. please signoff. (gcc-gcj should soon hit testing as well. still have to solve a minor build issue) -Andy

2 1

[arch-dev-public] [signoff] reiserfsprogs 3.6.21-1
by Andreas Radke 24 Jan '09

24 Jan '09

This is the first release after the Namesys company died (it seems). See: http://www.kernel.org/pub/linux/utils/fs/reiserfs/README please signoff. change below. -Andy Reiserfsprogs-3.6.21 Status: stable Comments: This contains changes made by Jeff Mahoney (everything got testing as a part of latest SuSE distros). 2009-01-09 3.6.21 release. 2009-01-09 Patches from Jeff Mahoney: - reiserfsprogs-mkreiserfs-quiet.diff - reiserfsprogs-large-block-warning.diff - reiserfsprogs-fsck-mapid.diff - reiserfsprogs-external-journal-changes.diff - reiserfsprogs-remove-stupid-fsck_sleep.diff - reiserfsprogs-mkfs-use-o_excl.diff - reiserfsprogs-enforce-block-limit.diff - reiserfsprogs-large-fs.diff - reiserfsprogs-better-fsck-a-behavior.diff - reiserfsprogs-remove-dependency-on-asm_unaligned.h.diff - reiserfsprogs-progress.diff - reiserfsprogs-reorder-libs.diff Patches from Ludwig Nussel: - mkreiserfs-set-the-owner-of-the-root-directory-to-the-calling-user.diff Patches from Edward Shishkin: - reiserfsprogs-disable-small-block.diff - reiserfsprogs-new-version.diff

1 2

[arch-dev-public] TODO list for namcap
by Hugo Doria 24 Jan '09

24 Jan '09

Hi guys, I made my first namcap module yesterday and i want to work more on this. Unfortunately i did not found any TODO list for it, so i want to hear from you guys: what you want to see on namcap? Any idea for a module or feature? -- Hugo

7 6

[arch-dev-public] [signoff] mkinitcpio 0.5.23
by Aaron Griffin 24 Jan '09

24 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. Added an additional underscore/dash related change since 0.5.22 For testing, please rebuild your mkinitcpio image with: $ mkinitcpio -p kernel26 And reboot. Please sign off as soon as you can. Cheers, Aaron

5 4

[arch-dev-public] KDE 4.2.0 in [testing]
by Pierre Schmitz 23 Jan '09

23 Jan '09

Hi everybody, today I uploaded the so called "first try" of 4.2 into [testing]. Those packages are not the final one yet, but damn close. There are only two known upstream showstoppers; which will be fixed by new packages soon. See http://bugs.kde.org/buglist.cgi?keywords=kde-4.2.0-blocker. On our site only mysql is blocking a release to [extra]: http://bugs.archlinux.org/task/12798 In addition to this kde-l10n-et seems broken. So please take the chance and check those packages. An update from 4.1 should be quite smooth. And even if you hated KDE 4.1, give 4.2 a try; it really rocks. :-) If you notice any regression, showstopper or problems during the update, please report them. Packages for x86_64 should be available on your favourite mirror soon; Andrea will build i66 packages tomorrow. Greetings, Pierre -- 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 1

[arch-dev-public] Firestarter obsolete
by tobias＠justdreams.de 23 Jan '09

23 Jan '09

Hi guys, a user(Sven-Hendrik Haase) brought to my attention that firestarter has issues (memleaks). Well there are apparently some patches available somewhere .... but - last release was Jan 29th, 2005 (yes that means 4 years) - there seems no activity in the project - it deals with iptables and the kernel (which has changed quite a bit over the last 4 years :P ) and is somewhat crucial to system security - in this state, I don't feel like fixing it(I don't maintain it anymore anyway) but I do consider it a security issue Proposal to fix: Let's get riddence of it. Opinions? -T

3 2

[arch-dev-public] [signoff] initscripts 2009.01
by Aaron Griffin 23 Jan '09

23 Jan '09

Shortlog: Aaron Griffin (6): Switch commented kdm path unset the TZ envvar in 'functions' chmod /var/run/utmp to 664 when creating Adjust minilogd's maximums Add some simple status display functions Adjust copyright year to 2009 Roman Kyrylych (1): Added missing slash I'd like to get this in core ASAP, as the copyright year change would be nice for the ISOs. Cheers, Aaron

3 3

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