Re: [MeeGo-dev] ubuntu 11.10
On Fri, Oct 14, 2011 at 12:16 AM, nic...@nicoladefilippo.it wrote: > Hi, > when thel support for kubuntu 11.10 ? This question makes no sense, therefore, nobody can answer you. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?
On Sat, Oct 1, 2011 at 8:49 AM, Gabriel Beddingfield wrote: > On Sat, Oct 1, 2011 at 10:20 AM, Michael Hasselmann > wrote: >> On Sat, 2011-10-01 at 10:13 -0500, Gabriel Beddingfield wrote: >>> With Intel removing the lion's share of those developer resources... >>> it would be foolish to continue that failed approach. It sets >>> everyone up for failure. >> >> I feel as if you over-estimate Intel's software development efforts for >> MeeGo. > > Well... MeeGo loses Auke... and that's pretty darn big IMHO. :-) > > I'm not going to bicker over head count or even quality. You wanna > support 5 verticals, go ahead. Make us all proud. I think it's a > plan for failure. > > > I'm all talk. At this moment, and for the past few months, I can't > commit any time to MeeGo (or even Tizen). But I really dig MeeGo for > several reasons... mostly the native/Qt API's... so I hope(d) to see > it succeed as a main-stream mobile OS. > Heh, I'm honored to be missed already, but, I'm not exactly gone just yet. Personally, I have about as many unanswered questions as anyone out there, which is partially why I haven't chimed in to any of the discussions recently. The other reason is that I've been on a 2-week vacation :-) As what this means to MeeGo, I'm not entirely sure and I've been asking questions. We most definitely have customers that will be getting part of my time to support their current MeeGo products, so meego.com isn't about to disappear. What exactly it means for the long run, and especially for the community, unfortunately I don't know either. See also the post from Stefano earlier. I've been asking the same questions as everyone else. If I get answers back that I can share, I most certainly will. For now, I'd like to ask everyone to submit questions to Dawn Foster, and keep asking. Answers will come - be patient. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] uxlaunch.log is empty
in newer versions, uxlaunch logs to syslog instead. Auke On Fri, Sep 9, 2011 at 2:50 AM, pingwei...@cs2c.com.cn wrote: > hi, guys, > > no content in my uxlaunch.log, how to fix this problem? > ___ > 伍平伟 > 9032 > 移动终端事业部 > > > > ___ > MeeGo-dev mailing list > MeeGo-dev@meego.com > http://lists.meego.com/listinfo/meego-dev > http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Is this a reliable way for app to know it's running on MeeGo Tablet vs. Netbook?
On Sun, Aug 28, 2011 at 9:58 PM, Niels Mayer wrote:
> In order for a package to run reasonably on both netbook and tablet
> UX's, is the following Qt C++ a good way of determining whether an
> application is running on MeeGo Netbook or Tablet?
This is a very debatable topic. Especially using preprocessor symbols
might not be the right thing, it's quite likely that other people will
just turn those on in order to make a piece of software work on
another platform
A better approach is to look at the device itself. Does it have a
102key keyboard? Then it's a laptop, desktop or netbook. Touch screen?
Then it's not a netbook or at least a hybrid, and the touch model
applies.
Using random files on disk sounds bad too, why not just parse
/etc/meego-release?
Ultimately, if you need 100% coverage, you need to read /etc/boardname
and maintain a mapping table of all 'boards' out there.
Auke
>
> +#ifdef Q_WS_MAEMO_5
> + isMeegoTablet = false; // NPM
> +#elif defined(MEEGO_EDITION_HARMATTAN)
> + isMeegoTablet = false;
> +#elif defined(Q_WS_X11)
> + /* NPM: package 'tablet-target-config' is in the Tablet KS
> +
> http://ftp-nyc.osuosl.org/pub/meego/builds/1.2.0.90/1.2.0.90.12.20110809.2/images/meego-tablet-ia32-pinetrail/meego-tablet-ia32-pinetrail-1.2.0.90.12.20110809.2.packages
> + but not in
> +
> http://ftp-nyc.osuosl.org/pub/meego/builds/1.2.0.90/1.2.0.90.12.20110809.2/images/meego-netbook-ia32/meego-netbook-ia32-1.2.0.90.12.20110809.2.packages
> + Package 'tablet-target-config' contains a single file
> /usr/share/meegotouch/targets/tablet.conf
> + if present, then assume we're on MeeGo tablet UX.
> + */
> + if (QFile::exists("/usr/share/meegotouch/targets/tablet.conf"))
> + isMeegoTablet = true;
> + else
> + isMeegoTablet = false;
> +#else
> + isMeegoTablet = false; // NPM
> +#endif
>
> The idea is that this ultimately sets a property
> 'Controller.isMeegoTablet' accessible from QML so that code does
> different things on difft platforms:
>
> onButtonClicked: {
> if (Controller.isMeegoTablet) { //NPM
> mainWindow.fullScreen =
> !(mainWindow.fullScreen);
> mainWindow.pageUsingFullScreen =
> !(mainWindow.pageUsingFullScreen);
> }
> else if (!Controller.isMaemo) {
> Controller.toggleState();
> }
> else {
> Controller.minimize();
> }
>
> Niels
> http://nielsmayer.com
>
> PS: The code works :-) And successfully invokes the tablet-UX "window
> framing" versus the netbook-UX. and associated different behaviors for
> the "full-screen" button on the app. For details,
> " svn checkout http://ytd-meego.googlecode.com/svn/trunk/playground/qmltube/ "
> " qtcreator qmltube/qmltube.pro "
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
> http://wiki.meego.com/Mailing_list_guidelines
>
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] meego OBS down again... Without Warning?
On Sat, Aug 6, 2011 at 3:52 AM, Brendan Le Foll wrote: > On 30 July 2011 13:11, David Greaves wrote: >> As mentioned last week (after the outage the week before): >> http://lists.meego.com/pipermail/meego-packaging/2011-July/247843.html >> >> There was no reply to that message but the OBS did return shortly after. > > Another weekend, same problem. This is now the 4th in a row. Still no > response I must admit that I'm starting to become frustrated by this myself as well - this is the second weekend for me where I was planning to do something and on friday night there already is breakage. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [Meego-kernel] at90usbkey sample firmware (HID mouse) / touch-screen
2011/7/25 weihua.zhang : > Hello, > > I've just acquired an Atom tablet PC with a touchscreen. The > screen appear to be a USB HID device, showing up in lsusb as > > Bus 001 Device 006: ID 03eb:201c Atmel Corp. at90usbkey sample > firmware (HID mouse) > > meego-1.2 install: > 1、wget > http://repo.meego.com/MeeGo/releases/1.2.0/builddata/image-configs/tablet-ia32-oaktrail.ks > 2、mic-image-creator --config=tablet-ia32-oaktrail.ks --format=livecd > --cache=mycache > > boot -> uxlaunch -> the desktop > the cursor moves around, but clicks are obstructed; > Click or double-click does not work. so you have a touchscreen device, but it registers itself as mouse? where are the left-click and right-click button on your touchscreen? Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] missing dist-upgrade path on major releases
On Tue, Jul 19, 2011 at 2:54 AM, Stefan Kost wrote: > Hi, > > On 07/18/11 17:58, Kok, Auke-jan H wrote: >> On Mon, Jul 18, 2011 at 6:38 AM, Stefan Kost wrote: >>> hi, >>> >>> there is a long standing bug >>> https://bugs.meego.com/show_bug.cgi?id=9205 >>> regarding a missing upgrade path for new major releases. Why does MeeGo >>> want to be special here (technical/legal/other issue)? I'd really like >>> to know, the current status is quite embarrassing. >>> >>> Is there a practical intermediate solution available? Like installing >>> all updates and then updating the repositories to change the 1.1. to 1.2 >>> in the repo url and running a dist-upgrade?. Has anyone tried that? >> We're working on bringing solutions in the long term. >> >> The focus for 1.3 will be on utilizing the btrfs features we can >> easily enable: Device reset (factory reset) will be possible, and the >> shell installer will be able to install into a new btrfs subvolume on >> an existing installation - effectively saving all your data (and >> potentially even your OLD os install as well as a bonus). >> >> Doing a in-place OS upgrade is probably something we'll not work on, >> as there are too many risks involved. "zypper dup" works good, but, >> the nature of rpm updates outside the tested update path is almost >> always guaranteed to give problems. >> >> Auke > What are the problems in particular you see here. I am running an (rpm > based) opensuse installation on my home computer, which I upgraded since > version 6.2. I know that it can cause issues, but in that case one could > still reinstall. So far I have been always able to resolve the conflicts. for instance, doing a zypper dup from rpm-4.8 to rpm-4.9 - this will leave your update broken midway and it's unlikely even more experienced people will recover. other issues: sysvinit -> systemd. util-linux-ng -> util-linux etc... Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Does MeeGo 1.3 support xHCI driver for USB 3.0?
On Mon, Jul 18, 2011 at 6:43 PM, Li, Hao H wrote: > Hi, > > Does MeeGo 1.3 support xHCI driver for USB 3.0? According to build.meego.com, the Trunk kernel-adaptation-pinetrail currently has this driver disabled: See: http://build.meego.com/package/view_file?file=config-generic&package=kernel-adaptation-pinetrail&project=Trunk&srcmd5=31a61c5542a6fdc9345f17fc050ed48d -> # CONFIG_USB_XHCI_HCD is not set If you require USB3.0 for your hardware, you should consider filing a feature request to have this enabled. Alternatively, you can compile a kernel with this enabled yourself as well. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] missing dist-upgrade path on major releases
On Mon, Jul 18, 2011 at 12:19 PM, Igor Stoppa wrote: > Hi, > On 18/07/11 18:58, Kok, Auke-jan H wrote: > >> The focus for 1.3 will be on utilizing the btrfs features we can >> easily enable: Device reset (factory reset) will be possible, and the >> shell installer will be able to install into a new btrfs subvolume on >> an existing installation - effectively saving all your data (and >> potentially even your OLD os install as well as a bonus). > > Depending on the type of product targeted, rolling back to older sw version > might be undesirable. > It's typical for embedded devices for pirates to try to rollback to older SW > versions to exploit known security flaws. > Example: subsidized simlocked phone, DRM - not the rendering thingy =) Vendors have the option of replacing and/or disabling this functionality, so, no issue there. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] missing dist-upgrade path on major releases
On Mon, Jul 18, 2011 at 6:38 AM, Stefan Kost wrote: > hi, > > there is a long standing bug > https://bugs.meego.com/show_bug.cgi?id=9205 > regarding a missing upgrade path for new major releases. Why does MeeGo > want to be special here (technical/legal/other issue)? I'd really like > to know, the current status is quite embarrassing. > > Is there a practical intermediate solution available? Like installing > all updates and then updating the repositories to change the 1.1. to 1.2 > in the repo url and running a dist-upgrade?. Has anyone tried that? We're working on bringing solutions in the long term. The focus for 1.3 will be on utilizing the btrfs features we can easily enable: Device reset (factory reset) will be possible, and the shell installer will be able to install into a new btrfs subvolume on an existing installation - effectively saving all your data (and potentially even your OLD os install as well as a bonus). Doing a in-place OS upgrade is probably something we'll not work on, as there are too many risks involved. "zypper dup" works good, but, the nature of rpm updates outside the tested update path is almost always guaranteed to give problems. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Meego sill alive ?
On Fri, Jul 15, 2011 at 9:12 PM, David Boosalis wrote: > Hi All > > I keep checking back on Meego to see what ,if any, momentum is building. > Today I fired up my meego netbook which has 1.2 to see how many updates > were available. The answer was zero, the same answer since it came out in > June. I then checked to see if the Meego SDK would install on to Ubuntu > 11.4, Then answer was no. So then I decided to see what is going on with > this Meego mailing list, I see it is getting about 10 email s a week - > hardly a thriving community. > > Is Meego dead ? If not then why so little activity with it. I would hardly call hundreds of people working on it dead. However, given the tone of your message, I think I'm just wasting my time replying though... Try following the links here to some of the many lists: http://wiki.meego.com/Community_communication perhaps the list of commits of this month interest you: http://lists.meego.com/pipermail/meego-commits/2011-July/thread.html that's 700 changes in about 2 weeks yeah, we're taking it easy alright ;) Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Using old IVI home on MeeGo 1.2.0 and uxlaunch keeps getting called
On Fri, Jul 15, 2011 at 9:25 AM, Foster, Susan B wrote: > I went back and did a clean install of MeeGo 1.2.0. I saw the crash on the > new IVI desktop. Then I modified the /etc/zypp/repo.d to point to where the > update testing repo is - > http://repo.meego.com/MeeGo/builds/1.2.0/1.2.0.0.5.20110709.1/ - and did a > zypper update. After that I did an install of ivi home. > > Good news - no more UX crashing - so that must have been the graphics bug > that was fixed in the update > > Bad news - ivihome is now a conglomeration of the new UX and the old UX, and > there is no easy way to launch a second console (which was the reason I > wanted to use ivihome in the first place > > I don't think that it is worth filing bugs against ivihome - are they on the > roadmap to be fixed? not for 1.2 as far as I'm concerned. desktop startup is entirely overhauled with systemd/uxlaunch rewrites in 1.3 and so all my focus will be on that. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Using old IVI home on MeeGo 1.2.0 and uxlaunch keeps getting called
On Thu, Jul 14, 2011 at 2:21 PM, Foster, Susan B wrote: > Hi, > > I need to be able to launch more than one console window at a time so I > reverted back to the old ivihome from the new QML UI by doing the following: > > #zypper install ivihome > > Modify uxlaunch > #vi /etc/sysconfig/uxlaunch > > Edit so that the only uncommented out lines are: >>user=meego >>session=/usr/bin/startivi > > remove the meego-ux-daemon.desktop file from /etc/xdg/autostart directory > #mv /etc/xdg/autostart/meego-ux-daemon.desktop ~ > > The problem I am getting is that with the 1.2.0 release on Crossville-OKI I > get the following line printed on console every 9 seconds: > Localhost klogd: [ 98.142230] Process uxlaunch(pid: 969, ti=f1448000 > task=f149ee30 task.ti=f1448000) > > When I look at the processes, sure enough there are LOTS of uxlaunch > processes. > > What do I need to do to disable this? uxlaunch is crashing, you need to figure out why: 1) include /var/log/uxlaunch.* 2) include /tmp/Xorg.* 3) dmesg output 4) /var/log/messages 5) /home/meego/.xsession-errors most likely it's because you modified some component, and that is misbehaving. A ~10 second interval usually suggests that Xorg is not properly functional. Did you modify the X server somehow? Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [Meego-kernel] Error drm/i915 can't work without intel_agp module DURING INSTALL
2011/7/13 张巍华 : > Hi all. > I'm trying to install MeeGo to my PC but everytime it gives me an error. > USB boot. "Welcome to Meego!" it says and from 3 options I choose > "Installation Only" and press Enter. This isn't a PC... I wonder what it is though... got any pictures? > Gray screen appears saying: > [ 0.484939] [drm:i915_init] *ERROR* drm/i915 can't work without > intel_agp module! I don't think the netbook supports the graphics chipset on this board. You'll have to work with your hardware vendor to figure out how to get drivers for the graphics card on this board. Alternatively, there is some wiki information, but YMMV, Maybe the IVI release has the drivers you need. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [Meego Dev]How to build Meego.Ux.Daemon
On Fri, Jul 8, 2011 at 5:02 AM, Shengjie Sun wrote: > Hi all, > i want to build the Meego.Ux.daemon in qemu which version is > meego-tablet-ia32-1.2.0.90.0.20110517.1. The error information is as follow: > > Package meegolocale was not found in the pkg-config search path. > Perhaps you should add the directory containing `meegolocale.pc' > to the PKG_CONFIG_PATH environment variable > No package 'meegolocale' found > Package meegolocale was not found in the pkg-config search path. > Perhaps you should add the directory containing `meegolocale.pc' > to the PKG_CONFIG_PATH environment variable > No package 'meegolocale' found > Package meegolocale was not found in the pkg-config search path. > Perhaps you should add the directory containing `meegolocale.pc' > to the PKG_CONFIG_PATH environment variable > No package 'meegolocale' found > > I believe there is a package called meegolocale i didnot install. But i > don`t find any information about meegolocale on the Internet. > How to build a environment to build Meego.Ux.daemon. I think that is a bad > repository that do not contain README! zypper si -d meego-ux-daemon ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] creating image for oaktrail platform using mic-image-creator
On Thu, Jul 7, 2011 at 7:43 AM, Jeremiah Foster wrote: > On Thu, Jul 7, 2011 at 2:52 PM, bradleyyan wrote: >> On 07/07/2011 03:24 PM, bradleyyan wrote: >>> >>> On 07/07/2011 11:30 AM, Arjan van de Ven wrote: On 7/6/2011 7:30 PM, bradleyyan wrote: > > It is my mistake,I forgetten to install install related packages. also make sure to upgrade your firmware; this was a bug in early firmwares that got since fixed... >>> I downloaded the meego repo to local machine,using the local repo to >>> install packages. >>> And when install image in machine using GUI mode,it said: >>> "X startup failed" >>> "/usr/sbin/liveinst: line93: kill: `': not a pid or valid job spec" >>> >> Problem had been solved, > > How was it solved? > >> the meego img doesn't support GUI mode >> installation. > > Is that correct for all images built with mic-image-creator? You > cannot install in graphical mode? Anaconda was recently removed from Trunk, and as such, there is no support currently for a graphical installer. The replacement is a rather spartan but effective install shell script that supports installing in free space, or whole disk. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo bugzilla on gitorious
On Mon, Jul 4, 2011 at 4:51 AM, wrote: > Hi everyone! > I'm very happy to announce that we have finally released our MeeGo bugzilla > instance code on gitorious. > Check it out here: https://gitorious.org/meego-bugzilla Can I ask why this isn't hosted under meego.gitorious.org instead? Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] File manager for Tablet Edition
2011/7/1 Éric Seigne : > Le 01/07/2011 18:53, Arjan van de Ven a écrit : >> On 7/1/2011 9:29 AM, Bernd Stramm wrote: >>> On Fri, 01 Jul 2011 09:14:17 -0700 >>> Andy Ross wrote: >>> On 07/01/2011 08:33 AM, Éric Seigne wrote: > so meego don't need a file manager for tablet, thanks a lot, i don't > waste my time. At the risk of adding more paint to the bikeshed: I think a better answer is that there are no plans to add a file manager as a core component. But a QML meego-ux-based third party utility would not doubt be a valuable contribution and see extensive use by technical users, just as it has on similar platforms. >>> In addition to that, it would be stupid to prevent people from >>> providing additional tools just because the original designers did not >>> foresee the usefulness. >>> >>> Why discourage people from contributing? >> sounds also like a perfect app for an AppStore(tm) kind of setup ;-) > > I'll be back :) > > i'm not discourraged (i'm working in free software developpement since > 1997). I've spend some hours translating meego-ux in french ... and i've > subscribe to this list only to know why my tablet with 1.2 (developper > preview) makes nothing when i plug my usb key ... and how i can add some > pictures to meego, import audio mp3, put some documents to hdd and so on. > > i'm a software developper so i have an idea (and a solution, i've > allready hack udev and so on to use my usb keys) ... but i think file > manager will miss ... > > i've got an answer, thanks > > But, in a really world with really users, could i ask you "what can i do > with a tablet ?" > > if the answer is only > - chat with friends on facebook > - send mails on google > - chat on MSN ... > - view pictures on picasaa > - surf the web > ... i'm sorry but what a pitty, 500$ for that ? i do the same with 50$ > old computer (but no touchscreen) :D > > meego is really a very very great project, open and free (libre), it > means everybody with a good idea could invent some uses of meego, could > invent some peace of software ... some news practises, not in > closed-world (apple and google one). > > basics uses of meego-ux lacks (as me and ~10 users here): > - full french support (the reason why i'm working on it) > - speed-up the interface (cf android 3) > - predictive keyboard (maybe already done ?) > - hibernation mode > - pdf / ebook reader > - office support (at least reading doc and odt files) these are realistic features - why not see if there are not already feature requests filed on bugs.meego.com, and write them if they are missing? > - mp3, avi, x264 (and so on) support -> flash is embedded so why not > the others non-free-but-must-have tools (or easy to install after > OS-install) ? Unfortunately, these codecs are not free. So they have no place in the "free" version of MeeGo. You can get them with a preinstalled version of MeeGo though, most vendors will likely include them. > - someting to copy/move/view my data (sorry, i'm an old guy and i think > meego open and free sofware must have a file manager, new users who > comes from linux or others os are happy to understand where there data > are, not in the cloud, not in hidden partition, meego is an open source > project, why users can't look at under the face ?) They can, because it's MeeGo. While it's unlikely that most vendors will ship meego with nautilus linked on the desktop, it's not preventing you from doing yourself. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Specification for OBS light project concept
On Fri, Jul 1, 2011 at 11:26 AM, Andy Ross wrote: > On 07/01/2011 10:59 AM, Kok, Auke-jan H wrote: >> >> I think Ryan is spot on. Until you get out of the hack-n-slash >> phase, your main development model should just be git, and ignore >> downstream. > > Yeah, but I'm with Shane on this. There's a big gap right now between > "I have a sandbox build with a fix and a patch" and "I have a working > package in OBS". And that gap is filled with traps, all of which > involve round trips to a known-finicky web app: > > + Have to remember the spectacle syntax again. you don't have to use spectacle. > + Patch collides with others: have to muck with ordering and respin. this is what devel projects are for: a sandbox where you're reasonably protected from changes in certain areas. all my devel projects build against MeeGo-1.2, Trunk, and Trunk:Testing. If Trunk and Trunk:Testing cause me to frown and spend too much time fixing up stuff, I just work against MeeGo-1.2 for a while. Or even MeeGo-1.1. > + Oops, forgot to update changes file (or just typo the date, builds > kick back if the dates aren't monotonic) irrelevant if you work in a devel project: You can violate all merge rules until you actually submit to Trunk:Testing. But at that point, you better fix your bad hack-n-slash packaging ;) > + Oops, built in a Trunk project branch when I should have branched > MeeGo:1.2:oss. see above. > + It's built, but won't install cleanly from the resulting repo > because the OBS build numbers are lower than the real version (quick > hack is to update a file a dozen times here), and it's something > like qt or libmeegotouch with frightening interpackage dependencies. Seems like a legitimate concern where OBS needs to be fixed. Please file a bugreport? > + Get everything ready, and just to annoy you OBS asks for a *third* > commit message (one in the patch, one in the .changes file, and a > third for the SR). Look up the bug number one last time... If you have a proper .changes file, you can leave this entirely empty. So, should not be an issue. > Add to that the fact that OBS projects are sometimes heavily patched, > and there's no straightforward path to turn an OBS project into a > buildable sandbox tree. The adaptation kernels and qt are really bad > in this respect. You can't meaningfully work with upstream code at > all for some things. Blame the kernel/Qt maintainer, not OBS? Performance is an issue, obviously, this probably needs to be a bugzilla. > And on top of it all, setting up OBS itself is really non-trivial. I > think something like this tool would be very useful, honestly, though > I think it's likely to be a ton of work to maintain. setting up OBS or osc? I just set up osc at home last week in 3 minutes on a totally unsupported distro (not even a .deb/.rpm distro) and I was able to checkin/build everything. Setting up OBS is something we have a team of people for to do this for projects. And, it's not easy, and we should see if we can improve it somehow. That does not warrant an OBS fork imo... Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Specification for OBS light project concept
On Fri, Jul 1, 2011 at 9:47 AM, Ware, Ryan R wrote: > On Fri, Jul 1, 2011 at 12:59 AM, Ramez Hanna wrote: >> On Thu, 2011-06-30 at 11:29 -0700, ext Kok, Auke-jan H wrote: >>> On Thu, Jun 30, 2011 at 5:09 AM, Ramez Hanna wrote: >>> > On Tue, 2011-06-14 at 10:52 +0200, ext Dominig ar Foll wrote: >>> >> Hello, >>> >> >>> >> those who have discussed with me during the MeeGo Conference in San >>> >> Francisco, know that I have started a small project to create a Light >>> >> version of OBS. >>> >> >>> >> The goal of the project is to ease the access to OBS for embedded >>> >> developers and initial investigation team which have to select an >>> >> embedded OS, by creating a tool which follows their traditional >>> >> development process (working locally in chroot) but keeps the >>> >> compatibility with the OBS. >>> >> >>> >> Some of the module that we are planning could potentially be of interest >>> >> for the real OBS (called Full OBS in my spec). In particular the the >>> >> automatic creation of patch files from a modified chroot and the UI for >>> >> MIC2 could become generic features. All created new code will be GPL2. >>> >> >>> >> Your feedback is welcome. All discussion will take place on the MeeGo >>> >> distribution-tools mailing list. >>> >> >>> >> http://lists.meego.com/listinfo/meego-distribution-tools >>> >> >>> >> The file is on the MeeGo Wiki. >>> >> >>> >> http://wiki.meego.com/images/SpecOBSLight-1_V-0-6.pdf >>> >> >>> > I also got similar (if not exactly) requirements from some of our >>> > internal developers, I have drafted a wiki page describing the reasons >>> > we think we need a different tool than just osc/obs and some details of >>> > the proposed implementation >>> > I would like to get more feedback to be able to make this tool usefull >>> > form more than just our internal developers >>> > >>> > Dominig I think we can work together on something here, our approach is >>> > much simpler than the one you propose >>> > maybe we can find some middle ground. >>> >>> can you state *why*, I asked before but I never got a reply. Please, >>> take some time to explain: >>> >>> - Why is current OBS insufficient for your development model? Would >>> running another instance of OBS not suffice? >> according to developers, they see OBS as a perfect system to deliver for >> integration cycles, but slow for hack,build,test cycles prior to >> integrating into product > > That would be because OBS isn't the tool they are supposed to be using > for that. It's not a tool for hacking and testing. It's not a > version control system. Trying to use it for that would be akin to > trying to write your Linux development code with Microsoft Word > running in Wine. It might be possible, but was never the intent of > the tool. > > They should be doing their development using their standard processes > with their normal version control system and then submitting a release > once they are done hacking and testing. I'm having a hard time with this as well, and I did not still get an answer from Dominig describing his specific concerns either, which doesn't help. I think Ryan is spot on. Until you get out of the hack-n-slash phase, your main development model should just be git, and ignore downstream. This is what most developers do, and widely accepted as the most flexible way to develop: You get to pick the development target, replace components at will, and when you're ready to integrate, you start with OBS. Those parts will not change, so adding an artificial step in between where you're both developing and integrating, seems detrimental to me, and just will add to the process overhead for developers: Now they need to work with a 3rd toolset. I can't think but this is a bad idea to spend a lot of time on. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Specification for OBS light project concept
On Thu, Jun 30, 2011 at 5:09 AM, Ramez Hanna wrote: > On Tue, 2011-06-14 at 10:52 +0200, ext Dominig ar Foll wrote: >> Hello, >> >> those who have discussed with me during the MeeGo Conference in San >> Francisco, know that I have started a small project to create a Light >> version of OBS. >> >> The goal of the project is to ease the access to OBS for embedded >> developers and initial investigation team which have to select an >> embedded OS, by creating a tool which follows their traditional >> development process (working locally in chroot) but keeps the >> compatibility with the OBS. >> >> Some of the module that we are planning could potentially be of interest >> for the real OBS (called Full OBS in my spec). In particular the the >> automatic creation of patch files from a modified chroot and the UI for >> MIC2 could become generic features. All created new code will be GPL2. >> >> Your feedback is welcome. All discussion will take place on the MeeGo >> distribution-tools mailing list. >> >> http://lists.meego.com/listinfo/meego-distribution-tools >> >> The file is on the MeeGo Wiki. >> >> http://wiki.meego.com/images/SpecOBSLight-1_V-0-6.pdf >> > I also got similar (if not exactly) requirements from some of our > internal developers, I have drafted a wiki page describing the reasons > we think we need a different tool than just osc/obs and some details of > the proposed implementation > I would like to get more feedback to be able to make this tool usefull > form more than just our internal developers > > Dominig I think we can work together on something here, our approach is > much simpler than the one you propose > maybe we can find some middle ground. can you state *why*, I asked before but I never got a reply. Please, take some time to explain: - Why is current OBS insufficient for your development model? Would running another instance of OBS not suffice? - Why can't the current OBS software be enhanced to better provide the needed features? Given that you and Dominig both state "it's needed", it should be trivial to answer these questions. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] uxlaunch can not connect to Consolekit
On Mon, Jun 27, 2011 at 11:48 PM, steven wrote: > Hi guys > > we built our image with this repo > http://repo.meego.com/MeeGo/builds/1.2.0.90/1.2.0.90.0.20110517. > > and after we power up this system, we got a message from uxlaunch.log > [ > Error: Unable to open session with ConsoleKit: > org.freedesktop.CkConnector.Error: Unable to open session: Launch helper > exited with unknown return code 1 > ] > > also in /var/log/messages,we got this error message: > [ > May 30 14:07:50 localhost dbus-daemon: [system] Rejected send message, 4 > matched rules; type="method_call", sender=":1.9" (uid=500 pid=310 > comm="uxlaunch) interface="org.freedesktop.ConsoleKit.Manager" > member="OpenSessionWithParameters" error name="(unset)" > requested_reply=0 destination="org.freedesktop.ConsoleKit" (uid=0 > pid=427 comm="/usr/sbin/console-kit-daemon)) > May 30 14:07:50 localhost console-kit-daemon[427]: WARNING: Failed to > acquire org.freedesktop.ConsoleKit: Rejected send message, 4 matched > rules; type="method_call", sender=":1.9" (uid=500 pid=310 > comm="uxlaunch) interface="org.freedesktop.ConsoleKit.Manager" > member="OpenSessionWithParameters" error name="(unset)" > requested_reply=0 destination="org.freedesktop.ConsoleKit" (uid=0 > pid=427 comm="/usr/sbin/console-kit-daemon)) > May 30 14:07:50 localhost console-kit-daemon[427]: WARNING: Could not > acquire name; bailing out > ] > we using ck-list-sessions command, it got nothing. > > So does anyone can give me a hint on this? First, of all, please open a bugzilla for this. This needs to be fixed in 1.2.1 or the earliest possible update. Second, it seems that the patch we have in ConsoleKit was missing, which isn't good. I'll need to fix this for which I need the bugzilla report. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Execute automatically a script at statup in meego-tablet-ia32-pinetrail-1.1.90.2.20110209.4
On Mon, Jun 27, 2011 at 1:43 PM, Leonardo Luiz Padovani da Mata wrote: >> it is neither in trunk, and initscripts will not work from 1.3 on. >> I've already explained why you can't have synergyc start in an init >> script anyway. > > Since it's 1.1.90.* should work with initscripts, right? no you can't start synergyc as initscript daemon, period. See my previous post as to why this will not work. Auke. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Execute automatically a script at statup in meego-tablet-ia32-pinetrail-1.1.90.2.20110209.4
On Mon, Jun 27, 2011 at 1:02 PM, Leonardo Luiz Padovani da Mata wrote: > Hey Bogdan, consider adding the script call on /etc/rc.local. > > As i remember, the default runlevel for MeeGo is 3, not 5, so adding > it to rc3.d might work also. it is neither in trunk, and initscripts will not work from 1.3 on. I've already explained why you can't have synergyc start in an init script anyway. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Execute automatically a script at statup in meego-tablet-ia32-pinetrail-1.1.90.2.20110209.4
On Sun, Jun 26, 2011 at 7:44 AM, Bogdan Cristea wrote: > I would like to execute at startup a script allowing to launch synergy client. > I have put this script in /etc/init.d and made a soft link to the script in > /etc/rc5.d, but the client is not running. What is the approach I need to > follow in order to lauch a script at startup ? The synergy client (synergyc) can not be started from an init.d script, as this would not enable the client to connect to the X11 session and do it's work. You need to make a desktop autostart file, and put it in ~/.config/autostart/. Something like this (adjust options appropriately for your systems) will work: $ cat ~/.config/autostart/synergy-client.desktop [Desktop Entry] Name=Synergy client Exec=synergyc -n client server.com --no-daemon X-MeeGo-Priority=Low X-MeeGo-Watchdog=Restart Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Systemd bugs? Please file them!
There's been some random questions about things people have seen wrt. systemd. weird output in mic2, messages during rpm updates, booting etc. However, at this point I'd like everyone to submit bugreports for every instance instead of contacting me or Chris F. directly. Since we obviously are starting to have regular images out there where you may or may not see some of these warnings/errors, it's just better to be sure and have a trackable bug number. So please, go ahead and file bugs against "MeeGo Platform" -> "OS Base" -> "System Startup" and put "systemd" in the title. Thanks Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Changes to uxlaunch in Trunk: configuration will need changes.
On Thu, Jun 23, 2011 at 6:19 PM, steven wrote: > Hi Auke, > > if we wana integrate Wayland into meego tablet, how should it be > started, will Wayland be started in uxlaunch? This is still in the open and not determined just yet. In practice, yes, uxlaunch will remain the process that makes the jump from "system session" to "user session" and therefore that will not chainge. However, in it's current form uxlaunch will start Xorg no matter what, and this needs fixing. In reality, it's a small change, but we'll need to figure out how to run all the scenarios (X support enabled, disabled or not etc.). The changes below are needed for this, but, it will get a bit more complex, and, I'll need some time to get it working. Auke > > Thanks, > > Steven Liu > > On Sun, 2011-06-19 at 21:30 -0700, Kok, Auke-jan H wrote: >> Hi, >> >> I've adjusted several things in the way uxlaunch operates in the >> recent weeks, and the most important changes are about to land in >> Trunk. I'll try and explain how things will work a bit in here since >> it affects the way we start the desktop session significantly, and >> this affects any image you can make. >> >> What changed exactly? Well, the biggest change is that there is no >> hardcoded session table anymore, and so now each session needs to be >> defined in a session definition file instead. That means that instead >> of telling uxlaunch "start /usr/bin/mutter --sm-disable", you'll now >> tell it to 'start the x-meego-nb' session, and something will instruct >> uxlaunch that that implies 'mutter' etc. >> >> Also, the new code allows the USER to entirely override this and >> create their own session definition, and completely different than >> what the main system defines as default. Yes, that's right, you can >> change your own desktop without root permissions. >> >> This is done through generic xsession desktop files. A lot of DE's >> already ship them (xfce, xbmc, even gnome) and so we're reusing this >> mechanism for maximum flexibility. Session files are named >> 'foo.desktop' and list an Exec= key that will be started as the >> session process. The 'foo' part is assumed to define the 'session >> name'. This allows uxlaunch to hide applications through the >> OnlyShowIn and NotShowIn fields as it did before. >> >> The impact for most people will be nil, except two groups: >> >> Release engineering & people who make images: You'll have to rewrite >> the kickstart files and uxlaunch configs. >> >> - The appropriate UX package needs to install a >> "/usr/share/xsessions/sessionname.desktop" file >> The "sessionname" should be consistent with MeeGo's naming >> convention: acceptable are "x-meego-nb", "x-meego-hs", "x-meego-tb", >> "x-meego-tv", "x-meego-ivi", others need to be discussed first as >> there is an impact on all packages if you make something up, and your >> UX might not work properly. (autostart files will be filtered >> case-insensitive). >> - Selecting a default session is done through symlinking in the >> kickstart file: The %post section needs to execute a line like this: >> ln -sf x-meego-nb.desktop /usr/share/applications/default.desktop >> This symlink *must never* be part of an installed package. >> - As local sysadmin, you can re-define sessions in >> /etc/X11/dm/Sessions/ to override the distro defaults >> - As local user, you can re-define sessions in ~/.config/xsessions/ to >> override both distro and local admin defaults. >> >> >> People who are building new UX's: You'll have to create session files: >> - start with creating your own ~/.config/xsessions/x-meego-foo.desktop >> and symlink this to default.desktop >> >> For a few of the MeeGo UX's, I will ensure that we have proper session >> files installed in the course of the coming week to make sure the >> change is without issues. For any issues or questions, please contact >> me or post a reply on the list. >> >> Auke >> ___ >> MeeGo-dev mailing list >> MeeGo-dev@meego.com >> http://lists.meego.com/listinfo/meego-dev >> http://wiki.meego.com/Mailing_list_guidelines > > > --
Re: [MeeGo-dev] Errors doing rpmbuild with kernel-adaptation-intel-automotive
please take a look at: http://wiki.meego.com/Recompile_kernel and, if this isn't enough information, we should document this page with more detailed instructions. Auke On Thu, Jun 23, 2011 at 6:53 AM, Liu, Bing Wei wrote: > Can MeeGo kernel gurus help to answer this issue - how to rebuild the MeeGo > kernel w/o an OBS account? > I think it's generic to other kernels in MeeGo. > > - Bingwei > > >> -Original Message- >> From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] >> On Behalf Of Foster, Susan B >> Sent: Tuesday, June 21, 2011 12:26 AM >> To: Kok, Auke-jan H >> Cc: meego-dev@meego.com >> Subject: Re: [MeeGo-dev] Errors doing rpmbuild with kernel-adaptation- >> intel-automotive >> >> Leaving aside the "why didn't I have the tools?" which is probably >> "they are included in the image I had been using, but not the release >> and this has nothing to do with doing the zypper si". >> >> I still have the following bad exit status: >> >> #zypper si kernel-adaptation-intel-automotive >> #cd ~/rpmbuild/SPEC >> #rpmbuild -bp kernel-adaptation-intel-automotive.spec >> >> >> >> ++ cat .config >> ++ grep -c CONFIG_ARM=y >> + '[' 0 -eq 1 ']' >> + echo Doing kernel-adaptation-intel-automotive.config >> Doing kernel-adaptation-intel-automotive.config >> + make ARCH=x86 listnewconfig >> error: Bad exit status from /var/tmp/rpm-tmp.Lcu21t (%prep) >> RPM build errors: >> Bad exit status from /var/tmp/rpm-tmp.Lcu21t (%prep) >> >> -Original Message- >> From: Kok, Auke-jan H [mailto:auke-jan.h@intel.com] >> Sent: Friday, June 17, 2011 8:36 PM >> To: Foster, Susan B >> Cc: meego-dev@meego.com >> Subject: Re: [MeeGo-dev] Errors doing rpmbuild with kernel-adaptation- >> intel-automotive >> >> On Fri, Jun 17, 2011 at 5:35 PM, Foster, Susan B >> wrote: >> > Oops, mistake in here sorry - I enabled source in the oss-repo and >> was doing: >> > >> > zypper si kernel-adaptation-intel-automotive >> > >> > Which in the past has installed the all the tools needed to build the >> kernel, not just some of them... >> >> yes, that's quite likely. The idea from `si` is that you get the build >> dependencies (headers, libraries). >> >> Getting the tools themselves is not part of that for several reasons. >> Mostly because it makes generating packages on the server faster, and >> that's a good thing. >> >> There are still the zypper patterns, those will give you all the basic >> compilation tools in one command. Check `zypper pt` which one you >> need/have, and use `zypper in -t pattern $pattern` to install a whole >> pattern at once. >> >> Auke >> ___ >> MeeGo-dev mailing list >> MeeGo-dev@meego.com >> http://lists.meego.com/listinfo/meego-dev >> http://wiki.meego.com/Mailing_list_guidelines > ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] boxbe users: please read.
Dear boxbe users, You are causing everyone who posts to lists that you subscribe to to receive one of the below messages. This is not a very friendly thing to do, since, by subscribing to the list, you agree to receiving voluntarily to receive the messages posting on the list. Effectively, you are spamming to all the posters on the list, which is ... terrible. I suggest kindly to stop using boxbe, and make your case against boxbe to improve their service. As a precaution, I'm asking our mailman moderators to keep an eye out for this and remove offenders. Auke -- Forwarded message -- From: Date: Tue, Jun 21, 2011 at 3:02 PM Subject: Re: Re: [meego-packaging] meego-ux-mediafs spec fix (Action Required) To: "Kok, Auke-jan H" Hello Kok, Auke-jan H, Your message about "Re: [meego-packaging] meego-ux-mediafs spec fix" was waitlisted. Please add yourself to my Guest List so your messages will be delivered to my Inbox. Use the link below. Click here to deliver your message <https://www.boxbe.com/crs?tc=8471564138_1483234890> Thank you, anand.d...@gmail.com [image: Boxbe] <http://www.boxbe.com/how-it-works?tc=8471564138_1483234890> Powered by Boxbe -- "End Email Overload" Final-Recipient: rfc822; anand.d...@gmail.com Diagnostic-Code: X-Boxbe-Notice; Sender not pre-approved. Follow instructions in above notice Status: 4.7.0 ------ Forwarded message -- From: "Kok, Auke-jan H" To: "Brandt, Todd E" Date: Tue, 21 Jun 2011 15:02:02 -0700 Subject: Re: [meego-packaging] meego-ux-mediafs spec fix ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Changes to uxlaunch in Trunk: configuration will need changes.
On Sun, Jun 19, 2011 at 11:23 PM, Marko Saukko wrote: > On 06/20/2011 07:30 AM, Kok, Auke-jan H wrote: >> >> What changed exactly? Well, the biggest change is that there is no >> hardcoded session table anymore, and so now each session needs to be >> defined in a session definition file instead. That means that instead >> of telling uxlaunch "start /usr/bin/mutter --sm-disable", you'll now >> tell it to 'start the x-meego-nb' session, and something will instruct >> uxlaunch that that implies 'mutter' etc. > > Sounds good. > >> >> Also, the new code allows the USER to entirely override this and >> create their own session definition, and completely different than >> what the main system defines as default. Yes, that's right, you can >> change your own desktop without root permissions. > > Will the user who's home is read be still determined by entry in > /etc/sysconfig/uxlaunch? yes, this will not change. note that on machines with only 1 user under /home, this will always be the default user that uxlaunch picks, making the setting largely optional. >> >> This is done through generic xsession desktop files. A lot of DE's >> already ship them (xfce, xbmc, even gnome) and so we're reusing this >> mechanism for maximum flexibility. Session files are named >> 'foo.desktop' and list an Exec= key that will be started as the >> session process. The 'foo' part is assumed to define the 'session >> name'. This allows uxlaunch to hide applications through the >> OnlyShowIn and NotShowIn fields as it did before. > > Currently uxlaunch has the xopts in the /etc/sysconfig/uxlaunch, could this > be moved to the UX .desktop file as well or even better could we provide > Xorg parameters as dynamic files in some directory as on touch devices you > don't want to see mouse cursor and netbooks you want, something that is also > more hardware thing. So information that hardware adaptation pattern/package > group might contain. > > Currently there is following hack in .ks files > https://meego.gitorious.org/meego-os-base/image-configurations/blobs/master/custom/scripts/uxlaunch-nocursor.post realistically this should end up in an xorg.conf.d dropin file, any other solution does not seem like a decent one. >> The impact for most people will be nil, except two groups: >> >> Release engineering& people who make images: You'll have to rewrite >> the kickstart files and uxlaunch configs. >> >> - The appropriate UX package needs to install a >> "/usr/share/xsessions/sessionname.desktop" file >> The "sessionname" should be consistent with MeeGo's naming >> convention: acceptable are "x-meego-nb", "x-meego-hs", "x-meego-tb", >> "x-meego-tv", "x-meego-ivi", others need to be discussed first as >> there is an impact on all packages if you make something up, and your >> UX might not work properly. (autostart files will be filtered >> case-insensitive). > > This is probably something that the UX specific pattern/package group should > provide. yes. I just submitted one example to for mutter myself. >> - Selecting a default session is done through symlinking in the >> kickstart file: The %post section needs to execute a line like this: >> ln -sf x-meego-nb.desktop /usr/share/applications/default.desktop >> This symlink *must never* be part of an installed package. > > Maybe a patch for mic2? Currently there are following lines in .ks file that > do some magics in this area: > > xconfig --startxonboot > desktop --autologinuser=meego --defaultdesktop=DUI > --session="/usr/bin/mcompositor" perhaps, but, I really dislike the xconfig option. It started out as a method to configure classic Xfree, and with all the recent changes to how we start the system, it's being rewritten every other week for instance, the --autologinuser=meego is completely unneeded on any meego image. the --defaultdesktop option does what? uxlaunch doesn't even know what DUI is for a while now. Obviously the '--session' would change as well, again. I'm a bit reluctant now to push for a change while this code is still in flux as well. After it's all settled, we can revisit. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Changes to uxlaunch in Trunk: configuration will need changes.
Hi, I've adjusted several things in the way uxlaunch operates in the recent weeks, and the most important changes are about to land in Trunk. I'll try and explain how things will work a bit in here since it affects the way we start the desktop session significantly, and this affects any image you can make. What changed exactly? Well, the biggest change is that there is no hardcoded session table anymore, and so now each session needs to be defined in a session definition file instead. That means that instead of telling uxlaunch "start /usr/bin/mutter --sm-disable", you'll now tell it to 'start the x-meego-nb' session, and something will instruct uxlaunch that that implies 'mutter' etc. Also, the new code allows the USER to entirely override this and create their own session definition, and completely different than what the main system defines as default. Yes, that's right, you can change your own desktop without root permissions. This is done through generic xsession desktop files. A lot of DE's already ship them (xfce, xbmc, even gnome) and so we're reusing this mechanism for maximum flexibility. Session files are named 'foo.desktop' and list an Exec= key that will be started as the session process. The 'foo' part is assumed to define the 'session name'. This allows uxlaunch to hide applications through the OnlyShowIn and NotShowIn fields as it did before. The impact for most people will be nil, except two groups: Release engineering & people who make images: You'll have to rewrite the kickstart files and uxlaunch configs. - The appropriate UX package needs to install a "/usr/share/xsessions/sessionname.desktop" file The "sessionname" should be consistent with MeeGo's naming convention: acceptable are "x-meego-nb", "x-meego-hs", "x-meego-tb", "x-meego-tv", "x-meego-ivi", others need to be discussed first as there is an impact on all packages if you make something up, and your UX might not work properly. (autostart files will be filtered case-insensitive). - Selecting a default session is done through symlinking in the kickstart file: The %post section needs to execute a line like this: ln -sf x-meego-nb.desktop /usr/share/applications/default.desktop This symlink *must never* be part of an installed package. - As local sysadmin, you can re-define sessions in /etc/X11/dm/Sessions/ to override the distro defaults - As local user, you can re-define sessions in ~/.config/xsessions/ to override both distro and local admin defaults. People who are building new UX's: You'll have to create session files: - start with creating your own ~/.config/xsessions/x-meego-foo.desktop and symlink this to default.desktop For a few of the MeeGo UX's, I will ensure that we have proper session files installed in the course of the coming week to make sure the change is without issues. For any issues or questions, please contact me or post a reply on the list. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Errors doing rpmbuild with kernel-adaptation-intel-automotive
On Fri, Jun 17, 2011 at 5:35 PM, Foster, Susan B wrote: > Oops, mistake in here sorry - I enabled source in the oss-repo and was doing: > > zypper si kernel-adaptation-intel-automotive > > Which in the past has installed the all the tools needed to build the kernel, > not just some of them... yes, that's quite likely. The idea from `si` is that you get the build dependencies (headers, libraries). Getting the tools themselves is not part of that for several reasons. Mostly because it makes generating packages on the server faster, and that's a good thing. There are still the zypper patterns, those will give you all the basic compilation tools in one command. Check `zypper pt` which one you need/have, and use `zypper in -t pattern $pattern` to install a whole pattern at once. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Errors doing rpmbuild with kernel-adaptation-intel-automotive
On Fri, Jun 17, 2011 at 5:12 PM, Foster, Susan B wrote: > Hi, > > I have built kernels on target in the past with MeeGo 1.0 and 1.1, but I am > encountering some issues with the MeeGo 1.2.0 release for IVI. I am > basically following the instructions that OKI-Semi has on Sourceforge - they > have worked flawlessly on MeeGo 1.0 and 1.1. > > I am doing the build on target - both a Crossville-OKI and on one of the > ML7213 reference boards with the same results > > 1) When I do a zypper install kernel-adaptation-intel-automotive I have in > the past gotten all the tools that I need to build a kernel. that doesn't make any sense, this command "just adds a kernel" to your /boot. It won't install any build tools at all, and never has. > With MeeGo 1.2.0 I am having to install rpm-build, ncurses-devel and gcc, >they don't get installed with the kernel, although make and other tools do. > > 2) When I get rpmbuild and gcc and do a > #rpmbuild -bp kernel-adaptation-intel-automotive.spec > > I get the following errors: > > ++ cat .config > ++ grep -c CONFIG_ARM=y > + '[' 0 -eq 1 ']' > + echo Doing kernel-adaptation-intel-automotive.config > Doing kernel-adaptation-intel-automotive.config > + make ARCH=x86 listnewconfig > error: Bad exit status from /var/tmp/rpm-tmp.Lcu21t (%prep) > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.Lcu21t (%prep) > > I realize that building on the target is about the slowest way of doing this, > and if there is a link to good instructions on setting up a Linux development > machine to do the kernel build, I'm all for that. Get an OBS account on build.meego.com (by filing a bug on bugs.meego.com for access) and you will have the opportunity to let the build server compile your kernels for you, which is by far the easiest method. The obs client can then download what the server compiles ( `osc getbinaries` ) and then you can just rpm install the downloaded rpms right there. All working on a meego system without making it sweat :). There is also some scattered documentation on the wiki if you want to build yourself, but, I really recommend looking into using the meego OBS first. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Wayland effort in 1.3 - planning, discussion, activities, etc
On Fri, Jun 17, 2011 at 8:31 AM, Carsten Munk wrote: > Hi all, > > One of the things we're trying to achieve in 1.3 is Wayland support, > but there seems to be very little documented on actual plans/tasks to > be done and not high transparency on what's being done currently. So > how do we change this? - we need to get all the effort pushed into > this as we can and ideally not do too much duplicate work :). I've > taken a liking to Wayland in MeeGo and am trying to contribute what I > can, myself. Same from me, especially when it comes to initialization: We'll have the chance to overhaul the way we do desktop startup soon, with systemd taking a larger place, but we also need to redo some of the uxlaunch code to better support wayland, and I'll be ready to discuss that... Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Specification for OBS light project concept
On Tue, Jun 14, 2011 at 1:52 AM, Dominig ar Foll wrote: > those who have discussed with me during the MeeGo Conference in San > Francisco, know that I have started a small project to create a Light > version of OBS. > > The goal of the project is to ease the access to OBS for embedded > developers and initial investigation team which have to select an > embedded OS, by creating a tool which follows their traditional > development process (working locally in chroot) but keeps the > compatibility with the OBS. > > Some of the module that we are planning could potentially be of interest > for the real OBS (called Full OBS in my spec). In particular the the > automatic creation of patch files from a modified chroot and the UI for > MIC2 could become generic features. All created new code will be GPL2. > > Your feedback is welcome. All discussion will take place on the MeeGo > distribution-tools mailing list. Dominig, it's a bit unclear why this is needed: - Why is current OBS insufficient for your development model? Would running another instance of OBS not suffice? - Why can't the current OBS software be enhanced to better provide the needed features? I'm sure nobody will object against you undertaking this effort, but, if we can extend the current OBS to provide the features needed, we should be in a much better shape going forward: I can only imagine how horrible it will be to maintain a secondary toolset based on a non-stable OBS API if upstream is unwilling to cooperate. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Cutting MeeGo 1.3 install footprint, locales?
On Fri, Jun 10, 2011 at 1:56 PM, Arjan van de Ven wrote: > On 6/10/2011 1:54 PM, Carsten Munk wrote: >> >> Hi, >> >> One of the bigger users of space in the images is >> /usr/lib/locale/locale-archive, which takes up 99mb uncompressed. > > is this based on "ls" output, or after taking sparse files into account ? > > also, our filesystem compresses as you know; how well does this compress > down ? $ cat /usr/lib/locale/locale-archive | gzip > out $ ls -lh out -rw-rw-r-- 1 ahkok ahkok 22M 2011-06-10 13:59 out Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Anyboday can make change on OBS?
On Wed, Jun 8, 2011 at 8:01 PM, Huo, Halton wrote: > I can run update actually, but fail when committing change. things to try: - make sure you are using a supported distribution. (everyone uses meego to commit changes in OBS, right?). - check your version of OBS. update if needed. - checkout a clean copy of the project instead of working with an old checkout. - file a bug against `osc`, include debug/error output, your distro, versions installed of python, osc, etc... Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Any word on the Ubuntu 11.04 repo
On Tue, Jun 7, 2011 at 10:25 PM, David Boosalis wrote: > Does anyone have any information as to when we might see a Meego repo for > Ubuntu 11.04. I really don't want to reinstall 10.10 now that I am running > 11.04 you mean a "tools" repo? Perhaps a bugzilla request is in order, so that the issue can be tracked and worked, and assigned to the right people. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] about uxlaunch support a command line option with enable/disable xsession-errors feature
On Mon, May 30, 2011 at 5:55 PM, steven wrote: > On Mon, 2011-05-30 at 16:58 -0700, Arjan van de Ven wrote: > > On 5/30/2011 1:23 AM, steven wrote: > > > On Mon, 2011-05-30 at 10:15 +0200, Andre Klapper wrote: > > >> On Mon, 2011-05-30 at 16:05 +0800, steven wrote: > > >>> currently when uxlauncher start a new user session, it will redirect > > >>> stderr/stdout to file xsession-errors, and all x client will write > their > > >>> log messages to this file, and this file will get too big in one > > >>> power-up cycle > > >> Please define "too big" by providing numbers, and why you think it is > > >> actually too big... > > >> > > > 400M > > > > yikes > > > > sounds like some program is hitting a lot of really bad debug messages... > > > > .. can you look inside the file to find out which ones need fixing > > urgently ? > > > > there isn't something wrong, just I installed a bad written package, and > it output too many debug messages which make the xsession-errors to > reach that limit. so comes out the question above. > > but now I agree with Kok not adding this feature to uxlaunch. > see kok's comments. > it's Auke and, please, tell us which package is writing 400mb of output so we can address the issue with the person who wrote the package? ;) Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] How to sync with the network time server in meego?
On Mon, May 30, 2011 at 6:00 PM, steven wrote: > On Mon, 2011-05-30 at 16:59 -0700, Arjan van de Ven wrote: > > On 5/30/2011 5:08 AM, steven wrote: > > > Hi, > > > > > > as for NTP, I remember that timed middleware also support NTP, and > > this > > > middleware is included in meego compliance group, so I think if we > > want > > > to use NTP time, we should use timed's interface for future > > compliance. > > > > timed is not part of compliance! It's on it's way out, at least the > > exact usage of it is. > did you mean meego will remove timed package in the near future? > ntp synchronization is currently (in Trunk) being done by connman - it takes the dhcp server ntp addresses and spawns a shortlived sync ntpd process. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] about uxlaunch support a command line option with enable/disable xsession-errors feature
On Mon, May 30, 2011 at 4:40 AM, steven wrote: > > On Mon, 2011-05-30 at 17:59 +0800, Pei Lin wrote: > > 2011/5/30 steven : > > > > > > On Mon, 2011-05-30 at 10:15 +0200, Andre Klapper wrote: > > >> On Mon, 2011-05-30 at 16:05 +0800, steven wrote: > > >> > currently when uxlauncher start a new user session, it will redirect > > >> > stderr/stdout to file xsession-errors, and all x client will write > their > > >> > log messages to this file, and this file will get too big in one > > >> > power-up cycle > > >> > > >> Please define "too big" by providing numbers, and why you think it is > > >> actually too big... > > >> > > > > > > 400M > > > > I think first should check where and why so huge errors coming from > > and not only redirect errors to /dev/null. > > Finding the reason is more important that workaround something. > > One trick method can be as that "ln -s /dev/null ~/.xsession-errors" > this looks nice, but I think it's very convenient for the user to log > messages to file or not. so does anyone want to give a comment on > whether to add the feature to uxlaunch or not? > I will not merge such a change. Any program written to log 400MB of output to stdout/stderr is obviously written to do this on purpose, and throwing the output away would not help in any way at all. To be honest, the ~/.xsession-errors file should (in a production level installation) be mostly empty. But if it does fill up, as QA often finds, it's the only indicator that something really went wrong. Removing that indicator would not help anyone at all, and just makes bugs harder to detect. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Can i distribute MeeGo ?
(sorry for top-posting) The questions below can't be simply answered by anyone here. Please contact a lawyer and have them advise you whether you can do what you want to do legally. Cheers, Auke -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Dome Charoenyost Sent: Saturday, June 12, 2010 3:27 AM To: meego-dev@meego.com Subject: [MeeGo-dev] Can i distribute MeeGo ? Dear All, I'm modify MeeGo for support nvidia , ati and include XBMC . I'm worry about copyright. so i want to know what's good way for distribute meeGo modify version. I don't want to folk. 1. Can i still use all graphic and logo in side Meego ? 2. Can i use MeeGo for name of my version? BG Dome C. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
