Page 5 of 19 « First 34 5 6715 Last »
Reply
Thread Tools
freemangordon is offline freemangordon
2016-11-14 , 16:59
Posts: 3,074 | Thanked: 12,960 times | Joined on Mar 2010 @ Sofia,Bulgaria
#41
Originally Posted by Android_808 View Post
I was thinking about this earlier. How do we manage the gtk2-dev/gtk3-dev dependency in the control file? The trouble with that is you could then end up trying to build with gtk2 headers and gtk3 hildon. Not sure if Debian control has a & option. If not it might be a case of dynamically generation the control file.
I am not sure I get it, however Depends has OR ("|") and commas are AND. Maybe I am missing something.

It will get a bit messy when it comes to libhildon and the rest of them because of the size of the code base compared to osso-* libraries.
I don't understand that, elaborate please.

The automake spaghetti is above me. I just took a guess based on a few quick google results. For the missing libraries, would it be useful to try using pkg-config to pull them in as needed?
I will fix it, if you explain what exactly is needed (besides moving config.h at the begining)


With regards to the Jessie port, osso-systemui is built. I had to go back to osso-af-utils and make a few hacks to anim-shower to bypass some outdated code. I'm not sure where/if the executable is used so it might come back to haunt me later.

Finally for today, upstart-dev. It doesn't exist in Debian, we have libupstart-dev. The Maemo version has dh_installxsession in it which is needed to finish building the rest of the osso-* pieces before I can install them. I need to look into how best to go about this, whether to just package the needed files
yeah, upstart - we have a problem there, upstream upstart no longer uses /etc/event.d, I am not sure how to tackle that.


I have to be totally honest, using Mer userland seems sooo much easier
Well, but the prise worths it IMO.
__________________
Never fear. I is here.

720p video support on N900,SmartReflex on N900,Keyboard and mouse support on N900
Nothing is impossible - Stable thumb2 on n900

Community SSU developer
kernel-power developer and maintainer
 

The Following 9 Users Say Thank You to freemangordon For This Useful Post:
Android_808 is offline Android_808
2016-11-14 , 23:58
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#42
With regards to AND and OR. How do you know that the libhildon that you have installed is using gtk2 or gtk3. Lets say that libhildon for gtk2 is called libhildon, as it is in Fremantle, and that for gtk3 we refer to it libhildon3. Now we want to build a package for Fremantle, so the control file needs libhildon-dev AND gtk2-dev as build-depends. Now we want to build for Jessie/Stretch we want libhildon3-dev AND gtk3-dev. So the question is can you have something like:

("libhildon-dev, gtk2-dev" | "libhildon3-dev, gtk3-dev").

Next up, the messy reference was in relation to the #ifdef for gtk3 in cssu packages. for the smaller osso libs, yeah it is only a few #ifdefs so thats fine. For hildon it could be lots of #ifdefs in every file.

the automake code I posted earlier does seem to fix the gtk3 support. If it still builds ok for Fremantle I would say thats ok to commit. Does the libcanberra error not appear for you with Fremantle? I don't have maemo-sdk set up on the machine doing the main porting otherwise I'd check it myself. I think the -ldl part might be down to newer toolchain, I seem to remember similar issues elsewhere.

finally, i'll look at upstart-dev, see what the dh_installxsession script does and trt to find some migration guides for event.d
 

The Following 6 Users Say Thank You to Android_808 For This Useful Post:
freemangordon is offline freemangordon
2016-11-15 , 07:51
Posts: 3,074 | Thanked: 12,960 times | Joined on Mar 2010 @ Sofia,Bulgaria
#43
Originally Posted by Android_808 View Post
With regards to AND and OR. How do you know that the libhildon that you have installed is using gtk2 or gtk3. Lets say that libhildon for gtk2 is called libhildon, as it is in Fremantle, and that for gtk3 we refer to it libhildon3. Now we want to build a package for Fremantle, so the control file needs libhildon-dev AND gtk2-dev as build-depends. Now we want to build for Jessie/Stretch we want libhildon3-dev AND gtk3-dev. So the question is can you have something like:

