**** BEGIN LOGGING AT Thu Nov 09 02:59:57 2006 Nov 09 04:52:02 eno: FYI: http://forum.linkstationwiki.net/index.php?action=vthread&forum=7&topic=1684#msg17121 Nov 09 05:43:50 rwhitby: thx for the link, linkstations seem interesting Nov 09 05:44:23 we're happy to host their specific feeds if they have developers to look after the linkstation specific issues Nov 09 05:44:35 (and hopefully we get more optware packages out of the deal) Nov 09 05:45:16 right Nov 09 05:45:36 i'm looking at the issue oleo mentioned Nov 09 05:46:04 imo, it's not as serious as it sounds Nov 09 05:46:19 the autoclean issue? Nov 09 05:46:29 right Nov 09 05:48:50 for package foo with foo.mk, there is impact only when there're ipks from the same foo.mk, and secondary ipk does not start with foo Nov 09 05:49:12 examples are perl.mk and modperl Nov 09 05:49:26 or buildroot.mk and uclibc Nov 09 05:49:40 s/modperl/microperl/ Nov 09 05:51:15 in which case, we can simply put them in separate bar.mk as workaround Nov 09 06:36:45 sounds good. Nov 09 06:37:55 i'm going to separate microperl, and i'd suggest oleo do the same for uclibc Nov 09 06:43:07 eno: here is a list of packages without .mk file: Nov 09 06:43:26 apache-manual, busybox-base, busybox-links, cups-doc-de, cups-doc-es, cups-doc, cyrus-imapd-devel, cyrus-imapd-doc, cyrus-sasl-libs, dspam-mysql, dspam-pgsql, findutils-doc, freeradius-doc, freeradius-doc package lacks control file creation Nov 09 06:43:28 imap-libs, microperl, openldap-libs, php-dev, php-embed, php-gd, php-imap, php-ldap, php-mbstring, php-mysql, php-pear, postfix-doc, sdl-dev, uclibc, wget-ssl Nov 09 06:43:46 not all of them need to have separate .mk file Nov 09 06:44:26 maybe. Nov 09 06:44:40 only those not started with foo- or foo_ Nov 09 06:45:03 so most don't Nov 09 06:45:21 foo being the name of the mk file Nov 09 06:46:04 aha. foo_* and foo-* are claned by master package. Nov 09 06:46:12 yes Nov 09 06:47:04 another difference is buildroot and uclibc does not use the same $(VERSION)-(IPK_VERSION) Nov 09 06:47:54 IPK+VERSION is th e sam. Just major differs. Nov 09 06:48:19 see optware-autoclean.pl line 172 Nov 09 06:49:42 I see now. Nov 09 06:51:24 This also means that change in slave packaging also requires master rebuild. Nov 09 06:52:12 which is rarely the case in the above packages Nov 09 06:54:44 OK. I accept this solution. Except that when looking in my buildroot package. I haven't find much thing to put it into uclibc.mk Nov 09 06:54:48 i mean the occasions of chaning slave packaging is fewer than the master packaging Nov 09 06:55:47 this means that I can just "touch make/uclibc.mk" when building buildroot.mk Nov 09 06:55:47 you can have all UCLIBC_* variables and uclibc- targets in uclibc.mk Nov 09 06:56:54 they are all included together anyway, conceptually some separation is good Nov 09 06:57:25 or maybe 'echo "# dummy package" > make/uclibc.mk"' Nov 09 06:57:46 i believe your list is not exaustive, i just generated a couple of py25-foo packages from py-foo.mk Nov 09 07:00:19 When I was looking how to separate monkey and bananna I saw that they could not live separated :) Nov 09 07:00:53 You cannot take out just bananna. Nov 09 07:02:10 well .mk file are not cages, it's all in your mind (monkey in one room, and banana in another) Nov 09 07:03:10 I will wait for microperl solution. Although the simplest solution may be perl-micro naming. Nov 09 07:13:04 microperl and perl are actually different packages built from the same source. On the other hand uclibc is just buildroot exctact. Nov 09 07:15:13 right, microperl & perl are two different builds Nov 09 07:16:52 it's up to you how much you want to put into uclibc.mk Nov 09 07:17:24 but i'm not in favor of build time uclibc.mk creation Nov 09 07:23:34 yes. It seems unpleasant jut to have empty uclibc.mk. It looks like bananna peels. Nov 09 07:30:12 UCLIBC_* variables and uclibc- targets belongs there, right? Nov 09 07:31:21 I am working on that. Nov 09 07:31:57 Except that I am in doubts if buildroot-source uclibc-source: $(DL_DIR)/$(BUILDROOT_SOURCE) $(BUILDROOT_PATCHES) Nov 09 07:32:20 should be written as buildroot-source $(DL_DIR)/$(BUILDROOT_SOURCE) $(BUILDROOT_PATCHES) and Nov 09 07:32:30 uclibc-source: $(DL_DIR)/$(BUILDROOT_SOURCE) $(BUILDROOT_PATCHES) Nov 09 07:32:51 Or to keep them together in buildroot.mk Nov 09 07:34:29 if you mark buildroot-* uclibc-* targets PHONY Nov 09 07:35:00 you can even have, "uclibc-source: buildroot-source" Nov 09 07:38:59 The question here is "What is elegant solution?" . No phony targets I think. Nov 09 07:42:46 these buildroot-* uclibc-* are .PHONY by definition Nov 09 07:43:05 right. Nov 09 07:45:23 I've decide just to move variables and uclibc-ipk: and $(UCLIBC_IPK): targets Nov 09 07:45:32 ~seen blaster8 Nov 09 07:45:56 blaster8 was last seen on IRC in channel #uclibc, 14h 23m 59s ago, saying: 'thanks'. Nov 09 07:46:20 03bzhou * r4420 10optware/trunk/make/ (microperl.mk perl.mk): split perl.mk into perl.mk & microperl.mk Nov 09 07:47:40 k, g'nite all Nov 09 07:48:45 This split actually could be good think, As I am planning OpenWRT packaging in buildroot. Nov 09 08:43:50 03oleo * r4421 10optware/trunk/make/ (buildroot.mk uclibc.mk): buildroot.mk split into buildroot.mk and uclibc.mk Nov 09 13:52:30 [g2]: ping. what phy did you choose on the loft? Nov 09 15:38:04 03bzhou * r4422 10optware/trunk/make/svn.mk: svn: upstream upgrade to 1.4.2 Nov 09 15:47:15 03bzhou * r4423 10optware/trunk/make/postgresql.mk: postgresql: upstream upgrade to 8.0.9 Nov 09 16:28:57 03bzhou * r4424 10optware/trunk/make/postgresql81.mk: postgresql81: upstream upgrade to 8.1.5 Nov 09 17:13:02 I can't find any specifics or "feature list" of what nslu2-utils provides.. do I NEED this package, because I can't get it installed on stable debian, even with apt-pinning Nov 09 18:31:53 03bzhou * r4425 10optware/trunk/make/nginx.mk: nginx: upstream upgrade to 0.4.12 Nov 09 19:52:51 03gda * r4426 10optware/trunk/make/kaffe.mk: kaffe: small fix, but it crashes anyway on the ds101g Nov 10 01:16:16 rwhitby: do you have a slug that is running openslug (trunk) handy ? I want to know whether you get a nice sounding beep with 'beep -f 440'. Nov 10 01:21:55 not now - a bit later yes. Nov 10 01:24:10 ok - thanks - I'm getting a strangled beep on my slug running Debian, and I'm not sure if it is something to do with the kernel or the hardware Nov 10 01:24:48 I'm going to load openslug 3.10b onto it to check because I get a nice beep on another slug that is currently running openslug 3.10b Nov 10 01:31:25 hi Nov 10 01:33:12 im trying to install the zd1211b moduls for openslug 3.10 beta, but when I compile them using the latest build it is compiling them agains the 2.6.18 kernel (while 3.10 uses the 2.6.16 kernel) I also cannot get the latest rootfs to work with the slug. Is there any way to get it to work, or to just update the new kernel without erasing the flash? **** ENDING LOGGING AT Fri Nov 10 02:59:56 2006