[split] fbsplash & mkinitcpio

dtw · 2006-05-13 08:34:09

Erm..so where is the final version of the fbsplash hook and where do you want it to be installed by gensplashutils?

Actually, I have a better idea. This doesn't need to be included in gensplashutils at all, it's MUCH more to do with mkinitramfs than fbsplash, it just uses fbsplash. So why can't these optional hooks, which we don't want bloating the core mkinitramfs pkg (what ever we are calling it), each be in their own pkg with their own deps?

That way the hook for fbsplash can be maintained by the person maintaining the core pkg and it can depend, nice and simply, on gensplashutils. I'll probably never use this new system as I build custom kernels and keep it simple and I don't really want to bloat gensplashutils with stuff not everyone wants or needs.

If the optional hooks (usplash, fbsplash, suspend, etc) are pkg'ed separately with a nice config /etc/whathesaid.d then it's super modular. "But more pkgs", I hear some whine! Rubbish, look at Xorg, that's much better than it was and these pkgs would be tiny.

_Gandalf_ · 2006-05-14 02:22:58

Well that is not at all a solution dtw, someone installing gensplashutils will not actuall install for example another package mkinitcpio-fbsplash for example!!!
It's easy just take my files -> http://wael.nasreddine.com/trash/splashutils/ the fbsplash.install will go into /lib/initcpio/install/fbsplash and fbsplash.conf (in my case) will go into /etc/mkinitcpio.d/fbsplash (phrakture haven't implemented this feature yet but it's two lines to implement)
anyway u're gensplashutils maintainer u can put these 2 files in gensplashutils or u can make a new package and make gensplashutils depends on it but i don't find it a good solution myself

iphitus · 2006-05-14 05:17:51

aye. i know you're going to respond with 'choice' as you did on IM the other day, but there is no choice here.

We will 'force' all users to use mkinicpio over mkinitrd/mkinitramfs inevitably. Dont think of it as a seperate system, rather a new version of the old. pacman 3.0 rather than 2.9. Once mkinitcpio is out and replacing the others, there'll be no reason for using the other two anyway, mkinitcpio will be easier to use, will support all features, and will work much better.

Inclusion in gensplashutils is the best option here. There's no need to seperate it.

James

dtw · 2006-05-14 07:17:01

_Gandalf_ wrote:

Well that is not at all a solution dtw, someone installing gensplashutils will not actuall install for example another package mkinitcpio-fbsplash for example!!!

Why not? Xorg now requires you to install all sorts of pkgs but people manage it - this is Arch Linux, we expect people to have brains.

Aside from that you're taking a narrow view of the situation: we're not just talking about hooks for gensplash but for ALL optional features. Where will suspend2 hooks be installed from? Will they be included in hibernate-scripts? Also you're looking at the deps backwards, gensplashutils doesn't, and never will, depend on hooks for something that is essentially optional, regardless of the hopes the devs might have for ubiquituity (not a word). If mkinitcpio-fbsplash depended _on_ genplashutils and you were advised to install that for fbsplash support that would work just as well. You're catering to a situation where people already have gensplashutils installed but as time passes that number will tend to zero as new users replace current users.

You're being utterly short sighted.

iphitus · 2006-05-14 07:36:26

dtw wrote:

_Gandalf_ wrote:
Well that is not at all a solution dtw, someone installing gensplashutils will not actuall install for example another package mkinitcpio-fbsplash for example!!!
Why not? Xorg now requires you to install all sorts of pkgs but people manage it - this is Arch Linux, we expect people to have brains.

The Xorg developers released it modular, so that's the way that was best for the distro to go. The logic in my brain says the hook should be in gensplash utils. Would I be brainless if i installed gensplash utils and expected mkinitcpio to work?

Aside from that you're taking a narrow view of the situation: we're not just talking about hooks for gensplash but for ALL optional features. Where will suspend2 hooks be installed from? Will they be included in hibernate-scripts?

Yep.

Also you're looking at the deps backwards, gensplashutils doesn't, and never will, depend on hooks for something that is essentially optional, regardless of the hopes the devs might have for ubiquituity (not a word).

Um, no, it isnt optional. To use Arch's kernels, users will need to use mkinitcpio. mkinitramfs/mkinitrd will be removed from the repositories when their time is up. It's not some hope we have, it's something thats being implemented, just like mkinitrd was originally. Not sure whether you understand that...

