[03:05] <Whippet> hi all
[03:06] <Whippet> wondering if anyone could help me with cairo-dock?
[03:06] <Whippet> it installed ok, but will not launch
[03:07] <Whippet> using ubuntu 8.04
[03:07] <Whippet> installed by launching the cairo-dock*.deb and cairo-dock-plug-ins*.deb
[03:08] <Whippet> files show up in right places
[03:08] <Whippet> but /usr/bin/cairo-dock wont launch
[03:08] <Whippet> says it's there but no launchy :-(
[03:09] <Whippet> specific error msg. is Failed to execute child process "cairo-dock" (No such file or directory)
[03:10] <Whippet> which is puzzling as the files and directories exist and the cairo-dock is marked as executable
[03:10] <Whippet> any help would be appreciated
[04:50] <DShepherd> does anyone else find the tracker-applet notification icons not very intuitive?
[06:55] <dholbach> good morning
[09:37] <huats> moring everyone
[10:01] <seb128> pochu: did you read my reply to your comment about the gtk-vnc update?
[10:03] <pochu> seb128: yeah, I'll look at them
[10:03] <seb128> thanks
[10:04] <pochu> soren: gtk-vnc is a sync for Intrepid, right?
[10:04] <seb128> let me know if you need some testing, etc
[10:04] <pochu> thanks
[10:05] <soren> pochu: AFAIR, yes.
[10:05] <pochu> from the changelog it looks like ;)
[10:08] <pochu> soren: it adds a new binary package, mozilla-gtk-vnc (--enable-plugin=yes), is that ok?
[10:09] <soren> pochu: For intrepid? Sure, sure.
[10:09] <soren> I looking forward to that one, actually :)
[10:11] <pochu> heh
[10:11] <pochu> seb128: can you sync gtk-vnc for Intrepid?
[10:11] <seb128> yes
[10:14] <pochu> good morning slomo_!
[10:18] <seb128> pitti: the pending sru code seems to pick upstream bug numbers too, it doesn't use Launchpad-Bugs-Fixed?
[10:19] <pitti> seb128: it only looks at the actual changelog
[10:19] <pitti> seb128: I started with parsing for LP: #1234
[10:19] <pitti> seb128: but that didn't catch a lot of mis-formatted bug numbers
[10:19] <seb128> hum
[10:19] <pitti> so I made it more flexible
[10:19] <seb128> pitti: looks at the evolution bugs list for example
[10:19] <pitti> of course that means getting false positives, but that's better than not showing all LP bugs IMHO
[10:20] <seb128> ok
[10:20] <seb128> I should clean the upstream numbers next time then
[10:20] <pitti> hehe, yea
[10:20] <pitti> seb128: no, please keep them, they are useful
[10:20] <pitti> seb128: it's quite clear that those are upstream #, not LP #
[10:20] <seb128> ok
[10:20] <pitti> seb128: well, I have started to reject packages with invalid changelogs (missing bug #), etc.
[10:21] <pitti> if we become consequent with that, I can make the parsing stricter again
[10:21] <seb128> I was not sure if you were aiming at "all green" on this list before copying to updates or something
[10:21] <pitti> seb128: oh, no; only the LP ones
[10:21] <seb128> ok, as long as you can figure which ones are lp or not that's fine I guess ;-)
[10:22] <pitti> once we hit the 3xxxxxx range, it becomes harder, of course
[10:22] <pitti> I try to train myself to not be forgiving about wrong SRU changelogs now
[10:27] <mantiena> hi all
[10:27] <mantiena> Is this channel correct place to ask about strange behaviour of hal and policy-kit ?
[10:28] <mantiena> ﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿or it's better to ask at ubuntu-devel ?
[10:32] <mantiena> ﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿anyone here?
[10:33] <seb128> hi mantiena, you can always ask
[10:33] <mantiena> seb128: :)
[10:34] <mantiena> ﻿so, question is - why policy-kit doesn't allow to upgrade hal package in chroot ?
[10:34] <mantiena> ﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿root@linux-desktop:/# dpkg --configure -a
[10:34] <mantiena> Setting up hal (0.5.11~rc2-1ubuntu8) ...
[10:34] <mantiena>  * Reloading system message bus config...                                [ OK ]
[10:34] <mantiena> polkit-read-auth-helper: needs to be setgid polkituser
[10:34] <mantiena> polkit-auth: NotAuthorizedToReadAuthorizationsForOtherUsers: uid 0 is not authorized to read authorizations for uid 111 (requires org.freedesktop.policykit.read)
[10:35] <mantiena> ﻿﻿I've found which hal.postinst line couses this message:
[10:36] <mantiena> ﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿# Allow hal to query the PolicyKit database to enforce privileges
[10:36] <mantiena>   if ! /usr/bin/polkit-auth --user haldaemon --explicit | grep -q 'org.freedesktop.policykit.read'; then
[10:36] <mantiena>       /usr/bin/polkit-auth --user haldaemon --grant 'org.freedesktop.policykit.read'
[10:36] <mantiena>   fi
[10:36] <mantiena> So, is it bug in hal package or bug in policy-kit ?
[10:41] <pochu> seb128, soren: gtk-vnc uploaded and built at https://edge.launchpad.net/~pochu/+archive, with the 3 fixes.
[10:41] <soren> pochu: Awesome!
[10:42] <pochu> seb128: I'll ask for testing in the 3 bug reports
[10:42] <seb128> ok, thanks
[10:42] <pochu> wait
[10:42] <seb128> pochu: it's not listed there yet, maybe you need to remove the 0.3.5 candidate?
[10:42] <pochu> right, I just got a rejected mail
[10:43] <pochu> anyway, it built fine on my desktop ;)
[10:45] <pochu> bah I guess it will take some time for the ppa to remove the package...
[10:45] <seb128> should not
[10:46] <soren> Er.. Yes.
[10:46] <soren> It's done by a nightly cron job.
[10:46] <pochu> I thought that was already fixed, but looks like not
[10:46] <soren> At least it used to be.
[10:46] <pochu> at least it's dissapeared from the UI but it's still at http://ppa.launchpad.net/pochu/ubuntu/pool/main/g/gtk-vnc/
[10:47] <pochu> so I guess a new upload will be rejected again
[10:47] <pochu> seb128, soren: anyway, I've put the diff.gz & .dsc at http://emilio.pozuelo.org/~deb/, you know where to get the orig from ;)
[10:47] <seb128> ah ok
[10:47] <pochu> feel free to play with it :)
[10:47] <seb128> pochu: can you attach the debdiff to one of the bugs rather?
[10:47] <pochu> ah, sure
[10:47] <seb128> pochu: that's what is required for a sure anyway
[10:48] <seb128> s/sure/sru
[10:50] <pochu> seb128: attached at bug 206227
[10:50] <seb128> pochu: thanks
[10:51] <pochu> anytime
[10:51] <pochu> bbl
[10:51] <seb128> see you later
[10:51] <seb128> soren: want to give it a try and do the sponsoring?
[10:52] <soren> seb128: I won't get around to it today, then.
[10:52] <soren> seb128: I can do it tomorrow or the next day.
[10:52] <seb128> soren: well, no hurry, before 8.04.1 would be nice though ;-)
[10:53] <soren> I think I can manage that :)
[10:57] <seb128> thanks
[12:01] <mantiena> seb128: so, could you tell me anything about hal updating problem? It appreard when I upgrading hal from hardy-updates...
[12:05] <seb128> no
[12:06] <seb128> I've no clue about this one
[12:13] <mantiena> pitti: maybe I should talk with you about hal updating problems ?
[12:13] <pitti> mantiena: sure
[12:35] <mantiena> pitti: should I repeat my lines or you can look at the history of this channel (I've post 2 hours ago) ?
[12:35] <pitti> mantiena: I have scrollback, give me another 5 mins
[12:36] <pitti> (I'd like to finish my current task)
[12:37] <mantiena> ok
[12:38] <pitti> mantiena: oh, hal in a chroot? I guess that will break in more than one way
[12:38] <pitti> mantiena: do you have policykit running in the chroot?
[12:39] <mantiena> pitti: I don't think so, but in any case - I think there should be a way to upgrade hal package in chroot
[12:40] <mantiena> pitti: I'm remastering Ubuntu LiveCD and wanna have to update latest packages
[12:41] <pitti> mantiena: does it help to stop the 'outside' hal and policykit, and restart the ones in the chroot?
[12:41] <mantiena> pitti: I can try, didn't this break my internet connection or something ?
[12:42] <pitti> yes, it might (network-manager)
[12:42] <pitti> I don't see a way how to sensibly run two hals on the same machine at the same time
[12:42] <mantiena> pitti: but I don't need to run hal inside chroot, I just need to update hal package
[12:42] <pitti> mantiena: oh
[12:43] <pitti> mantiena: using policy-rc.d might help then, but it'll proably stumble over the polkit-auth call
[12:44] <mantiena> ﻿﻿﻿﻿﻿﻿﻿﻿I've found which hal.postinst line couses this message:
[12:44] <mantiena> ﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿# Allow hal to query the PolicyKit database to enforce privileges
[12:44] <mantiena>   if ! /usr/bin/polkit-auth --user haldaemon --explicit | grep -q 'org.freedesktop.policykit.read'; then
[12:44] <mantiena>       /usr/bin/polkit-auth --user haldaemon --grant 'org.freedesktop.policykit.read'
[12:44] <mantiena>   fi
[12:45] <mantiena> ﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿are these lines needed for upgrading hal package ?
[12:45]  * mantiena is not policy-kit guru ...
[12:45] <pitti> mantiena: actually only for the first installation
[12:46] <pitti> so those could be wrapped into
[12:46] <pitti> if [ -z "$2" ]; then
[12:47] <mantiena> pitti: so, should I report a bug against hal package ?
[12:47] <mantiena> :)
[12:47] <asac> pitti:
[12:47] <asac> merging country code en
[12:47] <asac> merging country code es
[12:47] <asac> merging country code pt
[12:47] <asac> merging country code zh
[12:47] <asac> i guess for those few it makes sense to manually upload lang packs?
[12:48] <pitti> mantiena: no need to, I just fixed it in trunk: http://bazaar.launchpad.net/~ubuntu-core-dev/hal/ubuntu/revision/235
[12:48]  * pitti hugs asac
[12:49] <pitti> asac: yes, I think so; that should be done in the update packages
[12:49] <asac> pitti: update package? will that work?
[12:50] <pitti> asac: you need to update them anyway, since version(base) == version(update) ATM, and base version X depends on update version >= X
[12:50] <pitti> asac: so you can as well put them into the updates only (they Replaces: -base)
[12:50] <asac> yes ... i thought ill punch the new tarballs in base and upload update with bumpbed depends
[12:51] <asac> pitti: ok i see .. problem is that in en we have "en" + "en_GB" ... i would like to remove "en" from that
[12:51] <pochu> seb128, soren: gtk-vnc is now in my ppa in the correct version (the debdiff remains the same): https://edge.launchpad.net/~pochu/+archive
[12:51] <mantiena> pitti: oh, you don't wanna increase my karma in launchpad ....
[12:51] <asac> i think its not important.
[12:51] <asac> so i can go for update package only
[12:51] <seb128> pochu: cool, thanks
[12:51] <pitti> mantiena: heh; if you insist, you can file it anyway :)
[12:51] <pitti> mantiena: (or if you need it for tracking purposes)
[12:52] <pitti> asac: I agree; fewer packages to touch, and testing this scenario is good anyway (it's supposed to work)
[12:52] <pitti> asac: scenario> update packages providing newer translations than -base
[12:52]  * mantiena wanna to become ubuntu member, see https://wiki.ubuntu.com/MantasKriaučiūnas
[12:53] <mantiena> pitti: maybe you wanna write testmonial into my wiki page ?
[12:53] <mantiena> ;)
[12:53] <asac> pitti: ok fine. how about moving things to language-support when 3.0 RC1 comes out. people kick me all the time :/
[12:53] <pitti> asac: to language-*support*? heck, we just got rid of that?
[12:54] <asac> pitti: err, no idea how the package is called. i mean move it from -gnome- to a common package
[12:55] <pitti> asac: ah, I see; if Riddell is ok with that, sure
[12:55] <asac> pitti: ok, ill talk into him :)
[12:55] <asac> anyway ... i am doing the langpack updates as discussed for now
[12:56] <pitti> asac: great
[12:59] <mantiena> pitti: so, what about your testmonial into my wiki page ? ;)
[13:38] <asac> pitti: all three packs in bug 222673 are waiting for approval i guess
[13:43] <pitti> mantiena: what do you mean?
[13:43] <pitti> asac: great, so it worked correctly? (replacing files, etc.)
[13:44] <asac> pitti: for me the result looks ok. there are no conflicts when installing and the problems are fixed
[13:46] <pitti> cool
[13:46] <asac> pitti: all files replaced are identical to the ones in -base ... so i cannot check that easily if he replace worked properly
[13:47] <asac> but i hope that dpkg still works :)
[13:47] <asac> at least the new files are now in there ... and thats what i wanted
[13:47] <pitti> processing
[13:50] <pitti> asac: accepted; so what did you change in the po2xpi scripts now? can we roll this out to rookery as well?
[13:51] <asac> pitti: i produced it on rookery
[13:51] <pitti> asac: ah, so there's just one language tarball now? awesome
[13:51]  * pitti hugs asac
[13:52] <asac> so its already rolled there ... i added merge logic to the mozilla-rosetta/rosetta_xpi_to_sources script
[13:52] <pitti> asac: I'll check the next set of automatic PPA updates then
[13:52] <pitti> ah, I see
[13:53] <asac> pitti: you run daily PPA updates?
[13:53] <pitti> asac: twice a week, rather
[13:53] <asac> just note that for the next few days the .po files for firefox and xulrunner are bogus because a fix landed in launchpad and we have to reimport translations
[13:54] <pitti> oh, good to know
[13:54] <pitti> asac: I was planning to copy the PPA to -proposed next Monday
[13:54] <asac> ill let you know once everything is fine again
[13:54] <pitti> but then I'll hold off
[13:54] <pitti> thanks
[13:54] <asac> yeah ... i just got to know about this today
[13:54] <asac> but jtv is on it
[13:56] <asac> but there is good news ... the xulrunner-1.9 update triggered the auto import this time. so at least that appears to work finally now
[14:04] <pochu> seb128: hey, could you sync gstreamer0.10 for Intrepid?
[14:04] <pochu> slomo_: ^^
[14:04] <slomo_> :)
[14:04] <pochu> \o/
[14:04] <pochu> yah for the GStreamer stuck in sync with Debian!
[14:05] <seb128> "stuck"?
[14:05] <pochu> err, stack :)
[14:05] <seb128> ah ;-)
[14:05] <seb128> what was the change there? the symlink upgrade cdbs thing?
[14:06] <pochu> slomo_: what would you think if I find a new contributor willing to learn and do merges? you have a lot to do and I don't think I'll be able to take care of all of them as I did when Hardy opened
[14:06] <pochu> seb128: yup
[14:06] <pochu> and this one
[14:06] <pochu>       debian/libgstreamer.symbols:
[14:06] <pochu>       + Don't use the binary registry for now, too intrusive change for
[14:06] <pochu>         hardy and we'll switch after release.
[14:06] <seb128> synced
[14:06] <seb128> ok
[14:06] <pochu> thanks!
[14:06] <ember> heya
[14:08] <asac> pochu: you have a list of merges you would like to give away?
[14:08] <asac> pochu: i have someone in mozillateam who needs more on his list for MOTU application :) (jazzva)
[14:10] <seb128> pochu, slomo_: do you know if some of the gstreamer updates are bug fix versions we should consider for hardy updates?
[15:09] <pochu> asac: I have tracker and liferea, feel free to ask him to give them
[15:10] <asac> pochu: ok ill ask once he shows up
[15:27] <mantiena> pitti: I mean than you could recommend me :) I'm good bugreporter :)
[15:35] <mantiena> pitti: or you could mention me at least in http://bazaar.launchpad.net/~ubuntu-core-dev/hal/ubuntu/revision/235 :)
[15:35]  * mantiena wanna to become ubuntu member, so, I need to document my contributions to Ubuntu, see https://wiki.ubuntu.com/MantasKriaučiūnas
[15:39] <pitti> mantiena: aah, I see
[15:39] <mantiena> pitti: btw, maybe we need to forbid hal to query the PolicyKit database to enforce privileges in hal.postrm if ﻿﻿﻿﻿﻿we "allow hal to query the PolicyKit database to enforce privileges" in hal.postinst ?
[15:40] <pitti> mantiena: I'll put a blob on your page
[15:43] <mantiena> pitti: thanks
[15:53] <hggdh> seb128: good morning
[15:53] <seb128> hello hggdh
[15:53] <seb128> hggdh: so the cpu issue seems to be due to the e-a-n run?
[15:54] <hggdh> seb128: yes, it seems so. I sort of expected that, but we still do not know why
[15:54] <seb128> no
[15:54] <seb128> I'm pondering dropping the autostart desktop if upstream doesn't respond to the issue
[15:54] <hggdh> a bypass is to take out e-a-n from the suto start-up, but this would break notifications everywhere
[15:54] <hggdh> s/suto/auto/
[15:54] <seb128> well, we added it for this reason
[15:55] <seb128> I've the impression upstream doesn't care a lot about non evolution users
[15:55] <hggdh> now that I am home, I will set up one system I have to try to get it
[15:55] <seb128> or rather they use evolution so they don't miss notifications because it has not been started
[15:55] <hggdh> I agree -- chats I had upstream... they tell me to get more data,
[15:55] <hggdh> but we have gotten a lot of data already
[15:56] <seb128> right, I'm wondering what exactly they want now
[15:56] <seb128> we got debug stacktrace, strace logs, we know it's triggered for users not using evolution
[15:56] <hggdh> interesting is that only Ubuntu seems to have been hit so far
[15:56] <hggdh> it is triggered for evo users also
[15:56] <seb128> well, the autostart desktop is an ubuntu patch
[15:56] <hggdh> ah
[15:56] <seb128> so not so surprising
[15:57] <seb128> upstream relies on evolution being started and running e-a-n
[15:57] <hggdh> ah... so there!
[15:57] <seb128> who do you speak to about this issue upstream usually?
[15:58] <hggdh> anyone online, mchra, mbarnes, srag
[15:58] <seb128> ok
[15:58] <hggdh> AFAIR mbarnes and mchra were the last
[15:59] <hggdh> now one thing I do not understand: if e-a-n is used elsewhere in Gnome, why isn't e-a-n autostarted on every distro?
[16:00] <hggdh> also, what would happen is we autostarted e-d-s before e-a-n?
[16:05] <seb128> hggdh: other distros get no calendar notifications until somebody starts evolution
[16:06] <hggdh> seb128: so... either Gnome sports (and announces) calendar notifications, or officially drops this to only Evo users
[16:08] <seb128> well, that's something GNOME should look at fixing yes
[16:08] <seb128> hggdh: starting e-a-n before e-d-s causes no issue on my box, e-d-s is just autospawned as it should
[16:09] <seb128> hggdh: I just tried several evolution --force-shutdown && /usr/lib/evolution/2.22/evolution-alarm-notify
[16:16] <hggdh> seb128: I have been trying also, and never got it -- but, then, all I had was linux64
[16:16] <hggdh> seb128: this is why I want to install hardy32 on one of my machines
[16:17] <hggdh> my hunch of being related to one single CPU did not pan out :-(
[16:17] <seb128> I'm using only 32 bit installs
[16:17] <hggdh> darn! another hunch goes down the drain!
[16:18] <seb128> I don't think it's so low level issue
[16:18] <mantiena> ﻿﻿﻿﻿﻿/me wonders why pitti wanna put Binary Large OBject (BLOB) on my page...﻿﻿﻿
[16:18] <seb128> must be a race somewhere in the e-d-s code
[16:18] <hggdh> what is weird is that some users have it occasionally, and others almost always (secretlondon, for example)
[16:18] <seb128> races can be weird ;-)
[16:18] <hggdh> yeah
[16:19] <hggdh> on one of the loops all that I could see were very fast poll () -- like glib got lost
[16:20] <hggdh> and continuous poll() with a timeout of zero would indeed cause some CPU use
[16:20] <seb128> right
[16:21] <hggdh> now this is why I still think it is related to glib -- applications do not have that low access to poll, or g_hash_*
[16:24] <seb128> that's weird that nothing else trigger the issue if that's a glib bug
[16:25] <hggdh> I also agree. Must be something on how e-a-n starts up. But the e-a-n code is quite simple, and looks very much (to my ignorant eyes) like a standard glib usage
[16:26] <hggdh> so we go back to e-a-n and e-d-s iteraction -- and, still, glib
[16:27] <hggdh> because glib is the glue between both
[17:43] <pochu> ember: feel free to ping me if you need sponsorship for your exaile merge ;)
[17:51] <pochu> ember: or if you can't do it, let me know, I'll find some new contributor willing to do it! :)
[17:51] <pochu> there's people on ubuntu-motu-mentors asking for merges so should be trivial
[17:52] <pochu> ^-- that's for everybody in the channel, if you don't want to do your merges... although you will have to help the new contributor if he has issues with it ;)
[17:52] <ember> yeah i think you can give that merge to one of those people
[17:52] <ember> i'm waiting till i get a chroot of intrepid created (because of perl bug)
[17:53] <pochu> ah, ok
[17:54] <pochu> well actually I have requested some syncs without test-building them, but this soon in the cycle I don't think that's very important... as they built in Debian and the auto-syncer doesn't test-build them prior to sync packages :)
[17:55] <pochu> and I don't think I'm the only one here ;)
[17:55] <pochu> actually cdbs seems to be uninstallable in the buildds
[17:57] <ember> if nobody looks for exaile i can do it later at night
[17:59] <ember> but you can sync evolution-rss
[17:59] <ember> :p
[19:42] <doul_doul> Hello !
[19:43] <doul_doul> Can you help me about gDesklets (is #ubuntu-desktop the good channel ?)
[19:43] <doul_doul> I would like to put a desklet always on top
[19:44] <doul_doul> is anybody here ?
[19:46] <andreasn> doul_doul: you can try #ubuntu , this is a development channel
[19:46] <andreasn> I have no idea how to do it myself
[19:52] <doul_doul> okay, thank you
[19:57] <mantiena> pitti: ﻿May I expect your blob on my ubuntu wiki page, which you mentioned at 17:40:54 ?
[20:21] <mpt> Ugh, it's pretty annoying that the Screen Resolution window doesn't fit in 640x480
[20:28] <seb128> mpt: because other applications do fit nicely on that? ;-)
[20:28] <mpt> seb128, I'm testing applications that don't, and it would be nice to be able to use the mouse to go back to my normal resolution afterwards :-)
[20:29] <mpt> (testing, and providing design fixes for)
[20:31] <seb128> mpt: I was just reading bug #224229
[20:33] <mpt> seb128, +1 to Bryce's comments
[20:33] <mpt> The "Detect Displays" button taking up as much room as it does is ridiculous
[20:34] <mpt> GTK should refuse to make any button more than 250% the width of its label ;-)
[20:34] <andreasn> mpt: did the Brasero bug where it asked if you wanted to set it as default get solved?
[20:35] <mpt> andreasn, according to the Bugzilla comment yes. I haven't confirmed it myself.
[20:35] <seb128> mpt: I'm not sure those will be enough to get it fitting on screen though
[20:35] <seb128> mpt: you would like better an non expansed button there?
[20:36] <seb128> that would look weird no?
[20:36] <andreasn> mpt: I just noticed evolution throws up a pretty similar icky dialog, so I wanted to check that it was technically possible to insert "Current Application X"
[20:36] <mpt> seb128, sure, it would look weird either way, which is a clue that it's in the wrong place
[20:36] <mpt> andreasn, I'd be (pleasantly) surprised if the Brasero peeps had implemented that detail
[20:37] <cody-somerville> gicmo, looks like we're room mates in Prague.
[20:37] <seb128> mpt: still, I'm not sure it's possible to make GNOME works correctly on 640x480, and who is used that on normal installations anyway?
[20:37] <andreasn> mpt: right
[20:37] <mpt> seb128, people with subnotebooks
[20:37] <mpt> like that eeeeeeeeeeeeeeeeeeepc
[20:38] <seb128> mpt: I wrote "normal" on purpose, mobiles are a different target and have adapted interfaces
[20:38] <mpt> subnotebooks != mobiles