[03:23] micahg: IIRC, yes. [03:23] ScottK: k, we're fixing it anyways :) [03:24] kpackagekit is broken by design. [03:24] Actually it's packagekit. [03:24] kpackagekit does a decent job of making the best of a bad situation. [03:27] looks like the next rekonq is infact being targeted against qtwebkit 2.2: http://adjamblog.wordpress.com/2011/06/22/back-hacking/ [03:27] Handy. === Linkmaster is now known as Linkmaster|away [07:34] JontheEchidna: yay :D [07:49] shadeslayer: I am around, but you are probably asleep :) [07:53] Morning agateau!!! [07:54] Morning jussi! [07:54] agateau: how are things going? [07:55] hey jussi, agateau :) [07:55] ooh, everyone is just waking up. [07:56] jussi: fine thanks, what about your forking process? [07:56] didrocks: hi! === GrueMaster_ is now known as GrueMaster [07:56] was there for some time, just trying to catch up emails :) [07:58] didrocks is an early riser [07:59] depends on the day, but generally, yes :-) [08:03] agateau: FYI, I'm uploading in oneiric today Qt (a11y version and new utouch patch), sni-qt plugin patch will hopefully do it in next cut [08:03] didrocks: ok [08:03] didrocks: still waiting for confirmation from Qt devs :/ [08:04] agateau: right, let's not wait the a11y patch on that then, it will be a separate upload (and I'm sure we will have independant a11y fixes as well, so new uploads will be needed anyway) [08:04] didrocks: yes [08:06] agateau: the process is going well. She just started the second trimester, so Morning sickness is beginning to go away :) [08:06] jussi: good! morning sickness is a pain [09:03] shadeslayer: Quintasan http://www.engadget.com/photos/nokia-n950-press-shots/ === hunger_ is now known as hunger [09:21] apachelogger http://www.youtube.com/watch?v=ykwqXuMPsoc&feature=player_embedded#at=55 [09:42] sheytan: that's evil! [09:42] valorie yeah :D [09:43] :-) [10:07] jussi: How much for that one? === tazz_ is now known as tazz [10:31] Quintasan: they will loan you one... [10:32] jussi: where? [10:34] Quintasan: https://meego.com/community/device-program [10:35] jussi: Is working on Kubuntu Mobile enough to get this device? [10:36] Quintasan: I doubt it, I dont think they will be very interested in that commercially. Find something interesting you are willing to port... [10:36] Probably something with a large userbase ;) [10:41] Quintasan: video :) http://thenokiablog.com/2011/06/22/nokia-n950-hands-on/ [10:45] * jussi is in love :D [10:47] Quintasan: Candidates must be community developers ready to start working on new or existing open source applications, to be published in apps.meego.com and the Nokia Store. Links to your current projects are relevant! Deadline for applications: end of Tuesday, June 28th. [10:52] Quintasan: if you have questions--- http://forum.meego.com/showthread.php?t=3597 [11:38] morning [11:38] oh, 4.6.90 is up [11:55] * yofel goes updating the dep-graph again... [11:55] morning QuintasanDroid [11:58] at least Dirk cleaned up the tars this time, the empty ones are gone [12:01] * apachelogger giggles [12:03] Quintasan: plasma mobile i ssoooo sluggish because of no hardware accel and because of SD slowness [12:04] shadeslayer: yes you can over draw your card, in which case you need to pay big time moniez [12:04] Quintasan: why you be waiting for me? [12:04] jussi: stop making people long for microsoft^Wnokia products :P [12:05] apachelogger: awww [12:06] apachelogger: ohk [12:06] then Ill try compiling the kernel later [12:06] it was a 700 mb download [12:06] not 320 :O [12:07] this dep graph is becoming unreadable... [12:07] * QuintasanDroid looks at his todo and feels overwhelmed [12:07] time to split it a little bit [12:08] Quintasan: you do not need to build the kernelz [12:08] dude [12:08] read what I wrote yesterday :P [12:08] you only need to build like 3 source packages for the graphics stack [12:11] cool [12:20] great, wiki is utterly broken [12:21] open attachment page -> login to edit -> login -> {back to main page -> open attachment page -> login to edit -> login ->}* [12:24] hm, got it to work in konqueror [12:26] didrocks: We need to coordinate on Qt. [12:26] ScottK: I think we did? I talked to you some weeks ago about adding the accessibility with the Qt guys and on Monday that it was almost there, isn't it? [12:26] didrocks: Quintasan did an updated merge from Debian that debfx was reviewing for upload. [12:26] oh :/ [12:27] So we need to make sure we have this coordinated. [12:27] right, as when you are merging from debian and bumping the revision just before an alpha, we should avoid that [12:27] Additionally, IIRC, I asked you to discuss the accessibility stuff with fabo. [12:27] was there a merge request somewhere? [12:27] I think it was just coordinated on IRC. That's usually how we do it. [12:27] ScottK: right, and I told you that I will do once I'll explain the rationale (which is just done today) [12:28] so debfx was also aware about a11y then, in both ways as I did it on IRC. Anyway, rebasing shouldn't be hard as it's just a patch apart [12:28] Even if it doesn't go into Debian first, I want to see if we can have something fabo considers suitable so we don't add more diff than we need to. [12:29] fabo: do you have some time to talk now? [12:29] ScottK: well, I tried that for qtcreator and it ends up in a dead wait for 3 weeks as fabo is really busy and I didn't answer my ping on those [12:30] so I don't want to put more charge when people are busy, especially when Qt upstream is onboard [12:30] I'm not saying the upload should be blocked on his ack. [12:30] Since this is a backport from 4.8 I'm less worried about coordination for it. [12:31] no worry about coordination with debian people, I tend to do that a lot with GNOME components and other stuff already, even if it's done a day after the upload :) [12:31] Now that Debian has armhf our armv6+ changes got into Debian. [12:31] I'm mostly concerned that we've got two branches that need to be consolidated for upload. [12:32] If you can rebase your update on Quintasan's merge (and check that) then upload I think that'd be great. [12:32] ScottK: hum, I tend to use the branches for that, I think bzr-rebase should work in a very straightforward way [12:32] I can do it if you can point me to a branch [12:32] I'll get it. [12:32] did the merge has been reviewed/tested? [12:33] even with unity 2d? I don't want that the same thing happens again [12:33] debfx had looked at it some, I don't know how much. [12:34] ok, keep me posted then once we will know more about it === yofel changed the topic of #kubuntu-devel to: Kubuntu: Friendly Computing | 4.6.90 Packaging: https://wiki.kubuntu.org/Kubuntu/Ninjas/Packaging | Merges: https://merges.ubuntu.com/main.html | TODO: http://status.ubuntu.com/ubuntu-oneiric/group/topic-oneiric-kubuntu.html [12:34] !ninjas [12:34] Ninja Time! apachelogger, bulldog98, debfx, JontheEchidna, Lex79, maco, neversfelde, nhandler, Quintasan, rgreening, Riddell, ScottK, stalcup, txwikinger, yofel [12:34] ha [12:34] 4.6.90 tars are up and the wiki and dep-graph are updated [12:35] still no idea where the tarballs are :) [12:35] I'll do kdelibs in a bit [12:35] neversfelde: ftpubuntu@ftpmaster.kde.org (sftp) [12:35] your ssh key is there, I checked [12:35] didrocks: I see you uploaded Qt 4 hours ago. [12:35] (at least one) [12:36] ScottK: right, the version which was staging in the ppa. There was nothing more in the bzr branch [12:36] I'm not sure where Quintasan's branch is at the moment. [12:36] didrocks: If you're going to upload Qt I would appreciate it if you would coordinate with us first. [12:37] Now the merge that Quintasan spent a lot of yesterday working on is obsolete. [12:37] ScottK: I was thinking the discussion on Monday was enough for you to know about it [12:37] and the merge than Quitasian shouldn't conflict? [12:37] how it is obsolete? [12:38] It needs to be updated. [12:38] apart from the debian/changelog, it should be ok [12:38] and we would have the conflict anyway as it wasn't merged in trunk [12:38] apachelogger: how much? [12:38] so yeah, let's agree that if you or I upload Qt, let's know each other [12:38] didrocks: where's your a11y patch? [12:38] yofel: ah, now it works, no idea what was wrong yesterday. but it wants my password, shure that my key is there? https://launchpad.net/~neversfelde/+sshkeys [12:39] I changed it several times in the last half year [12:39] Perhaps the styles of the two teams are a bit different between desktop and Kubuntu, but I absolutely do not think mentioning something 4 days ago is sufficient coordination for uploading something like Qt today. [12:39] ah, I only checked for your name, sec [12:40] neversfelde: try again [12:40] ScottK: well, kubuntu guys uploaded a Qt making the unity-2d broken for alpha1, so notice should go in both way IMHO [12:40] fabo: http://bazaar.launchpad.net/~kubuntu-packagers/qt/ubuntu/revision/174 [12:40] thks [12:41] jussi: sawn [12:41] ScottK: for staging changes, we tend to just put in the vcs (we don't push every changes), maybe we should do that [12:41] agateau: still around? :D [12:41] shadeslayer: yes [12:41] ok #kde-usability then :) [12:42] shadeslayer: ? [12:42] jussi: the N950 shots [12:42] yofel: works, thx [12:42] shadeslayer: and the video [12:42] ? [12:42] didrocks: This is where we discuss Qt maintenance. Being here for the discussion should be enough coordination. That upload was very much discussed here when it was being prepared. [12:43] ScottK: well, some people on the desktop team thinks that toolkit is impact more than one project and should be discussedd on #ubuntu-devel rather [12:43] so I'm still joining there, but I can't follow everything [12:43] as I guess debxx or Quintasan didn't follow the discussion about the a11y patch [12:43] didrocks: Anyone is welcome to join here. It's part of the Kubuntu packageset so this is the right place. [12:44] ScottK: maybe now that it's in the ubuntu cd as well, we shoull revisit the packageset [12:44] but TBH, I don't care, it's just that I think you can understand I can't follow the discussion 100% of the time here [12:44] I would fight against that. [12:44] I understand. [12:45] jussi: nope, haven't seen the vid [12:45] shadeslayer: http://thenokiablog.com/2011/06/22/nokia-n950-hands-on/ [12:45] ScottK: should be rather easier to fix that the social way and just tell that for things which impacts other, we just ping people, agrred? [12:45] I hope you equally understand that mentioning something to me over half a week ago doesn't mean that everyone on the team will know. [12:45] agreed* [12:45] sure, I was thinking it was enough, but I agree that it could have be missed :) [12:45] Agreed, but it's hard to know what those things are. [12:46] I don't think anyone viewed the update before Alpha 1 as risky for unity-2d. [12:46] Because Qt takes soooooo long to build any upload of it needs some coordination. [12:47] I tested a lot this update for a11y for a couple of days, didn't think someone was merging from debian in the same time. I just focus on Qt regression (upstream as well did the work) [12:47] That's good. [12:47] ScottK: hum, I'm not sure, there is Qt/dbusmenu-qt/qt-at-spi/qt-sni (soon) [12:47] also qtcreator, qtquick3D? [12:48] I don't know, or we can just think about the biggest one, Qt? [12:48] as you prefer [12:48] It's less important for the smaller packages. [12:48] the other, in case of issue, are easier to quickly fix [12:48] right [12:48] The dbusmenu stuff we're still waiting for upstream feedback. [12:49] you mean dbusmenu or qt-sni? [12:49] qt-sni (more specifically the Qt changes it needs) [12:49] We want upstream to agree the approach is acceptable for eventual merge upstream. [12:50] (now isn't the right time since Qt 4.8 is past feature freeze) [12:50] right, that's why I'm still waiting before pushing the patch [12:50] as I hope you noted :) [12:50] (and the new package as well) [12:50] I see it wasn't pushed. I wasn't sure you were aware of all the coordination. [12:51] makes sense to me, and hence the ping to you and debfx about Qt things when I have things to touch on. I was thinking Monday ping was enough, sorry, my bad :) [12:52] This is a new thing to need to work together on. [12:52] let's just coordinate for next time (in particular for this incoming merge) [12:52] It's natural to have a few rough edges for a while. [12:52] sure [12:52] I just hope you notice that I'm trying my best to avoid those and I think you know I'm coming from the community and still feel part of it :) [12:52] (and I still have a lot of pure-community things related to ubuntu outside of my work) [12:54] jussi: fooey, that hinge looks like it'll break after a opening/closing the device a couple of times [12:54] shadeslayer: nah, its pretty much the same as on the E7 - and they are nice. [12:55] oh [12:56] didrocks: Sure. I would hope you would still view yourself as part of the community. I really don't like this idea of Canonical/Community. I think that many Canonical employees are part of the community. [12:57] didrocks: Is there any chance you pushed over Quintasan's merge? I checked my backscroll and when he and debfx were discussing it, they didn't specify a location, so I would have assumed it was in the main packaging branch. [12:58] ScottK: I totally agree with that and I think most of people are feeling this way. Of course (and unfortunatly) they are expection, but my guess is that it applies to for people beeing outside of the community before joining the company [12:58] ScottK: hum, I didn't found anything and no conflict in the main packaging branch [12:58] ScottK: I always use that one, let me check again [12:58] cnd: Can you look at https://code.launchpad.net/qt and mark the ones that are done as merged/obsolete/etc so they don't clutter things. [12:58] didrocks: In can case one of them will appear eventually and we'll get it sorted out. [12:59] ScottK: lp:~kubuntu-packagers/qt/ubuntu right? Don't tell me I'm pushing to the wrong location :) [12:59] That's right. [12:59] ok, so yeah, I pulled and pushed there [12:59] let's see with debfx and Quintasan once they are back [13:00] OK. That's the correct place. [13:04] ScottK: no idea on qtcreator? it's more on my "quickly" role, but I'm interested in pushing QML (and the editor) a little bit, do you want special warning when merging from debian or things like that? [13:04] I think it needs some coordination. [13:04] ok, no worry :) [13:04] I think if you discuss your plans here it's sufficient. [13:05] no worry for that [13:05] I also think you should talk to fabo about such things as well as it's nicer to get stuff in Debian. [13:05] I already disussed with debfx and fabo about qtcreator and enabling the design view [13:05] (and if he's too busy, I'm glad to do team upload for him there) [13:05] Sounds good. [13:06] just now that I've been at the Qt summit, I have a clearer view from upstream, just need to refresh them (probably later, next week or the week after) [13:07] That's good. [13:07] didrocks: you're talking about the qml designer plugin? [13:07] "qtcreator and enabling the design view" [13:08] fabo: right [13:08] fabo: so, at the summit, I raised the issue about private header which have to be shipped [13:08] fabo: they are aware of this, and will load a separate process in Qt 5 [13:08] didrocks: oh that's why daniel was annoyed :) [13:09] fabo: right now, there advise are to copy the headers, they don't see changing coming in 4.7 and 4.8 [13:09] that's what fedora and opensuse are doing [13:09] didrocks: it's shipped in latest qtcreator [13:09] fabo: oh? you did it in debian? [13:09] yes [13:09] awesome :) [13:09] so yeah, you're blessed by upstream with that decision ;) [13:10] anyway, qml designer is still young and quite experimental [13:10] but better to try a little bit to play with it [13:10] so ok, no need to discuss about it more, I'll just merge from you [13:10] fabo: also, they are interested in the patches from library pathes we are, do you have an upstream contact? [13:10] 2.2.1 is coming in the next couple of hours [13:11] s/are/have [13:11] both are stuck in NEW [13:11] oh nice, that was my second question [13:11] didrocks: The Qt change is part of the merge we were just discussing. [13:13] ScottK: oh, so it's not a copy but a new binary package? [13:13] Yes. [13:14] (others distro choosed to rather copy in the source to avoid people waiting to do bad things with private headers) [13:14] One that creator can depend on that is very clearly marked as private. [13:14] Anyone who uses it deserves what they get. [13:14] yeah, like "You Don't Want To Install This Package" :) [13:14] Just installing the headers won't cause problems. You'd have to write code that used them. [13:14] right :) [13:15] I just meant, it's more tempting :) [13:15] but it's nice to know, thanks for the heads' up [13:22] didrocks: Would you have a chance to work with cnd and get his touch fixes uploaded to natty-proposed? I'm good with having my pending SRU rejected and replaced now that a proper fix is available. [13:22] ScottK: oh sure, we can probably do that starting next week. I don't have the hardware handy to test it on a natty box there. cnd ? [13:24] He's had some natty testers via his PPA. [13:24] Next week is fine. === tazz_ is now known as tazz [13:25] if it's enough tested (the latest fix we push), I can bindly backport of course, just waiting for him to be awaken there [13:25] Given it's tested in oneiric and in natty via the PPA I think that it's probably tested enough for -proposed. [13:25] Let's wait for him though. [13:30] now this is great, kdelibs 4.6.90 tar contains 4.6.80... [13:30] * yofel sends a mail [13:31] Go yofel go. [13:31] btw they're going to have something called superbuilds [13:32] I'm in favour of split packages though, even if they're a bit more work [13:34] shadeslayer: Those are for lazy people unwilling to joing the modern age. [13:34] We might use some of them as a transition if we don't get the splitting done, but it shouldn't be more than that. [13:34] i'm just saying :P ... i had a look at the project page, looks icky [13:35] won't work for us i think because it uses cmake commands to download the git branches [13:36] didrocks, ScottK: I did not push anything to lp:~kubuntu-packagers/qt/ubuntu yet [13:36] Quintasan: OK. You'll need to merge from there first since didrocks did an upload this morning. [13:36] Since I was awaiting more comments from debfx [13:37] OK. [13:37] Quintasan: apart from the changelog, I don't think you will get any conflict [13:37] Quintasan: Where is it? [13:37] ScottK: I'll upload the diff I've got somewhere, please wait a second [13:37] Quintasan: It's better you push a branch to LP. [13:42] ScottK: diffs are http://people.ubuntu.com/~quintasan/merges/ [13:42] I'll push somewhere in a second [13:44] bah, not only kdelibs but other tars also say 4.6.80, Dirk sure seems overwhelmed by git [13:45] yofel: Sounds like someone needs a guide :P [13:45] I think they wrote a git guide [13:45] somewhere [14:01] micahg: Why is firefox 5.0 carrying a canonical-1.0 version number in the about box? [14:02] It sounds like a candidate for Partner rather than Ubuntu. [14:14] ScottK: I tried keeping delta to minimum but no matter what I do diff still show some differences between two copyrights === Mamarok_ is now known as Mamarok [14:14] Any idea what the hell is wrong? [14:15] * Quintasan even copied the whole file [14:15] No idea. Sometimes you have to take the diff and make a patch out of what you want to keep and then start from what Debian has and apply that as a patch. [14:15] Weird. [14:18] https://code.launchpad.net/~quintasan/qt/debian-merge/+merge/65662 [14:20] debfx: ^ [14:20] Unless I did something wrong it should be fine [14:21] It builds and installs sucessfully [14:22] -installs [14:29] Quintasan: Did you update that to base it from the upload didrocks did this morning? [14:29] yofel: I'll start pacakaging 4.6.90 Tomorrow [14:29] ScottK: Yes, I've tried merging it and it worked [14:30] Great. [14:30] It also did build [14:30] look at -packagers first though, the current tars are junk [14:30] God damn [14:30] So keep working on splits with the beta. [14:30] yofel: Are we getting the old layout or the splitted one? [14:30] Quintasan: Splitted. [14:30] splitted one [14:31] Oh k, I'll start later since I have some business to attend to [14:31] Like Father's Day for example. [14:31] right, you can do all packages from the beta except for kdegraphics, that changes for the RC [14:32] This whole split was HIGHLY unorganised [14:32] Really. [14:32] sure it was, thanks to that they even skipped beta2 [14:32] the RC layout looks like the neon one though. So I guess we won't get anymore changes [14:32] * Quintasan has to compile the ARM magic tooday too [14:33] yofel: PROTIP: copy over the packaging from neon ;) [14:33] not doable, but you can use most of the build-deps [14:33] and I already based the dep-graph on neon :P [14:33] Yeah, good work there Project Neon Brigade :D [14:34] kubotu: order cookies for yofel [14:34] lol [14:34] * kubotu slides a whole bunch of world's finest cookies down the bar to yofel. [14:34] kubotu: order cookies for shadeslayer [14:34] * kubotu slides a whole bunch of world's finest cookies down the bar to shadeslayer. [14:34] kubotu: order cookies for Quintasan [14:34] * kubotu slides a whole bunch of world's finest cookies down the bar to Quintasan. [14:34] :D [14:56] didrocks: qtcreator 2.2.1 is now accepted in Debian. [14:56] ScottK: thanks, I'll merge it later today or tomorrow :) [14:57] didrocks: We'll need Qt updated first and it'll hit binary New. Feel free to sponsor Quintasan's merge as I think debfx is away. [14:57] ScottK: it can wait a little bit, but yeah, I add that on my schedule if debfx isn't there [14:58] Thanks. [15:30] didrocks: I told you wrong about qtcreator. It's uploaded to Debian (and in New there). Sorry for any confusion. [15:30] Debian New is pretty fast these days though. [15:30] We should have it soon. [15:30] ScottK: no worry, can wait a little bit then [15:30] oh really? [15:31] the New queue is processed more regularly? I probably was out of luck last time I experienced this :) [15:35] It's been much better than the historical average recently. Last time I hit New in Debian for binary changes it was ~a day. [15:40] waow, nice to hear! [15:49] ScottK: have you seen Thiago's answer for the sni patch? [15:50] didrocks: I did. agateau also wrote Denis Dzyubenko. I'd like to see his input too. [15:50] sure [15:51] I took Thiago's answer as kind of a non-answer due to the timing. [15:51] Not suprising, but .... [15:51] yeah [15:55] ScottK: I wrote to Denis because I thought Thiago would be too busy to answer. Now Denis seems to be away (those Qt developers can't be trusted! :)) but he told me yesterday in private the patch makes sense (I could paste it privately to you, but I don't like pasting private conversations on public channels). Thiago answer suggests we ship the patch, so I would go for it. We can start the upstream process when it makes sense for 5.0. [15:56] agateau: I think that is fine. [15:56] As long as you don't forget .... [15:57] didrocks: Perhaps you could look at a combination of agateau's Qt patch and Quintasan's merge? [15:58] ScottK: sure, that was my intent when pinging you about that email, if you are fine with it, I will do both in a row :) [15:58] didrocks: Based on what agateau just said about Denis review, I'm fine with it. [15:58] can't commit for tonight, but for tomorrow morning, sure [15:58] debfx: ^^^ Please coordinate with didrocks for further Qt update reviewing. [15:58] Thanks. [15:59] debfx: ScottK: ok, so tomorrow morning (my morning), will probably see an upload of Qt with both if they make sense. Tell me if something is going wrong with that [15:59] didrocks: It might be good to let the current build finish on all archs first. [15:59] I suspect that will be tomorrow afternoon for you. [16:00] ScottK: hum, I don't like pushing things on Friday afternoon. So I can make it staging in a ppa maybe and if everything's fine push on Monday? [16:00] especially for week-end I'm travelling for the platform rally, can't be online to look if everything's fine [16:01] didrocks: Up to you. Next week will be busy for you I'm sure. [16:01] If you want to upload in the morning, it should be OK. [16:01] ScottK: I would prefer, right, I'll look at the build state tomorrow morning [16:02] The next upload will hit binary New. If you upload tomorrow I can review it with my archive admin hat on over the weekend. [16:04] ScottK: oh, as long as it's blocked on binary New, I'm fine with uploading even in the afternoon then :) (didn't check the merge yet) [16:04] but yeah, with the new private header package, I'm dummy :) [16:04] so it's fine, I'll upload tomorrow's afternoon [16:24] nixternal: are you just lurking or have you actually returned? [16:24] don't know yet :p === darkwingduck is now known as DarkwingDuck [16:25] nixternal: epic. [16:25] nixternal: I have a meeting with Jono in 30 min... [16:25] need my server to do some work and this crap fires up automagically [16:25] gl [16:25] ty [16:25] didrocks, ScottK: I was planning to work on the SRU after the the last fix was pushed [16:26] so I'll probably document the second SRU today (the first is already documented) [16:27] and then I'll prepare a patch for SRU against natty [16:28] cnd: excellent, thanks! [16:43] evening [16:47] hey bambee === neversfelde_ is now known as neversfelde [16:48] ScottK: that's been there as long as I can remember [16:48] micahg: OK. I guess I don't check about Firefox very often. [16:49] It seems like an odd reference though. [16:58] bambee, DarkwingDuck: sup [16:58] ;) [16:58] hey Quintasan. Have a job meeting with Jono in a couple minutes. [16:58] DarkwingDuck: Good luck [16:58] Quintasan: Thanks mate. :) [16:58] mhhh kde 4.6.90 is out... so I've a lot of packages to bump for this week end :D [17:00] DarkwingDuck: good luck;) [17:00] * DarkwingDuck crosses fingers [17:26] Quintasan: I reviewed your merge request, some small fixes needed: https://code.launchpad.net/~quintasan/qt/debian-merge/+merge/65662 [17:26] Okay [17:27] fabo: thanks for the "only one dep for each line" that makes life so easier in the future :) [17:27] Quintasan: should be easy to fix :) [18:29] debfx: https://code.launchpad.net/~quintasan/qt/debian-merge/+merge/65662 === Linkmaster is now known as Linkmaster|away [18:56] apachelogger: IMX_MMCODECS_11.01.tar.gz <-- any idea how these are better than what we have in ports? [19:07] yofel: New tarballs for RC1. [19:08] yay [19:08] * yofel rsyncs [19:08] He renamed the directories, so make sure you get the right one (see -packager) [19:09] well, the new one replaces the old one, and old one was renamed [19:36] yep, good tars this time :) [20:02] ScottK, I've uploaded a debdiff and source package for qt4-x11 to bug 762938 [20:02] Launchpad bug 762938 in qt4-x11 (Ubuntu Natty) "Wacom Pressure broken with Qt applications" [High,In progress] https://launchpad.net/bugs/762938 [20:02] it also includes the fix for bug 785433 [20:02] Launchpad bug 785433 in qt4-x11 (Ubuntu) "Touch end events not handled" [Medium,Fix released] https://launchpad.net/bugs/785433 [20:02] could you upload it to natty-proposed for me? [20:03] cnd: Great. I'm slammed with work so hopefully didrocks will have time to look at it tomorrow. Please make sure he's aware. [20:03] ok [20:07] yofel: It might be good to reply to packagers that the problem is fixed. [20:07] true === Linkmaster|away is now known as Linkmaster [20:31] apachelogger: ungzipping magic and trying building === Quintasan_ is now known as Quintasan === yofel_ is now known as yofel [20:38] apachelogger: That amd* stuff are only binaries [20:39] at least in L2.6.35_11.05.01_ER_source [20:43] amd-gpu-x11-bin-mx51-11.05.01.tar.gz and amd-gpu-bin-mx51-11.05.01.tar.gz [20:43] OR I am doing something wrong [20:52] shadeslayer: http://paste.kde.org/86863 <-- debug form Lancelot crash [20:52] can't get any more than this [20:53] is there PIM update for natty already? [21:17] shadeslayer: in staging [21:17] it's still not stable imo [21:26] FFS Y U INSTALL SO LONG [21:42] apachelogger: stuck on video-imx [21:42] linux/mxcfb.h [21:42] missing [21:53] oh wait [21:54] this is sick [21:54] apachelogger: http://boundarydevices.com/blogs/building-gstreamer-plugins-under-ubuntu [21:54] apachelogger: http://boundarydevices.com/blogs/freescale-gstreamer-plugins [21:54] build imx-lib according to instructions [21:54] then try building xorg-imx driver [21:55] apachelogger: also, show up at least once a day [21:55] :P [21:58] DarkwingDuck: ping [22:04] rbelem: ping [22:04] eventually jussi [22:20] * Quintasan laughts maniacally [22:20] * Quintasan stabs everyone around [22:20] * Quintasan kills himself [22:23] * Quintasan tries the LTIB stuff [22:25] Quintasan: you OK? [22:25] valorie: No. [22:25] going apeshit over iMX magic [22:25] {{{{{{{{{{{{{{{{hugs}}}}}}}}}}}}}}}} [22:25] valorie: Thanks :D [22:25] sounds serious [22:32] I'm somewhere in the middle of complation and it misses some damn header files [22:33] Can't find them [22:37] apachelogger: ping ping ping ping [22:42] apachelogger: You made me descend into this madness myself? How far did you get? [22:45] persia: Any ideas about where I could possibly find shw_driver.h? Google yields linux-fsl-imx51 but if I try to install that it pulls other kernel [22:46] Quintasan, Dunno. Maybe I should get one of these devices myself :) [22:46] So, for in-the-archive source, everything is kinda old. [22:47] persia: No, really, I'm trying to compile their own video driver with their own sources and I can't because there are missing headers :S [22:47] The freescale team at Linaro (see https://wiki.linaro.org/LandingTeams ) may have newer code, but the rumour is that there are licensing issues with putting it in the archive. [22:47] And Freescale has some code. [22:48] Aha. Let me look. [22:48] persia: Oh wait, that PPA sounds promising [22:49] persia: I've got some code from Freescale -> L2.6.35_11.05.01_ER_source_bundle [22:49] You might also try looking in linux-headers-2.6.38-1002-linaro-mx51 [22:49] Already installed [22:49] I don't know if that has the right headers, as it's supposed to be upstreamable stuff though. [22:49] now trying linux-headers-2.6.38-1003 [22:50] This Class 4 Card... [22:50] * Quintasan grits his teeth [22:50] SATA ought work, and would be *lots* faster. [22:50] Mind you, this needs an external drive, case, power, cabling, etc. [22:51] Just found the connector, but I do not have a HDD [22:51] maybe my USB drive would be better [22:51] USB drive is a bit better. [22:52] And, depending on your taste in hardware hacking, many USB drives can be disassembled to get SATA drives. [22:52] You got me there. [22:52] * Quintasan looks for instructions [22:52] (note that USB *rotary* drives are better. Most USB flash drives aren't that much better.) [22:55] hmm 3GB HDD [22:55] That's magic [22:55] 3 *giga* byte? [22:56] persia: Yes. Something old most likely [22:56] WD Caviar 33200 [22:57] 3249,3 MB :D [22:57] Wow! [22:58] CCC: 19 Jan 98 [22:58] So, that's a PATA drive. You'd need a converter to use SATA. [22:58] I know, I just looked around if something useful is not laying around [22:59] If I get this driver to work then this means two things [23:00] GL and video decoding acceleration [23:00] And huge kudos from all sorts of folk :) [23:00] K, plasma-mobile starts up as expected [23:01] ericm (the person who uploaded everything in that PPA) is usually in #ubuntu-arm, although in UTC+8, so maybe not yet. He might have more information about kernel porting for that hardware. [23:03] * Quintasan tries adding that PPA [23:04] I downloaded the header debs from there, and didn't see shw_driver.h (although maybe I didn't look hard enough). [23:06] persia: So I far I figured out I need linux/mxcfb.h to build the driver which is apparently provided by imx-lib which in turn needs that shw_driver.h to compile [23:06] If we are to somehow package all that stuff into a working image that will be a massive PITA [23:09] Why? Does it need to compile-at-runtime or something annoying like that? [23:09] Otherwise it seems doable (although we'll want to share the work with lots of other folk with the board). [23:11] persia: I mean packaging the driver if we don't have the headers :D [23:11] There is an ITP in Debian but it was untouched [23:11] Aha! "the sahara/ and rng/ sub-projects won’t compile without a full kernel source installation, since they refer to headers that are not in the public include/linux tree.", and from looking at the docs for shw_driver.c, it seems to be RNG related. [23:11] Which makes me sad [23:11] Err, shw_driver.h [23:12] Shouldn't linux-headers be enough? [23:12] Well, the trick there is to find someone who *does* have the headers. I very strongly suspect that the Freescale Landing Team at Linaro would have access to them (as some of those guys work on kernels at Freescale). [23:13] Yes, for sane values of "should". [23:13] In practice, some companies will sign licensing agreements with other companies to use their technologies, and then use those technologies in their products. [23:14] Often these agreements include disclosure restrictions, which prohibit the licensee from disclosing the source, even if they wished. [23:15] Urgh. [23:15] I don't happen to know the terms of the contract between Freescale and AMD for the Z180 core, but unless someone was extra careful, it probably has that sort of restriction (just because the boilerplate contracts all have this by default). [23:16] Would answer the amd-gpu-bin-mx51-11.05.01.tar.gz question :) [23:16] It's binary only installation [23:16] In some cases, vendors will make binary drivers available. On the other hand, many of the silicon vendors who license the ARM ISA are used to working in the embedded market, so these binary drivers are typically only made available in a single revision for a combined hardware/software "product". [23:18] However, if you happen to know someone who has access to the code that needs to be compiled, you may be able to get them to release binaries based on it (although it depends on the specific terms of the arrangement). [23:20] Looks like I'll stay at #linaro a little bit longer [23:21] There or #ubuntu-arm. Many of the Ubuntu-friendly Linaro folk are there (but not the Android folk, etc.) [23:23] persia: Where did you find that "the sahara/ and rng/ sub-projects won’t compile....." ? [23:23] Note, the other option is `rm -rf sahara2/ rng/` (unless you have something *else* requiring shw_driver.h) [23:23] From your URL: http://boundarydevices.com/blogs/building-gstreamer-plugins-under-ubuntu [23:23] * Quintasan facepalms [23:23] Mind you, that's outdated... [23:23] I've read that two times [23:24] Well, no harm in trying out [23:24] The difference might be that you expected things to work, and I'm surprised you're making the progress you have. [23:25] Note that you may need to use "PLATFORM=IMX53". [23:25] If I recall correctly, i.MX51 uses an AMD Z160 and i.MX53 uses an AMD Z180. [23:25] Which quite possibly means differing code paths. [23:26] persia: Well, I'm the adamant type, I usually sit until I get stuff done :P [23:27] And for this you are to be commended. [23:29] * valorie adds kudos to Quintasan [23:30] Someone should rather invent a way not to sleep and be effective as usually [23:30] * Quintasan installs headers once again [23:31] coffee [23:31] and the occasional walk around outside in the fresh air [23:32] * Quintasan wonders if it would be possible to have XMBC on this board [23:32] I wanted a small PC in living room to watch movies [23:32] if that small board can decode 1080p then I'm buying the HDMI port extension [23:33] baruba [23:33] LOOK WHO'S HERE [23:33] * Quintasan throws bricks at apachelogger [23:33] I actually shall be going to bed soonish [23:33] * Quintasan throws more bricks at apachelogger [23:34] exams a bit exhausting, apachelogger? [23:34] gotta pack up my life and move tomorrow and study for exams at some point [23:34] Excuses, all excuses apachelogger [23:34] valorie: nah, drinking [23:34] I blame all the drinking [23:34] ah [23:34] How come I am not surprised? [23:34] yesterday I was so drunk I, my bike, my laptop and everything ended up in a mud hole [23:34] welll, your .prn is already on your devices, so that's done [23:34] later on the better part of those things moved into the shower altogether [23:35] you took your bike into the shower? [23:35] unusual [23:35] I know [23:35] apachelogger: Bike and drinking? Does not compute the same way as skateboarding and drinking [23:35] then I went to sleep for 12 hours and was all surprised that the entire house is drity [23:35] Quintasan: my sober biking is already about as bad as my sober skateboarding [23:36] * valorie fears for the apachelogger health [23:36] apachelogger: Are you going to Akademy or Desktop Summit? [23:36] imagine that combined with wet ground and drunkeness [23:36] all wicked up [23:36] Quintasan: perhaps I am and perhaps I am not [23:36] ! [23:36] the future will tell [23:36] apachelogger: http://www.youtube.com/watch?v=McO1cH54vEU [23:36] Problem? [23:36] * valorie gives the future a talking-to [23:36] also I fear that godzilla might come after berlin, in which case I'd rather not be there [23:37] great laugh on that one, Quintasan [23:37] ah, I know it, I know it all too well [23:38] valorie: It's not me laughing :D [23:38] like if I were not wearing cloths most of the time in consideration of other people I'd look like a wreak really [23:38] valorie: I'm the one landing on face [23:38] :( [23:38] it shows [23:38] that's not good for your face [23:39] Quintasan, http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=IMX53QSB claims it does 1080p (but you will need to sort the codecs first) [23:39] * apachelogger points out that the codecs likely need accel first [23:39] valorie: Well, not that I expected one of bearings would suddenly refuse cooperation with the rest of the wheels [23:39] as otherwise openmaxil won't do zip [23:39] apachelogger: Guess what I'm trying to do Sherlock [23:39] I think rsalveti was looking at XBMC (and other set top box solutions). Might ask him in #ubuntu-arm. I don't think he has a Quckstart, but he has similar hardware. [23:40] the more you fix the less I have to fix [23:40] the less I have to fix the more time I can spend drinking [23:40] the more time I can spend on drinking the more creative ideas I have [23:40] it is a win for everyone really [23:40] also I need to organize a flipping meating next week [23:40] apachelogger: the more you fix the less I have to fix, the less I have to fix the more time I can spend drinking [23:41] persia: \o/ imx-lib compiled [23:41] \o/ [23:41] Does it work? [23:41] Can't install it via make install :O [23:41] Heh. [23:41] Did you happen to end up with the code with a license that lets you upload it? [23:41] ahh, the joys of not proper free software [23:42] There are folk hanging around in #ubuntu-arm with commit access to trunk, so we can arrange for patches to be taken. [23:42] persia: Probably not since contents of sim are not compiled due to yet another "missing" header [23:42] Oh, ugh. [23:42] linux/mxc_sim_interface.h this time [23:43] http://linux-fsl-imx51.sourcearchive.com/documentation/2.6.31-605.8/mxc__sim__interface_8h-source.html ? [23:43] Okay, removed sim/ as well [23:43] Exactly [23:43] But that file is *GPLv2*. It ought be around somewhere. [23:43] hmm [23:44] linux/mxcfb.h still missing [23:44] Even the implementation is available: http://linux-fsl-imx51.sourcearchive.com/documentation/2.6.31-606.11/imx__sim_8c-source.html [23:44] (yes, these examples are from an *old* kernel, but still ...) [23:44] looks like imx-lib providing that was a wild guess [23:44] Should be in the kernel source. [23:45] (or it was for 2.6.31) [23:45] I'll install that linux-fsl-imx51 [23:46] I suspect you'll get the newest code from *-linaro-lt-mx53 from the PPA. [23:47] https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/2282720 [23:47] I'm not going to bother with apt magic and I'll just force the debs [23:47] My understanding (the people who really do this know more) is that *-linaro-lt-* includes random code that makes the board happy but is expected to make Linus cry, and linux-linaro-* contains code that is expected to be upstreamable, but may not provide full board support. [23:48] I wouldn't use that one, unless you want older code. [23:48] I believe the latest version they have there is from lucid. [23:48] (but, yeah, if there's no other way to get it) [23:49] The main issue being that the i.MX53 *didn't exist* for lucid, so that code is guaranteed not to have ever been tested on your processor. [23:49] It can't burn the board, can it? [23:50] Did you install a heatsink? [23:50] nope [23:50] Then it can. [23:50] Unfortunately, all pre-3.0 kernels require that all the resistor values, board voltages, etc. be specified in the source code. [23:51] Mind you, the values might not have changed much, but one never knows. [23:52] With 3.0 and later, *some* drivers will be using "devicetree" to specify these details outside the kernel, as an extra datafile. [23:52] I have no idea if the drivers for i.MX* are included in the set of drivers that have been ported to use devicetree. [23:53] That said, since we don't actually have any kernels newer than 2.6.38 for that board, we can be sure that none of the available kernels use devicetree. [23:53] I'll just copy over the headers [23:53] That's probably safer :) [23:54] Unless Google has been trolling me and those headers are not really in there [23:54] Oh wait, it's 01:00 in the morning. [23:54] I thought it's more like 03:00 [23:56] I have linux-headers-2.6.35-1001-linaro-lt-mx53_2.6.35-1001.1_armel.deb installed [23:56] That's ericm's latest, from what I can tell. [23:56] He might have newer in git somewhere, but I don't see any packages. [23:57] I guess I'll go to bed if that doesn't work. Not much I can do at this phase.