As for custom users, they're doing things different from the way Arch does it, and we can't support everything the users do. That's like expecting us to support RPM's. Even then, i doubt they'll be crying about losing 2kb of disk space.

That's .00000136% of a 160gb hdd. Nothing. The pacman database entry for a seperate package would take up nearly as much.

If mkinitcpio-fbsplash depended _on_ genplashutils and you were advised to install that for fbsplash support that would work just as well. You're catering to a situation where people already have gensplashutils installed but as time passes that number will tend to zero as new users replace current users.
You're being utterly short sighted.

Users are going to have gensplashutils if they want fbsplash. Simple.

I think it's silly to provide a 2.3kb file in a seperate package. All fbsplash users will have gensplashutils, so it makes plenty of sense to include it in that.

James

_Gandalf_ · 2006-05-14 07:38:49

Well that is obviously wrong dtw, You'll know very well that Arch will have only one util to generate an initramfs image (initrd will non longer be used) so If i will use fbsplash and beyond kernel, what is the use to install gensplashutils then? if the required hook was not provided?? that's no longer optional we're talking about required! I understand your point of view about Xorg how JGC did split the whole stuff it's cool, but i know that when i pacman xorg, i don't manually pacman startx (the bin) for example, so it's not optional that is a must, so is the fbsplash hook, As for suspend2 hook that is in mkinitcpio already, it's called resume (will take care of both suspend (Software Suspend) and suspend2) Anyway i really don't understand the reason why u won't include it in the package, it's one file there plus it's needed

You are absolutely right about new users, even current users we're talking about Arch as u said, it's not ubuntu or some newbie-dedicated distro, but that doesn't mean the user must know about every package without leaving it to pacman to decide weather it's needed or not, I know and u know very well if the theme was not included in the image, the user will not see verbose/silent mods plus the COLS in /etc/rc.d/functions will be calculated wrong so when gensplash daemon starts it will look really ugly on startup, hope u got my point

brain0 · 2006-05-14 08:43:31

I don't see the problem here. fbsplash is a minor feature that a small percentage of users will use. As for me, I don't care whether it is included in fbsplashutils or in mkinitcpio, they are both valid solution and both don't hurt anyone. (Still, I the /etc/mkinitcpio.d/ idea is good and I thnink creating a separate package is nonsense)

I thought this thread was for discussing problems and bugs and testing cases for mkinitcpio, so please don't spam it with fbsplash flaming. It's a minor problem, so just pick one of the two solutions and be happy.

iphitus · 2006-05-14 08:57:23

ill just put it into gensplashutils when i move it to [extra]. problem solved

dtw · 2006-05-14 11:43:26

iphitus wrote:

Would I be brainless if i installed gensplash utils and expected mkinitcpio to work?

People install gensplashutils all the time and expect silent splash to work - is that case a case for combing the initscripts changes in gensplashutils? No.

iphitus wrote:

Aside from that you're taking a narrow view of the situation: we're not just talking about hooks for gensplash but for ALL optional features. Where will suspend2 hooks be installed from? Will they be included in hibernate-scripts?
Yep.

So now our pkgs are becoming increasingly specialized to the Arch developers whims and wants rather than sticking to the old "we'll leave it vanilla unless it breaks ethos"? Great. -1 for the future of Arch.

iphitus wrote:

Also you're looking at the deps backwards, gensplashutils doesn't, and never will, depend on hooks for something that is essentially optional, regardless of the hopes the devs might have for ubiquituity (not a word).
Um, no, it isnt optional. To use Arch's kernels

Ding ding ding ding ding ding - wake up call for James, not all of us use the Arch stock kernels:

http://bbs.archlinux.org/viewtopic.php? … ght=kernel

That's a healthy third of the voting population.

Not sure whether you understand that...

That's .00000136% of a 160gb hdd. Nothing. The pacman database entry for a seperate package would take up nearly as much.

Cool - we'll add arrogance and assumptions to ego

Users are going to have gensplashutils if they want fbsplash. Simple.
I think it's silly to provide a 2.3kb file in a seperate package. All fbsplash users will have gensplashutils, so it makes plenty of sense to include it in that.

Yeah _now_, as it currently stands, that might be the case. But as I said above your assumptions are based on current trends, your assuming gensplash is there first in the majority of cases and I am saying that that situation will only ever decrease as the user base grows.

Aside from that I fail to see what size has to do with it?! We have similar tiny pkgs already. the same logic can't be applied to combine them!