("libhildon-dev, gtk2-dev" | "libhildon3-dev, gtk3-dev").
Ah, I see now. Well, afaik we just do:

Build-Depends: libhildon-dev | libhildon3-dev, gtk2-dev | gtk3-dev

On Fremantle, we don't have libhildon3-dev, neither we have gtk3-dev, on Jessie (or any other modern distro), we don't have libhildon-dev

Also, I think it could look like:

Build-Depends: libhildon-dev | libhildon3-dev | gtk3-dev, gtk2-dev | gtk3-dev

In which case we will support builds on Fremantle, Jessie(etc) with libhildon3-dev and gtk3-dev installed and Jessie(etc) with only gtk3-dev installed. In that case to build with hildon3 support on Jessie, one must install libhildon3-dev "by hand" before doing apt-get build-dep $package

Next up, the messy reference was in relation to the #ifdef for gtk3 in cssu packages. for the smaller osso libs, yeah it is only a few #ifdefs so thats fine. For hildon it could be lots of #ifdefs in every file.
I meant using #ifdefs only where there will be only a couple of, for stuff like libhildon, hildon-desktop itself, etc, it should be a different branch/package (like you said ^^^ - libhildon3, for example). Abusing #ifdefs will definitely create a mess with nothing in return.

the automake code I posted earlier does seem to fix the gtk3 support. If it still builds ok for Fremantle I would say thats ok to commit. Does the libcanberra error not appear for you with Fremantle? I don't have maemo-sdk set up on the machine doing the main porting otherwise I'd check it myself. I think the -ldl part might be down to newer toolchain, I seem to remember similar issues elsewhere.
We have to decide whether we should support systemui builds without libhildon(whatever version). Initially I make that possible just to be able to test if it builds outside of scratchbox, on my devuan chroot where there is no libhildon at all (still ). I don't really think that building systemui without libhildon brings any benefit, so Build-Depends and configure.ac should be made in such a way, so to require the appropriate libhildon instead of libhildon or gtk3.

Also, https://github.com/community-ssu/oss...57a16d1408aR36 test should be removed as well and just use GLIB_VERSION macro around g_thread_init() call

Yes, I have SB installed and libcanberra is there by default, thus I missed that dependency. That should be fixed.

finally, i'll look at upstart-dev, see what the dh_installxsession script does and trt to find some migration guides for event.d
dh_installxsession copies stuff in /etc/XSession.d/. Now, it has a problem - see the first line of dh_installxsession That must be fixed, but in CSSU, not in a fork.
__________________
Never fear. I is here.

720p video support on N900,SmartReflex on N900,Keyboard and mouse support on N900
Nothing is impossible - Stable thumb2 on n900

Community SSU developer
kernel-power developer and maintainer
Last edited by freemangordon; 2016-11-15 at 07:58.
 

The Following 5 Users Say Thank You to freemangordon For This Useful Post:
Android_808 is offline Android_808
2016-11-15 , 10:08
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#44
Build-Depends: libhildon-dev | libhildon3-dev, gtk2-dev | gtk3-dev
At the moment my libs are still called libhildon, hence the issue is how does it know if its gtk2 or 3. I think it will have to be libhildon3 and install headers into /usr/include/hildon-3 or similar.

osso-systemui without hildon seems a bit pointless at the moment. AFAIK the main use is to dispatch requests from the system or user requests from Hildon UI. Should we look to replace hildon-desktop in the future with something else it would be worth while but not at the current point in time.

dh_installxsession copies stuff in /etc/XSession.d/. Now, it has a problem - see the first line of dh_installxsession That must be fixed, but in CSSU, not in a fork.
I suppose it was only ever designed with scratchbox in mind. For the time being what I've done locally is rename the affected file in osso-af-utils from debian/tmp-reaper to src/41tmp-reaper and put a reference to it in the install file. If it's gooed enough for Jessie's gnome files (debian/55gnome-session_gnomerc etc/X11/Xsession.d) it's good enough for me until a proper solution is found. Easiest is probably just going to be to split dh_* files from upstart-dev and depend on upstart-dev | maemo-dh-helpers.
 