dtw · 2006-05-14 11:48:56

_Gandalf_ wrote:

Well that is obviously wrong dtw, You'll know very well that Arch will have only one util to generate an initramfs image (initrd will non longer be used) so If i will use fbsplash and beyond kernel, what is the use to install gensplashutils then? if the required hook was not provided?? that's no longer optional we're talking about required!

It will be useful to me - which is why I ported it to Arch in the first place as I don't use a stock kernel and haven't for years. Is everyone being deliberatley obtuse or just stupid?

Anyway i really don't understand the reason why u won't include it in the package, it's one file there plus it's needed

So the devs are AUTOMATICALLY right? We can't even have a discussion about it?

You are absolutely right about new users, even current users we're talking about Arch as u said, it's not ubuntu or some newbie-dedicated distro, but that doesn't mean the user must know about every package without leaving it to pacman to decide weather it's needed or not

Quite, that's why I didn't have loads of xorg stuff installed for about a week - I fail to see how it is different.

Aside from that you are all overlooking the fact that the system is already being flouted as being modular and with a seperate pkg it is easier to maintain.

dtw · 2006-05-14 11:56:24

iphitus wrote:

ill just put it into gensplashutils when i move it to [extra]. problem solved

You arrogant, selfish and inconsiderate *. After all the support I gave you for archck you'd just overide my wishes just like that to futher your own agenda? What a spirit of community.

Where the hell were you all 18 months ago when I put gensplash together from scratch and my requests for help and support where generally ignored by, well, everyone except a tiny few? Now all of a suddent it's fine for the dev team to steam-roller in and decide what's best with no regard at all? What's next? Will you arrest the whole port from me?

Aside from that we have only heard from one developer on this, iphitus, and I think I'd like to at least here a response from someone a little more "established". I think I deserve that much.

P.S. I understand that I am arguing based purely on a principle but Arch was also established on a set of principles so one could argue that we are here today because of principles. Therefore I'd appreciate some respect for that fact.

P.P.S. Simo, if you're reading this: ethics. Enough said.

[edit in bold]

iphitus · 2006-05-14 12:04:23

dtw wrote:

So now our pkgs are becoming increasingly specialized to the Arch developers whims and wants rather than sticking to the old "we'll leave it vanilla unless it breaks ethos"? Great. -1 for the future of Arch.

The mkinitcpio situation, is something that each distro has to do their own way. there is no standard vanilla solution to this. It's one the devs have to choose.

dtw wrote:

iphitus wrote:
Um, no, it isnt optional. To use Arch's kernels
Ding ding ding ding ding ding - wake up call for James, not all of us use the Arch stock kernels:
http://bbs.archlinux.org/viewtopic.php? … ght=kernel
That's .00000136% of a 160gb hdd. Nothing. The pacman database entry for a seperate package would take up nearly as much.
Cool - we'll add arrogance and assumptions to ego

Please at least be reasonable and quote me within context. I actually said:

iphitus wrote:

Um, no, it isnt optional. To use Arch's kernels, users will need to use mkinitcpio.

which has a very different meaning.

As for my %, I was bored, and would take any chance to pull out a calculator. I think i made a typo calculating it too...

Most custom kernel users would not be too concerned about 1 tiny little file on their system anyway. Some custom users use mkinitrd/ramfs too... and some more may well choose to use mkinitcpio when it's more complete, as it offers quite a nice setup with a range of options. Such as fbsplash when gensplashutils is installed!

dtw wrote:

Yeah _now_, as it currently stands, that might be the case. But as I said above your assumptions are based on current trends, your assuming gensplash is there first in the majority of cases and I am saying that that situation will only ever decrease as the user base grows.
Aside from that I fail to see what size has to do with it?! We have similar tiny pkgs already. the same logic can't be applied to combine them!

Like which packages? The assumption I make, is that gensplashutils will be there in every case a user wants to use fbsplash. It is not an unreasonable assumption. This assumption is correct, unless there is a drastic architectural change in fbsplash, which seems unlikely.

It's one file, those who need it will be greatful for it being there when they expect it to be there, those who dont need it, wont notice it, and probably couldnt care less about it being there. This isnt debian where we split every man file, include file, device file and temporary file into it's own package. A little bit of consolidation is good in moderation.

James

iphitus · 2006-05-14 12:11:13

dtw wrote:

iphitus wrote:
ill just put it into gensplashutils when i move it to [extra]. problem solved
You arrogant, selfish and inconsiderate *. After all the support I gave you for archck you'd just overide my wishes just like that to futher your own agenda? What a spirit of community.

Agenda? Please, look at what this is, it's one 2kb file. Settle.

Where the hell were you all 18 months ago when I put gensplash together from scratch and my requests for help and support where generally ignored by, well, everyone except a tiny few? Now all of a suddent it's fine for the dev team to steam-roller in and take over with no regard at all? What's next? Will you arrest the whole port from me?

So far I havn't steam rolled anything. I dont take peoples packages without their permission, I could, but i dont. You've heard me ask you more than once whether it's ok for me to move the package to [extra], and yet, I still havn't.

Don't forget, that the source in the package still points back to you, so thus, you still control it. All I would be doing is making your work, which you spent a great deal of time on, and we all appreciate that, more accessible. Hardly steamrolling and taking over with no regard.

Chill mate, dont take it personally, I'd rather this discussion is kept level rather than moved to the dust bin or hidden forum.

James

dtw · 2006-05-14 12:14:12

iphitus wrote:

dtw wrote:
iphitus wrote:
Um, no, it isnt optional. To use Arch's kernels
Ding ding ding ding ding ding - wake up call for James, not all of us use the Arch stock kernels:
http://bbs.archlinux.org/viewtopic.php? … ght=kernel
That's .00000136% of a 160gb hdd. Nothing. The pacman database entry for a seperate package would take up nearly as much.
Cool - we'll add arrogance and assumptions to ego
Please at least be reasonable and quote me within context.

I did. Your point was that to use Arch kernels you'll need mkinitcpio - My point, still, is that many people don't use them.

My other comment is aimed at your 160GB assumption - we don't all have that much space, even if the majority do. You can still cater to a majority without pissing off the minority.

iphitus · 2006-05-14 12:24:10

dtw wrote:

My other comment is aimed at your 160GB assumption - we don't all have that much space, even if the majority do. You can still cater to a majority without pissing off the minority.

Apologies. My point was the file is small, and is nothing on most hdd's. Even on a 1gb hdd, it's still next to nothing.

dtw · 2006-05-14 12:32:49

iphitus wrote:

Hardly steamrolling and taking over with no regard.

I edited that bit already as it was disgustingly unfair on you and I apologise for that. And please note the "with no regard" - that's the key part. I do appreciate the consideration that you described but lets be clear that it's absolutely no less than I would expect given my work on this project.

iphitus wrote:

Chill mate, dont take it personally

I do take it personally and if you were sitting where I am you'd take it personally too. So, yeah, I do take it personally and increasingly so.

I'd rather this discussion is kept level rather than moved to the dust bin or hidden forum.

Well, I'm the trainman here, I'm damn sure I won't be stoppped from having my say through the one medium I've worked on more than anyone else.

Back to topic. I admit we are arguing a very narrow toss. The arguements for and against are identical: it's tiny - it needs to be where people can get it easily. No-one has yet addressed the maintenance point but I'd also like to point out, just in case it is still not clear: any reason you chose as to why these hooks should _not_ go in mkinitcpio itself can also be applied in this case. gensplashutils has NOTHING to do with mkinitcpio and can be used completely seperately. Any statement to the contrary is just twisted logic.

Aside from that a 2kb hook in every pkg that is even related to mkinitcpio will add up.

As for tiny pkgs: any pkg that provides a single bash script, and there are plenty of those - would we consider combining them?

iphitus · 2006-05-14 12:38:21

dtw wrote:

Back to topic. I admit we are arguing a very narrow toss. The arguements for and against are identical: it's tiny - it needs to be where people can get it easily. No-one has yet addressed the maintenance point but I'd also like to point out, just in case it is still not clear: any reason you chose as to why these hooks should _not_ go in mkinitcpio itself can also be applied in this case. gensplashutils has NOTHING to do with mkinitcpio and can be used completely seperately. Any statement to the contrary is just twisted logic.

Let's twist that logic shall we? :twisted: :twisted:

this mkinitcpio hook has everything to do with fbsplash, and thus gensplashutils.

And from my perspective, I would expect gensplashutils to include all utilities neccesary to create a fbsplash capable initramfs under all systems. It already makes plain initramfs, so I don't see the harm in adding the support for mkinitcpio based initramfs to it too.