The Following 5 Users Say Thank You to Android_808 For This Useful Post:
Android_808 is offline Android_808
2016-11-15 , 10:44
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#45
Apparently xset770 is used

Running xset770 -- the future of xset!
/etc/osso-af-init/real-af-startup: line 44: xset770: command not found
 

The Following 4 Users Say Thank You to Android_808 For This Useful Post:
freemangordon is offline freemangordon
2016-11-15 , 11:42
Posts: 3,074 | Thanked: 12,960 times | Joined on Mar 2010 @ Sofia,Bulgaria
#46
Originally Posted by Android_808 View Post
Apparently xset770 is used
shall I RE it?
__________________
Never fear. I is here.

720p video support on N900,SmartReflex on N900,Keyboard and mouse support on N900
Nothing is impossible - Stable thumb2 on n900

Community SSU developer
kernel-power developer and maintainer
 

The Following 5 Users Say Thank You to freemangordon For This Useful Post:
Android_808 is offline Android_808
2016-11-15 , 14:14
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#47
We have the source. It just requires an X11 lib that is no longer maintained as far as I can tell.

Libxsp0 is needed by xset770 in osso-af-utils, which is required by osso-af-startup, required by osso-app-killer, required by hildon-control-panel....phew. I don't know what the state of libxsp0 is in regards to building against current X11. http://wiki.maemo.org/Game_development states:
In order to get the package to build for now, I commented out the makefile info for the program so it didn't try to build it.

I do need to know what the situation is regarding files from nokia-binaries/non-free that don't actually have any binary content. In particular theme-default-settings (which provides theme-config). The file has no contents except a post install script to set up links to /usr/share/theme/default, setting default theme to alpha. The package does contain a copyright and given its nokia-binaries/non-free location I guess is not redistributable as-is?
Last edited by Android_808; 2016-11-15 at 14:20.
 

The Following 5 Users Say Thank You to Android_808 For This Useful Post:
freemangordon is offline freemangordon
2016-11-15 , 21:27
Posts: 3,074 | Thanked: 12,960 times | Joined on Mar 2010 @ Sofia,Bulgaria
#48
Originally Posted by Android_808 View Post
We have the source. It just requires an X11 lib that is no longer maintained as far as I can tell.



In order to get the package to build for now, I commented out the makefile info for the program so it didn't try to build it.

I do need to know what the situation is regarding files from nokia-binaries/non-free that don't actually have any binary content. In particular theme-default-settings (which provides theme-config). The file has no contents except a post install script to set up links to /usr/share/theme/default, setting default theme to alpha. The package does contain a copyright and given its nokia-binaries/non-free location I guess is not redistributable as-is?
Well, if we create source package and build binary package from it, I doubt there is any problem.
__________________
Never fear. I is here.

720p video support on N900,SmartReflex on N900,Keyboard and mouse support on N900
Nothing is impossible - Stable thumb2 on n900

Community SSU developer
kernel-power developer and maintainer
 

The Following 6 Users Say Thank You to freemangordon For This Useful Post:
Android_808 is offline Android_808
2016-11-15 , 23:50
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#49
it's one of a couple of packages i've found with literally no source code, no binary/library. the only contents are scipts within control.tar.gz, like post install. the funny/pointless thing is that a version seems to exist for each variant such mr0, 203, 204 etc...and all the ones i looked at were same. the idea i guess was in case there was say a vodafone specific version with a different default theme.

might be worth consolidating some of these style of packages at some stage to make defaults easier to locate.
 

The Following 6 Users Say Thank You to Android_808 For This Useful Post:
Android_808 is offline Android_808
2016-11-16 , 10:06
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#50
xset770...solved...I think.

Removed the xsp header from xset770.c and all mentions from Makefile.in and it still builds. Run sudo /etc/init.d/af-startup start and I don't get any errors relating to it.
 

The Following 7 Users Say Thank You to Android_808 For This Useful Post:
Reply
Page 5 of 19 « First 34 5 6715 Last »

« Previous Thread | Next Thread »
Thread Tools

 
Forum Jump


All times are GMT. The time now is 17:19.

Contact Us - Home - Archive - Top