As for it going into mkinitcpio, it adds another layer to work through to make any changes, changes need to be sent to a dev to be added into it.

Let's see what others have to say.

James

dtw · 2006-05-14 13:04:57

iphitus wrote:

As for it going into mkinitcpio, it adds another layer to work through to make any changes, changes need to be sent to a dev to be added into it.

If you didn't adopted gensplash into [extra] how would it be any different? Because I must say my original arguements where based on me being the maintainer. I can't imagine the devs hope to adopt every optional aspect of mkinitcpio automatically. And also, just because gensplash _seems_ like a core "bonus" of mkinitcpio at the moment and so is getting dragged into a bigger picture - there is just something illogical and short sighted about that I can't put my finger on.

Maybe someone else will hit that nail for me.

_Gandalf_ · 2006-05-14 13:14:33

I still Agree with iphitus on this point, Okay i'm not a dev, nor a TU am just a plain user who expect to find tools already in my system wether I use a stock kernel or a customized one, Speaking of which, IF you'd say that including fbsplash.hook into gensplashutils is completely useless for custon (non mkinitcpio) users, I'd say including splash_geninitramfs is COMPLETELY useless for the kernel provided by arch which happens to be beyond, so will you split it into another package? what about bootsplash2fbsplash?? I never had or will have bootsplash installed on my system and i never convert a bootsplash theme, and the file is 4Kb will you also split it into another package?? got the point ??

Cerebral · 2006-05-14 15:17:30

Hm. Here's my take on things - we need to put this fbsplash hook for mkinitcpio somewhere. That's a given, it needs to be accessible. The options, as I see them, are as follows:

· include it right in mkinitcpio.
Problems: we want mkinitcpio to be modular, and so it really should be just a base package that these extra hooks can be eventually added onto. Also, everyone using stock kernels needs mkinitcpio; not all of them will want fbsplash.
Benefits: anyone who installs mkinitcpio will automatically have the hook, no extra work required.

· stick it in gensplashutils.
Problems: not everyone using gensplashutils will be using a stock arch kernel or mkinitcpio, and so they will have a random unneeded hook lying around.
Benefits: Anyone using fbsplash will need gensplashutils, so putting th e hook here implies everyone who needs it will have it available. Additionally, everyone who wants to use fbsplash needs to generate an initramfs somehow; some may still use mkinitcpio to do so. Is there some way that everyone could switch to the mkinitcpio system instead of... what is it... fbsplash-genititramfs or whatever it's called? Dunno.

· Make it's own package.
Problems: people won't 'automatically' have the hook when it's needed; they'll need to both know that the hook exists, then find it through pacman. This could be alleviated with properly worded install messages or comments in the mkinitcpio config.
Benefits: Essentially solves the problems associated with the first two possibilities. Also, as more hooks are created, we could have a group 'mkinitcpio-hooks' that contains them all for easy perusal.

So, there we have it, in a nutshell, the possibilities. Personally, I see 2 or 3 as the best of the options, and either could probably work out alright. I don't pesonally see the problem with putting the hook in gensplashutils, as to me that's just another 'utility' that some gensplash users might like to make use of, but I can understand some of dtw's points.

Wow, Arch has been an awfully heated discussion-ground lately.

dtw · 2006-05-14 17:11:45

Thanks, Cerebral, that clarifies things a lot

_Gandalf_: much of your counter arguement seems to totally disregard current Arch pkging practice - we don't make two or more pkgs from one source tarball.

Cerebral · 2006-05-14 18:09:15

dtw wrote:

Thanks, Cerebral, that clarifies things a lot

Heh, not a problem, I was trying to sort out what exactly was being discussed here myself, so that was as much a clarification for me as it was for anyone else.

we don't make two or more pkgs from one source tarball.

Well... we try not to. In some cases it's beneficial - see any kernel module packages (ati-fglrx, etc...).

However, I do agree that the counter-example didn't quite fit - gensplashutils contains utilities for gensplash. The two apps Gandalf mentioned are utilities for gensplash, so they naturally fit in the package. That'd be the same as taking all the localizations out of packages because I speak English.

Anyway, dtw, do you think there's a way that fbsplash-geninitramfs (or whatever it is) could be replaced or superceded by mkinitcpio + fbsplash.hook? I could see that as one solution... or is that script part of the actual gensplashutils source tarball?

dtw · 2006-05-14 18:37:58

Cerebral wrote:

Anyway, dtw, do you think there's a way that fbsplash-geninitramfs (or whatever it is) could be replaced or superceded by mkinitcpio + fbsplash.hook? I could see that as one solution... or is that script part of the actual gensplashutils source tarball?

It is. And the other thing: I think the dude who develops it is pretty prone to sudden and total changes of heart - I wouldn't bet gensplash stays the same indefinitely

phrakture · 2006-05-15 03:11:57

Oi vey, I just noticed this discussion. As the original creator of the new mkinitcpio stuff, I will tell you how these things were *meant* to be implemented.

The hooks for each package should be provided with package it depends on. Here's the rationale:

If I want gensplash, I install the package and get the hooks along with it. The reason being that, this is part of arch, and, while using given arch tools are not required, the support is. You don't install "gnome" and "gnome-profile.d-script" and "gdm-rc.d-script" and other arch-specific things. They are included. Scripts are trivial and, as iphitus stated, take less that 0.1% of disk space.

The point is that arch packages should support official arch tools, in official arch directories, and offical arch formats. If you want your package to be distro-agnostic, that's fine. The problem is that it's generally arch-specific.

When and if the gensplash stuff goes official, support for officially supported tools will have to be added. That's just the way it works. Modularity is great, to a point (see the gnome example above).

iBertus · 2006-05-15 04:15:13

/ puts on bullet-proof vest

Okay, so we've got two basic trains of thought here.
1) Not everyone will use the hook, so it should be modularized.
2) It's needed for mkinitcpio based gensplash to work, so it's needed for the offical Arch solution to work.

I've never really thought of Arch as a distro that "just worked" or that was supposed to "just work". I can think of several examples right now that don't always work when installed without extra packages (aspell, xorg7). That said, this file is 2KB in size, thus too small to matter. I would totally agree with dibble if the file were larger, but it sounds like the choice has already been made.

I do feel that the general rude behaviour and arrogant tones used by some in this thread have made any such discussion seem pointless. My point is that dibble has supported this project, built the gensplash utilities, and maintained the packages for awhile. He deserves credit and to be included in civilized discussion about the future of these packages.

Arch Linux

#1 2006-05-13 08:34:09

[split] fbsplash & mkinitcpio

#2 2006-05-14 02:22:58

Re: [split] fbsplash & mkinitcpio

#3 2006-05-14 05:17:51

Re: [split] fbsplash & mkinitcpio

#4 2006-05-14 07:17:01

Re: [split] fbsplash & mkinitcpio

#5 2006-05-14 07:36:26

Re: [split] fbsplash & mkinitcpio

#6 2006-05-14 07:38:49

Re: [split] fbsplash & mkinitcpio

#7 2006-05-14 08:43:31

Re: [split] fbsplash & mkinitcpio

#8 2006-05-14 08:57:23

Re: [split] fbsplash & mkinitcpio

#9 2006-05-14 11:43:26

Re: [split] fbsplash & mkinitcpio

#10 2006-05-14 11:48:56

Re: [split] fbsplash & mkinitcpio

#11 2006-05-14 11:56:24

Re: [split] fbsplash & mkinitcpio

#12 2006-05-14 12:04:23

Re: [split] fbsplash & mkinitcpio

#13 2006-05-14 12:11:13

Re: [split] fbsplash & mkinitcpio

#14 2006-05-14 12:14:12

Re: [split] fbsplash & mkinitcpio

#15 2006-05-14 12:24:10

Re: [split] fbsplash & mkinitcpio

#16 2006-05-14 12:32:49

Re: [split] fbsplash & mkinitcpio

#17 2006-05-14 12:38:21

Re: [split] fbsplash & mkinitcpio

#18 2006-05-14 13:04:57

Re: [split] fbsplash & mkinitcpio

#19 2006-05-14 13:14:33

Re: [split] fbsplash & mkinitcpio

#20 2006-05-14 15:17:30

Re: [split] fbsplash & mkinitcpio

#21 2006-05-14 17:11:45

Re: [split] fbsplash & mkinitcpio

#22 2006-05-14 18:09:15

Re: [split] fbsplash & mkinitcpio

#23 2006-05-14 18:37:58

Re: [split] fbsplash & mkinitcpio

#24 2006-05-15 03:11:57

Re: [split] fbsplash & mkinitcpio

#25 2006-05-15 04:15:13

Re: [split] fbsplash & mkinitcpio

Board footer